为什么2023年最应该关注软件供应链安全

NIST表示，尽管各行各业都在努力监视或删除可疑的包，但由于任何代码存储库都可能包含恶意代码，所以风险正在不断扩大。比如GitHub等存储库正在采取积极措施阻止恶意软件进入其网站，但攻击者仍找到了相应的方法，成功将其代码提供给了毫无戒心的开发人员。

Phylum《2023年第三季度软件供应链安全发展报告》显示，各种类别的可疑软件包都在不断增加。在扫描的300万个包中，有1万多个文件引用了已知的恶意URL；近86000个包含预编译的二进制文件，这使得它们难以扫描恶意软件；另有5500人试图混淆他们的代码，5000人被作者用一次性电子邮件账户注册。

其中更重要的是，该报告显示了策略的转变：越来越多的恶意软件作者开始针对特定的公司，而不是采取更广泛的方法，这点和NIST的观点有所不同。报告指出，近1000个恶意软件包在针对特定的群体或企业，比2023年第二季度增长了47.4%，这些有针对性的攻击包括获取凭证和源代码，也包括了盗窃知识产权。

Phylum指出，开发人员的做法对供应链安全产生了重大影响。开发人员每周从Javascript软件包注册中心npm下载约240亿个软件包，但几乎没有人验证这些代码的完整性。报告指出，攻击者知道了这一点，这可能会使得他们在未来发起更广泛的活动，如大规模勒索软件攻击或僵尸网络。

NIST对此表示赞同，他们认为，开发人员环境是恶意行为者实施SSC攻击的主要原因。由于现代分布式劳动力、自带设备（BYoD）场景、SaaS等，都在和自托管源代码管理系统相结合，因此组织必须采取措施来降低开发环境、开发人员账户，以及其相关端点的风险。

以上述内容为背景，国外相关组织介绍了最近在SSC攻击中常会使用到的几种技术。

在大多数SSC攻击中，攻击者会破坏上游服务器或代码存储库，并注入恶意负载（比如恶意代码行或Trojanized更新），然后将有效载荷向下游分发给许多用户。然而，从技术角度来看，并非总是如此。

Codecov供应链攻击就是很好的例子。根据官方公告，Codecov攻击者会从有缺陷的Docker映像创建过程中获得凭据，该过程可用于修改Codecov Bash Uploader，然后攻击者会修改Codecov服务器上托管的Codecov Bash Uploader，以收集从客户连续集成/连续交付（CI/CD）环境中上传的环境变量。

Codecov Bash Uploader脚本存在于Codecov[.]io/Bash的Codecov服务器上，成千上万的存储库已经指向该链接，以便将信息从其CI/CD环境上游发送到此Bash Upload。因此，恶意代码仅存在于受损的上游服务器，而没有发生任何代码的下游分发，因为所谓的下游存储库已经指向托管Bash Uploader脚本的Codecov服务器。然而，这些下游存储库受到了此次攻击的影响，因为它们被配置为将数据上传到Codecov的Bash Uploader：

据报道，Codecov攻击者因此得以使用相关凭据，并攻破了数百个客户网络。不久之后HashiCorp披露，Codecov事件导致其曝光了用于签名和验证软件包的GPG私钥。

“中游妥协”是指攻击者破坏中间软件升级功能或CI/CD工具。此前，Passwordstate企业密码管理器的制造商Click Studios遭受了供应链攻击，攻击者破坏了Passwordstate的“就地升级功能”，并将恶意更新分发给Passwordstate用户。

此非法更新包含了一个名为Moserware的修改DLL文件。Click Studios在一份安全公告中表示：“该漏洞在被清除前存在了大约28个小时，在此时间段内执行了就地升级的客户会受到影响，而Passwordstate的手动升级不会受到影响。受影响客户的密码记录可能已被收集。”

除了在升级过程中进行篡改外，这种供应链攻击还涉及社会工程学。在伪造更新的zip文件中，攻击者设法更改了用户手册、帮助文件和PowerShell构建脚本，以指向他们的恶意内容分发网络（CDN）服务器。

这种攻击的社会工程方面也表明了另一个弱点：开发人员或软件消费者可能并不怎么怀疑与内容分发网络（CDN）相关的各种链接。NIST表示，这可能是因为软件应用程序和网站会合法地使用CDN来提供更新和脚本。

近几年，任何一篇关于供应链攻击的文章都会提及依赖性混淆，因为这种攻击具备简单化和自动化的性质。由于在多个开源生态系统中存在固有的设计弱点，因此攻击者可以用最小的代价来施行自动化的依赖性混淆攻击。

