共计 4963 个字符，预计需要花费 13 分钟才能阅读完成。
在软件开发中所面临的新型威逼曾经不仅仅与特定的公司相干，整个软件供应链的上下游都已成为攻击者的指标，因而必须保障每个环节的安全性，因为如果一个环节呈现问题，所有都会受到影响。
供应链流动包含将原材料、部件和资源转化为残缺产品并交付给最终客户的每一步。每个步骤自身都可能是一个简单的过程，并且有可能导致安全事故。
什么是软件供应链攻打？
咱们在之前的文章中曾经分明地理解到什么是软件供应链。那么咱们当初持续深刻，将重点放在源代码上。
举个例子，你的源代码将存储在公有的 Git 仓库中，这可能是你的基础设施的一部分，也可能是供应商提供的 SaaS，还有编译器工具、根底容器镜像仓库等。而一些依赖项则托管在公开的代码库中，如 Docker Hub 或 Quay.io，可能会受到损坏。此外，咱们也将咱们的应用程序作为容器镜像公布在公开的代码仓库中。
那么，在供应链中其中一些组件在你的爱护之下，比方你的公有源代码 git 仓库、利用程序代码自身以及最终生产进去的二进制文件或容器镜像。但许多其余的组件或服务是公开的服务和资源，或是由其余公司提供的，齐全不在你的掌控范畴之内。
所以软件供应链攻打能够间接瞄准你的软件，或它能够瞄准任意上游组件（比方内部的依赖项或第三方服务），进而你会成为受害者，要么间接蒙受攻打，要么成为提供受损资源的供应商。
软件供应链攻打事件
针对软件供应链的攻打正以每年 4 - 5 倍的速度增长，仅在 2021 年就产生了几千次，最常见的是与依赖项混同或误值域名（URL 劫持）无关的谬误，其次是歹意源代码注入。
侥幸的是，并不是每次攻打都有微小的影响范畴，下文咱们将会介绍其中几个较为出名的攻打事件。CNCF 还在其《供应链毁坏目录》中收集了各种类型的供应链蒙受攻打的事例：
https://github.com/cncf/tag-s…
CodeCov 源代码泄露
具体信息：https://about.codecov.io/secu…
CodeCov 是一款用于托管代码测试报告和数据的在线平台，2021 年其 Docker 镜像中泄露的凭证使攻击者能够批改一个 bash 脚本。当客户下载并执行该脚本之后，客户的凭证会被泄露，进而攻击者能够拜访他们的 Git 仓库。攻打从当年的 1 月 31 日开始，而第一个客户发现凭证蒙受泄露时已是 3 个月之后，这意味着被入侵的软件在长达数月的工夫里失常与上下游对接。Hashicorp、Confluent 等多个知名企业示意受到影响。
SolarWinds 黑客攻击
攻击者渗透到 SolarWinds 的网络中，并设法将恶意软件注入其构建过程。该恶意软件（与 APT29、Nobelium 无关）与 Orion（某个网络管理系统）捆绑在一起，作为产品更新的一部分散发。该 Artifact 通过数字签名，作为构建过程的一部分被数百名客户下载。
一旦恶意软件进入客户网络，攻击者就会监督并窃取他们的信息。这一事件也展现了针对供应链的攻打是如何向上游流传并影响到多个客户。作为被毁坏的 Orion 软件的一部分，Mimecast（一家云网络安全服务公司）的邮件服务器的 TLS 证书私钥被泄露，这使得攻击者能够对邮件服务器进行中间人攻打，进而拜访客户的电子邮件取得敏感信息。
咱们可能永远也无奈理解到 SolarWinds 攻打所产生的真正影响，因为被攻打的软件在有成千上万客户的网络中运行了数月。该事件尚未完结：SolarWinds 背地的攻击者最近仍在试图复制相似的攻打，不过是针对供应链的不同局部，如代理商和某些技术服务提供商。
Kaseya 勒索软件攻打
具体信息：
https://helpdesk.kaseya.com/h…
2021 年 7 月，近程 IT 服务管理软件 Kaseya 蒙受勒索软件攻打，攻击者索要 7000 万美元。这次攻打与 SolarWinds 攻打非常相似，但这次攻击者利用 Kaseya 零碎中的零日破绽。一旦他们管制了零碎，他们就能够应用 VSA、远程管理和监控工具在客户的零碎中执行近程命令。
大概有 50 个客户受到此次攻打的间接影响。但他们的很多客户都是托管服务提供商，专门为其余企业提供 IT 服务，所以 Kaseya CEO Fred Vocola 示意，理论受到影响的企业约达到 800 至 1500 家。
更为要害的事实是，在 2017-2020 年期间，Kaseya 的高管屡次收到正告，这些正告称产品存在重大的安全漏洞，但公司高管对此不以为意。
苹果公司的 Xcode 和 XcodeGhost
在这次攻打中，一个非法的 Xcode 我的项目 “TabBarInteraction “ 的木马版本被公布在一个公开的代码仓库中。应用该我的项目虚伪版本的开发人员在每次我的项目构建时都会无心中执行一个脚本，该脚本会关上与 C2（命令和管制）服务器的连贯。
带有恶意代码的 Xcode 的从新打包版本被上传到中国的文件托管服务。开发人员从这些镜像中下载被毁坏的版本，最终失去的是一个批改过的对象文件。在创立 iOS 应用程序时，该对象文件被连贯到最终的可执行文件中。至多有 2 个出名的应用程序胜利通过了苹果的官网认证和代码审查，最终进入了 AppStore。
NPM 包 ua-parser-js
2021 年 10 月 22 日，阿里云平安团队监测到 Npm 官网仓库 ua-parser-js 疑似被歹意劫持，多个版本被攻击者植入挖矿脚本，其中蕴含 Linux 和 Windows 的恶意软件，并且可能窃取数据（至多是浏览器的明码和 cookies）。
这个 ua-parser-js 库是泛滥出名软件和企业的供应链的一部分，例如 Facebook、微软、苹果、亚马逊等大型科技公司对其均有依赖。因而它会被用于面向用户的终端应用程序中，从而扩散到数百万台计算机。
Unicode 和代码编译器——看不见的破绽
剑桥大学的一些钻研人员示意，他们在文本编码标准（如 Unicode）的细节中发现了一种针对源代码的新型供应链攻打。依据 Unicode 的工作形式，有可能再代码的正文或某些局部增加特殊字符，使代码的“逻辑编码”以与显示方式不同的程序工作。这使得在一些开起来是正确的代码中暗藏恶意代码成为可能，从而绕过审查程序。但该问题并非新问题，也并不是那么荫蔽，通过建设对代码贡献者的信赖并进行适当的审查来预防该类型的攻打。
WordPress 主题和插件攻打
2021 年 9 月有钻研人员发现，超过 90 个 WordPress 主题、插件被毁坏，攻击者在这些组件中植入了 PHP 后门，使其可能齐全拜访网站。有超过 36 万个的沉闷网站都在应用这些插件和主题。
据钻研人员称，攻击者应用后门将访问者重定向到恶意软件投放和欺骗网站，也有可能应用该恶意软件在暗网上发售对后门网站的拜访权限。
Apache Log4j 高危破绽
2021 年 12 月，Apache 软件基金会公开 Apache Log4j2 被曝出高危破绽，攻击者通过 JNDI 注入攻打的形式，能够近程执行任何代码。破绽发现以来，Steam、苹果的云服务受到了影响，推特和亚马逊也蒙受了攻打，元宇宙概念游戏“Minecraft 我的世界”数十万用户被入侵。美联社评论称，这一破绽可能是近年来发现的最重大的计算机破绽。
而这一破绽并非短时间内就能齐全解决，其影响可能蔓延至将来十年。因为 Log4j2 是一个十分风行的、基于 Java 的开源日志框架，它曾经被嵌入成千上万的软件包中。雪上加霜的是，Log4j 常常被深深地嵌入到代码中，因为被间接的依赖项所调用而暗藏起来。
如何保障软件供应链平安
针对软件供应链的攻打使得企业受攻击面在扩充，因为它们的安全性不仅取决于外部审查流程，还须要确保第三方（软件、硬件、服务等）不会成为他们被攻打的通道。
因而，不可能像传统平安一样确保所有代码、组件都是平安的，尤其是当下咱们仍在一直发现新型的软件供应链攻打。
接下来，咱们一起讨论一下，如果要尽可能地爱护企业软件供应链，你须要把重点放在哪里。
关注软件开发中的第三方组件
如果您的组织采纳了来自多个供应商的构件、硬件和服务，那么须要确保这些供应商对平安都放弃高度重视。
软件供应链平安正在变得如此重要，以至于 2021 年 5 月，美国总统公布了一项旨在改善国家网络安全的行政命令。尔后，NIST 依据这一命令公布了《开发者软件验证最低标准指南》，其中倡议了开发者验证软件的最低标准。
因为不可能实现和保障 100% 的平安，所以也须要你关注影响供应商的任何危险和事件，并筹备好在发现或报告受毁坏的组件时迅速采取纠正措施，以缩小损失。
公司外部软件开发的安全意识
对于代码和开发过程，上文中所提到的“最低标准指南”中倡议软件开发生命周期中须要蕴含以下技术作为其最低的平安要求：
- 利用威逼模型以辨认要害或潜在的被忽视的测试指标
- 自动化测试
- 基于代码的动态剖析，应用代码扫描工具并且审查硬编码的密钥
- 动态分析、内置查看、保护措施、黑箱和含糊测试以及网络应用扫描工具等
- 对于供应链中的软件进行相似性查看（包含第三方依赖项）
- 尽快修复重要破绽
随着基础设施即代码（IaC）的呈现，软件供应链中的威逼当初有可能针对软件、应用程序以及底层基础设施。同样的软件验证准则应实用于部署和治理作为代码的基础设施，实现“平安左移”。
仅确保代码和开发过程的平安是远远不够的，还须要让平安必须在所有的开发阶段和公司文化及实际中普遍存在。
CNCF 社区保留了一份实时更新的、由社区保护的文件，软件供应链平安文件。该文件旨在通过“一系列举荐的实际、工具选项和设计思考，来缩小供应链攻打的可能性和整体影响”，为社区做出奉献。
文件地址：
https://github.com/cncf/tag-s…
此外，CNCF、Linux 基金会、VMWare、英特尔、谷歌和其余机构也在钻研 SLSA，这是一个软件供应链平安框架，用于进步软件的安全性和供应链的完整性，能够供任何开发软件的人应用。该框架中的每个级别都提供了越来越高的信任度，阐明软件没有被篡改，能够平安地追溯到它的起源。
Kubernetes 和容器在企业中利用也非常宽泛，NSA/CISA 公布了 Kubernetes 加固指南，强调“供应链危险”是三个泄露源之一，并提出了以下加固措施和缓解方法：
- 扫描容器和 Pod 的破绽或谬误配置
- 以尽可能小的权限运行容器和 Pod
- 应用网络隔离来管制歹意毁坏可能造成的侵害水平
- 最初，借助防火墙限度不须要的网络连接和加密以爱护机密性
- 应用弱小身份认证和验证来限度用户和管理员的拜访并批改攻击面
- 最初，应用日志审计使管理员能够监控流动并且在发现潜在的歹意行为时收到告警
- 周期性查看所有 Kubernetes 设置并且应用破绽扫描来帮忙确定危险等级，并利用安全补丁
你的软件须要对上游平安负责
当你在抉择供应商时，你应该意识到你不仅仅是为本人抉择，也是在为你的客户、终端用户进行抉择。因而，即便你在软件供应链生命周期的每个步骤和流程中都严格地施行了安全策略，你依然须要将其体现进去并为交付的产品增加具体的安全措施：
- 提供您的组织内实用于软件供应链的监管合规性和平安认证的证据
- 减少一个软件资料清单（SBOM），以跟踪软件中的依赖项和第三方侵害源
- 包含数字签名，以避免篡改和验证你的工件起源
- 应用平安的散发渠道、加密的通信和可信的托管或存储基础设施
总 结
软件供应链攻打并非新兴事物。在 1984 年与丹尼斯·里奇一起取得图灵奖后，肯·汤普森写了一篇对于信赖代码提供商的重要性的演讲。他展现了一个木马化的编译器二进制版本如何产生带有后门的“login”Unix 命令的批改版本。
“人们应该在多大程度上置信一个程序没有特洛伊木马的申明？兴许置信编写软件的人更重要。”
随着软件、基础设施和依赖项的复杂性一直减少，以及针对供应链的攻打事件在指数级增长，使得各行业和组织越来越关注软件供应链的安全性。
你应该曾经意识到软件供应链是一个极其简单的网络，从代码和库到硬件组件，都是相互连接但实质不同的事物。因而，确保每一个单件和环节安全性的办法是不同的，不能作为一个对立的整体来看待。
无论你是甲方还是乙方，是终端用户还是服务提供商，你都须要专一于爱护你的流程，并且与可信赖的、通过验证的供应商建设弱小的分割。因为即便你驳回了最佳的平安实际，并在代码、基础设施等方面投入了全副精力，你依然依赖于齐全不受管制的第三方组件。而软件供应链的平安取决于每一个独自的环节。
