黑客如何威胁软件供应链安全
介绍
在许多方面，软件供应链与制成品相似，我们都知道，制成品在很大程度上受到了全球大流行和原材料短缺的影响。
然而，在IT世界，近年来要克服的主要障碍不是短缺或流行病，而是旨在利用它们同时伤害数百甚至数千名受害者的攻击。如果你听说过2020年到今天发生的网络攻击，那么很可能是软件供应链起了作用。
当我们谈论对软件供应链的攻击时，我们实际上指的是两个连续的攻击：一个针对供应商，另一个针对链中的一个或多个下游用户，将第一个作为工具。
在本文中，我们将通过研究现代开发周期中的一个典型漏洞，深入探讨软件供应链的机制和风险：公司数字资产中存在个人识别信息或“秘密”。我们还将看到公司如何通过利用持续改进周期来适应这种新情况。
供应链是IT开发周期的核心
什么是供应链？
如今，很少有公司100%内部生产软件。无论是开源库、开发人员工具、内部部署或基于云的部署和交付系统，还是软件即服务（SaaS）服务，这些构建块已成为现代软件工厂中必不可少的。
每一块“砖”本身都是一个漫长供应链的产物，使软件供应链成为一个涵盖IT各个方面的概念：从硬件到开发人员编写的源代码，到第三方工具和平台，还有数据存储和所有用于开发、测试和分发软件的基础设施。
供应链是一个分层结构，允许公司实施高度灵活的软件工厂，这是其数字化转型的引擎。
开源组件和库的大规模重用极大地加快了开发周期和根据客户期望交付功能的能力。但与这一令人印象深刻的进步相对应的是，对进入公司产品的代码的来源失去了控制。这种依赖关系链使组织及其客户暴露于其直接控制之外的变更所带来的漏洞。
这显然是一个重大的网络安全问题，随着供应链逐年变得越来越复杂，这一问题只会越来越严重。因此，最近大规模网络攻击能够利用其优势也就不足为奇了。
薄弱环节的风险
对于黑客来说，出于几个原因，公司的软件供应链是一个有趣的目标。首先，由于其复杂性和软件工厂核心交互“砖块”的数量，其攻击面非常大。第二，应用程序安全历来侧重于保护生产中的应用程序（即向公众公开），通常缺乏有效保护内部安全的可见性和工具建筑服务器和CI/CD管道的其他部分。
此外，重要的是要了解当今的开发链正在不断发展，不断添加新的工具。这是DevOps运动的一个决定性特征，它极大地模糊了开发和运营之间的界限，让开发人员可以尽可能快地为客户提供功能。
然而，这些选择往往是在没有监督的情况下实施的，而且在不同的团队中，甚至在同一个部门内，也会有很大的不同。由于工具、库和平台略有不同，因此很难创建准确的库存，而库存是有效安全管理的基石。
最后，通过利用供应链，黑客找到了最大化攻击影响的方法，从而提高了攻击的收益。要理解这一点，我们必须考虑软件服务公司供应链的产品和服务是其他供应链的基石。攻击者成功渗透到链中的一个环节，可能会危及整个用户群，这可能会带来灾难性后果。
供应链攻击的兴起
在2020年3月至6月的SolarWinds攻击中，约18000名猎户座平台客户（包括一些美国政府机构）下载了带有恶意代码的更新。该代码允许黑客未经授权的后门访问近100个实体的系统和私人网络。SolarWinds直到2020年12月才发现漏洞。国际丑闻接踵而至。
几周后，即2021 1月，由于构建过程中的错误，攻击者获得了Docker映像创建过程中使用的凭据，其中涉及Codecov软件。这些凭据使攻击者能够劫持Codecov，这是一款用于测试开发人员代码覆盖率的软件，并将其变成真正的特洛伊木马：由于该软件用于持续集成（CI）环境，因此它可以访问构建过程的秘密凭据（我们将再次讨论）。
因此，攻击者能够从Codecov用户那里窃取数百份凭据，从而允许他访问尽可能多的安全系统。该公司在几个月后的4月份才发现了这一漏洞。
大约90天后，2021 7月2日，一个复杂的勒索软件小组利用了Kaseya Virtual System Administrator（VSA）服务器中的漏洞，影响了大约1500家小型企业。Kaseya是管理服务提供商（MSP）和其他IT承包商使用的网络、系统和基础设施管理软件的开发商。尽管勒索软件攻击控制了客户的系统，但几天后攻击被遏制并被击败。
但这并不是2021最大的供应链漏洞。2021 12月，也就是Kaseya事件发生几个月后，发生了对软件供应链最简单但最广泛的攻击。在最初的概念验证（POC）被披露后，攻击者开始大规模利用影响Apache Log4j的漏洞，Apache Log4j是Java生态系统中非常流行的开源日志库。
尽管修复问题的更新建议相对较快，但事实上，这个仅由少数人维护的库在世界各地被大规模使用，而且很少以透明的方式使用，造成了一个巨大的攻击面，需要数年才能解决：美国网络安全和基础设施安全局（CISA）刚刚将其描述为“地方病”，这意味着它可能在未来十年内再次出现。
尽管其规模巨大，但这一脆弱性远不是一个孤立的案例：2020年至2021，利用开源生态系统作为传播媒介到达供应链的攻击数量增加了650%。欧洲网络安全局（ENISA）预测，到2022年，供应链攻击将增加四倍。
所有这些攻击和漏洞都突显出缺乏有效保护供应链的可见性和工具，无论是清点开源组件的使用情况、验证其完整性或防止敏感信息泄漏的系统。关于最后一点，重要的是后退一步，更仔细地审视安全的这一关键要素。
供应链的关键：秘密
获取未加密的凭据是黑客在供应链上从供应商转移到客户的最佳方式：有了有效的凭据，攻击者将作为授权用户进行操作，入侵后检测变得更加困难。
从防御的角度来看，硬编码的秘密是一种独特的漏洞。源代码是一种非常有漏洞的资产，因为它本质上是要经常克隆并分布在多台机器上的。事实上，源代码中的秘密伴随着它而来。但更令人担忧的是，代码也有“记忆”。
如今，任何代码存储库都是通过版本控制系统（VCS）管理的，通常是Git，它对代码库中的文件所做的所有更改都有一个完美的时间表，有时是几十年。问题是，仍然有效的秘密可以隐藏在时间线上的任何地方，从而为软件攻击表面打开了一个新的维度，这次是历史性的。
不幸的是，大多数安全扫描仅限于检查应用程序源代码的当前、已部署或即将部署状态。换言之，当涉及到隐藏在旧提交中的秘密，甚至是从未部署过的分支时，传统工具是完全盲目的。
仅去年一年，就有超过600万个秘密在GitHUb上公开转发：平均每1000个提交中就有3个包含秘密。这比去年增加了50%。
大量的这些秘密使公司资源得以利用。重要的是要理解，即使GitHub上托管的大多数开源项目都是个人存储库，专业开发人员也很容易无意中发布代码，从而访问公司资源。它经常发生！
因此，想要对软件供应链进行攻击的恶意行为者会仔细查看GitHub上的公共存储库，这并不奇怪：他们很有可能发现手边的缺陷，主要是源代码中存在的秘密，这些秘密可以让他在不引起任何怀疑的情况下向系统验证自己。
一旦一个秘密被公布，它必须立即被视为被泄露：一个简单的实验就是自愿公布一个“金丝雀令牌”，即一个看起来相当有效的秘密的代码，在使用时会触发一个警报机制。发布和警报之间的时间平均为4秒！这一空间受到密切监测和积极利用。
为了尽快消除入侵风险，只有一个解决方案：立即撤销秘密。但是，由于恐慌或缺乏技术知识，一些人试图通过添加一个删除秘密的提交来掩盖错误，这根本不能缓解安全漏洞：事实上，Git会跟踪随着时间的推移添加、修改或删除的所有代码历史。实际上，这意味着很难消除过去错误的所有痕迹。这也意味着，在许多情况下，即使从代码的“最终”状态中删除了该秘密，该秘密仍将在线可用。
但问题并不止于此。在我们的场景中，当包含秘密的文件被一个“干净”文件替换时，无论是在同行手动代码审查期间（一种常见做法），还是在传统的应用程序安全工具（如扫描仪）（也只考虑源代码的最新版本）中，都无法检测到秘密。更糟糕的是，每次克隆代码时都会复制该漏洞，因此有可能长时间无声传播。换句话说，这是黑客的天赐良机。
7月3日，加密货币巨头币安斯（Binance）的首席执行官警告称，这起大规模泄密事件据称泄露了上海警方的“10亿（中国）居民记录”，包括“姓名、地址、国家身份、手机、警察和医疗记录”。原因是什么？据称，中国CSDN的开发人员复制了一段源代码，其中包含连接到巨大的个人信息数据库的秘密。
私人回购也受到影响
毫不奇怪，这只是冰山一角。私有存储库比公共存储库隐藏更多的秘密。在封闭的环境中工作提供了一种虚假的安全感，使贡献者不那么可疑，因此统计上更可能“泄露秘密”。容忍在非公开的存储库中存在秘密将是一个大错误。
事实上，无论这些存储库多么私密，它们所包含的秘密都可以被用作攻击中的杠杆，从而允许访问存储库的对手转向其他系统或提升其权限。有很多黑客攻击场景，但它们都有一个共同点：使用任何发现的秘密来最大化攻击的影响。
应用程序安全团队非常清楚这个问题。不幸的是，每周调查、撤销和轮换秘密所涉及的工作量实在是太大了，更不用说挖掘多年未开发的代码了。
网络安全团队非常严肃地对待源代码中的硬编码秘密及其带来的风险。在著名的CWE Top 25 2022（常见弱点列举）中，它们在最“常见和影响”的漏洞中排名第15。
正如前面的示例所示，将此漏洞与所有其他漏洞区分开来的一个关键区别是，在源代码中发现的秘密在软件未投入生产的情况下是可利用的，这一点经常被遗忘！换句话说，携带漏洞的是代码本身，而不是底层逻辑。
因此，我们已经看到了秘密是如何成为确保供应链安全的关键因素。现在让我们来看看组织如何在开发周期中应对这一新威胁。
组织的反应：将安全纳入发展周期
DevSecOps的出现
软件供应链有许多灰色区域，传统安全方法无法解决。组织已经意识到需要在开发生命周期中引入安全性，以在生产力和弹性之间取得正确的平衡。
DevSecOps运动就是这样诞生的。DevSecOps包括在DevOps实践中插入安全性。需要提醒的是，DevOps是一种开发理念，它将流程和技术结合在一起，使开发人员能够更有效地与运营团队合作。我们经常谈论DevOps管道（软件供应链的主干），其特点是其连续性：它是指能够以连续的方式在预生产中集成、测试、验证和交付代码。
传统的安全方法是在与DevOps理念不符：交付速度越来越快，随机应变。应用程序安全团队和开发人员团队之间存在着巨大的摩擦，他们的文化、专业知识和方法非常不同。这种分歧是许多误解的根源，最终助长了发展周期的脆弱性。
对于安全管理者来说，挑战是保持DevOps的速度，同时加强改进的安全态势：包括开发周期早期阶段（规划、设计）的安全规则，传播最佳实践，并通过更早捕获更多“良性”缺陷来缩短平均修复时间（MTTR）。
这不仅仅是一种方法，更重要的是公司希望努力实现的理想。这条路并不长：文化差异是顽强的，往往需要数年才能消失。已经提出了促进这一过渡的若干途径。
第一条途径是依靠现代工具。开发人员采用与他们的工作环境完美集成的直观工具：命令行、API、IDE（集成开发环境），甚至是他们的版本控制系统（VCS）。直到最近，典型的安全分析师的工具还远远没有出现在这个世界上，使用的术语非常具体，而且往往难以理解。安全软件供应商在这方面取得了巨大进展，为开发人员提供了熟悉安全概念并在广泛领域实现自给自足的机会。
自动化也是创建有效安全系统的关键。软件工程师是自动化方面的专家，因此他们无法实施，甚至无法理解为保护供应链而强加给他们的安全规则，这是毫无意义的。他们也是最了解需要防御的系统的人。将他们的知识与安全工程师的专业知识相结合，可以最大限度地利用可用资源，使团队整体更快乐。
也许DevDecOps最重要的元素是安全必须是全部的开发周期的各个阶段。它的安全性不仅仅是一个简单的检查表，在发布新版本之前就可以勾选。
为了实现这一结果，必须解决一个重要概念：分担责任。
分担责任并向左转移
新的安全模式意味着在参与项目的所有成员之间分担责任。在跨职能团队中共享，而不是在筒仓中共享，这是历史上的情况（一个负责安全、审计和质量保证的独立团队）。
术语“向左移动”通常用于说明将安全移出筒仓的愿望，以便更早地移动安全操作并节省检测和补救费用。然而，这一术语在2000年代初开始流行，它描述的是一种理想的运营结果，而不是实现它的真正方式。对于一个希望开始DevSecOps转型的组织来说，最好关注如何诱导这种变化，以有效地保障其软件供应链。
开发人员的授权是这一点的重要驱动因素。作为数字世界的第一批工匠，他们必须参与安全决策，以考虑他们的需求和工作方法。一个简单但有力的指导原则是始终使最短的路径也是最安全的。
因此，防止最常见错误（例如忘记源代码中的秘密）的工具应该易于使用，并且不会与团队开发代码的方式产生摩擦。一个好的工具必须证明它的有用性和价值，而不会觉得它会导致“供应商锁定”它还应该能够与安全团队进行交互，这些团队不会消失！相反，安全团队往往比相应的开发团队小，因此必须迅速动员起来应对最复杂的情况。
在过去，应用程序安全被认为是一个无法渗透的领域，以确保其有效性，但那些日子已经过去了。如今，人们希望在整个周期内进行安全测试，并希望结果能够在不必升级到安全团队的情况下进行补救。
在周期的每个阶段促进对安全的所有权，需要所有团队共同努力提高透明度。这是创造信任环境和培养一种拒绝将责备作为问责工具的文化的强制性条件。
事实上，即使是远离技术领域的功能也必须是这种转换的一部分。例如，产品经理在决策过程中还必须考虑到他们设计的产品的安全性。
因此，公司应对软件供应链新风险的反应将是技术性的，也是组织性的。在供应链上工作的不同专业之间的合作现在是信息系统安全的优先事项。
Note — 本文由GitGuardian的技术内容作者Thomas Segura撰写并投稿。