简单来说，如果组织的软件构建，使用了在公共开源存储库中不存在的，并且是私有内部创建的依赖项，则此依赖项混淆（或命名空间混淆）会起作用。攻击者可以在具有更高版本号的公共存储库中注册同名依赖项，然后与组织的内部依赖关系相反，攻击者的依赖项就很可能会被拉入组织的软件构建中。

通过在PyPI、npm和RubyGems等常用生态系统中利用这一依赖项弱点，黑客Alex Birsan得以侵入35家大型科技公司，并获得超过13万美元的漏洞奖励。

随着HTTPS网站的增加，SSL/TLS证书现在变得无处不在，其可以保护组织的在线通信。因此，SSL证书私钥的泄露，可能会威胁到最终用户由“端到端加密连接所提供的安全通信和保证”。

2021年1月，Mimecast披露，其客户用于建立与Microsoft 365 Exchange服务连接的证书被泄露，此事件可能影响到10%Mimecast用户的通信。虽然Mimecast没有明确表示这是SSL证书，但正如一些研究人员所怀疑的那样，情况似乎就是如此。

另一方面，被盗的代码签名证书（即受损的私钥）可能会对软件安全产生更广泛的影响。比如Stuxnet仍然是一个重要例子，攻击者使用从两家知名公司窃取的私钥，将他们的恶意代码签名为“可信”，而这种攻击在Stuxnet之前就已经盛行，这也是为什么前面提到的HashiCorp在Codecov供应链攻击中暴露GPG私钥的例子是有问题的。尽管目前还没有迹象表明HashiCorp的泄露密钥被攻击者滥用来签署恶意软件，但在泄露密钥被撤销之前，这种事件确实有发生的可能。

Sonatrype前段时间观察到一次多方面的SSC攻击，该攻击不仅依赖于向用户的GitHub项目引入恶意拉取请求，还滥用GitHub的CI/CD自动化基础设施GitHub Actions以挖掘加密货币。该攻击包括克隆使用GitHub Actions的合法GitHub存储库，更改存储库中的GitHub Action脚本，并向项目所有者提交拉取请求，将此更改合并回原始存储库。

如果项目所有者随意批准更改后的拉取请求，那么供应链攻击就成功了，但这甚至不是先决条件。恶意拉取请求包含对ci.yml的修改，攻击者一提交拉取请求，GitHub Actions就会自动运行这些修改。修改后的代码本质上是滥用了GitHub的服务器来挖掘加密货币。

这样的攻击一举两得：它能欺骗开发人员接受恶意拉取请求，如果失败，它就会滥用现有的自动化CI/CD基础设施进行恶意活动。

安全人员应该知道，安全只有在最薄弱的环节才能发挥作用。由于人的因素仍然是最薄弱的环节，“exploitation（利用）”可能来自最不被期望的地方。Linux基金会最近“拉黑”了明尼苏达大学的研究人员，因为这些研究人员故意提出了错误的“补丁”，从而在Linux内核源代码中引入漏洞。

尽管该实例被捕获，现在已经得到处理，但它证明了几个简单的事实：开发人员分布稀疏，使得并不总是由带宽来审查每一个代码提交或拟议的代码更改，这些更改可能是有缺陷的或完全恶意的。而更重要的是，社会工程可能来自最不可疑的来源，比如看似可信的大学研究人员，他们就拥有“.edu”电子邮件地址，并可能会发起恶意攻击。

在过去的一年里，创建拼写错误和品牌劫持软件包的攻击者多次以开源开发者为目标，在他们的上游构建中引入恶意代码，然后传播给许多消费者。

NIST指出，除了外部恶意活动外，SSC攻击也可能由不满组织的内部人员所发起。这些攻击通常是利用各种技术来危害供应链中的软件，比如网络钓鱼、恶意软件和社会工程。攻击目标包括源代码、凭据和敏感数据。而利用漏洞的类型各不相同，比如注入漏洞和恶意软件、窃取凭据，以及将恶意代码注入存储库。

而针对以上种种软件供应链问题，NIST提出了一套强有力的缓解措施，此措施从补丁管理、访问控制等基本活动，到审计、监测，以及与适用的监管框架都能保持一致。

NIST介绍，现代DevSecOps环境需要使用CI/CD平台和技术来促进迭代软件开发和交付。当软件经过构建、打包、测试和部署的各个阶段时，就会生成元数据，这些元数据可以帮助保障软件的来源，以及生成软件的步骤和措施。

NIST指出，组织必须对内部开发的代码以及第三方组件（如开源软件）采取安全措施，至少从源代码的角度来看，这些组件正越来越多地构成现代软件。

对组织来说，需求是确保攻击者不会篡改软件生产过程，不会引入恶意软件更新，以及不会破坏CI/CD管道工件和活动的完整性。NIST提供了下表，展示了在典型CI/CD环境中需要信任的工件，以及工件通常会驻留/依赖的存储库：

NIST建议，组织要为系统操作员定义角色，映射到特定权限，并根据基于角色的访问控制（RBAC）实现最小特权访问。如果特定参与者的账户或资产受到损害，此类活动可以降低风险。

NIST还建议自动化SAST和DAST的使用，并通过基础设施即代码（IaC）和策略/配置即代码等技术，以声明的方式定义应用程序代码和CI/CD活动的开发和部署，这些技术可以为安全和合规指定运行设置。同时，CI/CD管道的工作流程也必须是安全的，包括构建、从存储库推送/提取工件，以及软件更新或代码提交。

在构建方面，NIST的建议包括指定构建策略、使用独立的构建平台，以及执行构建活动的人员权限。NIST表示，组织还应利用策略执行引擎，并确保在软件构建过程中，产生安全构建过程的证据和证明，其包括所涉及的环境、过程、材料和人工制品的证明。

NIST建议对证明进行签名，并将其存储在可用于证明策略合规性的位置，这样做有助于证明软件是由授权实体或工具所构建的，并且符合法规遵从性要求。

而除了安全构建活动的需要外，NIST还建议组织要确保SCM存储库上的推拉操作安全。这包括开发人员从存储库中提取、修改代码，也包括将代码推回存储库，这每一项都会带来篡改的机会。NIST建议对工件进行自动安全检查，以及要求所有从存储库推送和提取的外部合作者都要进行明确批准。

NIST建议在软件更新期间保持证据生成的完整性，确保代码提交的安全以及CD管道中的流程安全，因为攻击者可能会删除或篡改软件更新跟踪。

此外，为了确保代码提交不会引入恶意或易受攻击的代码，NIST建议在具有广泛语言覆盖范围的CI/CD管道中使用SAST/DAST工具，并通过SCA工具来验证OSS组件和依赖项的安全性。

最后，鉴于该行业最近出现了无数备受瞩目的秘密暴露，NIST建议各组织扫描代码中是否存在机密，如密钥或访问令牌，这些机密可能会被恶意行为者滥用。

对于软件供应链攻击的危害有多大，作为安全人员，又该如何预防，国内安全专家如此建议。

知乎相关专家“啊社”表示，针对软件供应链的攻击正以每年4-5倍的速度增长，仅在2021年就发生了几千次，危害的范围和严重性不容忽视。不仅包含在开发、交付、运行三个环节引入的安全攻击和漏洞风险，而且还包括开源软件的可持续风险，如多方依赖和开发供应商提供的代码风险。

常见的供应链攻击方式主要包括基于硬件、软件以及固件三种形式。基于硬件的攻击通常涉及使用不安全的硬件配置来托管应用程序并将其连接到用户，这可能包括预装恶意软件的设备以及可公开访问的网络设备等。基于软件的攻击主要发生在源代码、操作系统、库以及应用程序中使用的几乎所有其他软件中增加缺陷。而基于固件的攻击则是通过网络犯罪分子将恶意代码注入设备的启动代码来发起的。

“啊社”表示，软件供应链的安全犹如盖房子需要的材料，供应链、基础部分或组件的安全，决定了整体是不是安全。所以，对供应链的安全检测机制可以保证后续整体系统存在安全隐患。

某A+H股上市公司信息安全负责人孙琦表示：“从我的视角来看，软件供应链的安全管理是一个相对独立的体系，其牵涉到上下游供应链管理和供应商管理等一系列复杂场景和关系，由软件供应链问题引发的安全问题往往是一个覆盖面巨大的灾难，牵一发而动全身。”

早年solarwinds的sunburst后门引发的软件供应链危机还历历在目，孙琦表示，自己还记得当时美国财政部和商务部都牵涉其中，很多500强企业和基础电信运营商也都是其受害者。近年来，基于开源软件的漏洞问题也是我们在讨论软件供应链威胁必须重视的一个领域，log4j的漏洞直接影响了数十亿java相关的应用，最要命的是这些漏洞在没有被公开发布前是否已经被利用，是个很难说清楚的问题。

作为安全从业者，孙琦认为对于软件供应链攻击的防范还有很多事情需要完善。比如，在企业的软件生态中，上下游关系是否已经足够清晰？接口之间的调用关系是否已经完成api治理？是否已经建立了足够抵御apt的分层防御能力？

回到软件供应链攻击防御的话题，安全部门需要有自上而下的视野和担负全责的勇气，主动承担起这份责任，把涉及的业务、技术、其他支持部门拉在一起，以权责利对等方式去明确各自的责任和义务。业务bcp+技术bcp+安全bcp+综合支持bcp，合力才能将供应链攻击的风险和危害降至最低。