Log4J等软件供应链中的安全问题有解吗？

译者 | Ethan

Log4J这盆冷水，让大多数开发人员意识到他们的软件供应链安全问题。 我们的构建环境并不像我们的生产环境那样安全。

几十年以来，大大小的公司都把注意力聚焦在软件构建和各自的生产环境上，很少意识到这一切是基于未打补丁的Jenkins盒子上构建的。我们把大部分时间都花在保护“运行时”，然后使用业余工具部署到它们。

这就是在过去12个月中导致大量高调攻击的原因，从SolarWinds到Codecov攻击，再到Travis CI机密泄露。虽然我们的基础设施方面做得非常好，但却让攻击者寻找到更简单的方法进入，并在我们在供应链中敞开的大门中找到了它。

无法通过周边安检进入？只需找到一个开源依赖项或库，然后就可以了。然后转向所有客户。这是现代软件供应链黑客。

PART 01

软件也需要有信任的根基

人们之间有信任的根源。我们有双重身份验证，我们有识别系统。这些都是证明一个人身份的东西。硬件也有同样的东西。我们有加密密钥。我们有我们可以相信的硬件在启动时没有被篡改。

即使作为互联 用户，我们也有信任的根源。我们有URI、URN和URL——也就是互联 上连接我们所浏览站点的身份、名称和位置的命名空间；SSL证书则表明浏览器 站是安全的；DNS防火墙位于用户的递归解析器之间，以确保我们的缓存没有被错误的请求加载。所有这一切都发生在幕后，几十年来在支持数十亿互联 用户方面取得了令人难以置信的效果。

但是我们今天没有这个用于软件工件。

PART 02

开发人员过于隐晦地信任

开发人员经常把许多事情委托给不同的人员和系统，却没有意识到其中的风险。因为其中的每一个环节都可能被篡改或攻击，或者甚至可能是恶意的。

举一个当下开发者习以为常的例子：从云原生计算基金会(CNCF)Artifact Hub安装Prometheus（目前非常流行的开源可观察性项目）。技术人员安装完Helm，然后查看所有被拉取且开始运行的集群镜像，就会发现：许多容器镜像最终都是通过一个简单的安装运行开始的。

这与“零信任”是完全相悖的——我们信任几十个我们一无所知的系统。

我们也信任操作存储库的人。因此，如果存储库运营商遭到入侵，那么现在这些入侵者也就成为了“信任圈”的一部分。任何控制这些存储库之一的人都可能改变某些东西并发起攻击。

然后是构建系统。构建系统可能会受到攻击并被注入恶意代码。2020年，SolarWinds软件供应链入侵事件就是一件值得让人警醒的事情（SolarWinds是一家生产名为Orion的 络和应用程序监控平台的公司，然后使用该访问权限生成木马化更新并将其分发给软件用户）。

即使你信任镜像的运营商以及运行托管图像的系统的人员，如果这些系统的构建不安全，一样存在被注入恶意软件的风险。而且这种风险一直是可传递的。依赖关系维护者以及他们使用的构建系统、所在的工件管理器——它们都会被破坏掉。

因此，当开发人员安装软件包时，他们无选择地信任了很多东西，无论他们是否有这些目的。

PART 03

软件供应链安全陷阱

在软件供应链安全中，最糟糕的策略就是什么都不做，这也是当今许多开发人员正在做的事情。他们允许任何东西在生产环境中运行。更为危险的是，如果缺失对可以运行的工件的安全性，就意味着不知道它们来自哪里。

下一个陷阱则是允许列出特定标签。如果您通过一些关于Kubernetes最佳实践的教程，这很容易设置。如果将所有镜像都推送到一个位置，开发者至少可以将内容限制在该位置。这比什么都不做要好得多，但这依旧不够，因为任何被推到那里的东西现在都会被默认放在信任圈内，这并不是真正的零信任。“允许列出特定存储库”和“允许列出特定标记”具有相同的限制。

甚至供应链安全中的签名模式也在解决同样的问题。任何被签名的东西现在都可以运行，无论它来自哪里，这会导致大量的攻击，这类攻击大多涉及欺骗某人签署伪造协议或无法撤销证书等。

PART 04

是时候开始提出正确的问题了

假设走在办公室外的人行道上，发现地上有一个USB ，绝对不应该将它带入办公室并将其插入工作站。世界各地的安全组织都将这一警告作为培训的一部分。

同样地，像docker pull，npm install之类的命令，大多数开发者甚至想都不想就运行了，即使这种情况必比插入捡来的USB更糟糕。它们都可能会从不被信任的人那里获取代码并运行，但Docker容器或NPM包最终会将一路进入生产环境中！

安全团队需要一套标准流程来锁定软件工件的信任根，开发人员需要一条清晰的路径来平衡开源选择与安全策略。开源或许是个答案。

PART 05

如何解决软件供应链安全问题

谁该具备软件供应链安全？开发商？还是支持他们的平台和安全工程团队？

过去，CIO、CISO或CTO及其安全团队将决定公司将从哪个Linux发行版、操作系统和基础设施平台获得支持合同和安全SLA。今天，开发人员在Docker Files和GitHub Actions中完成这一切，并且在事情交给开发人员之前存在的那种组织监督已经不复存在了。

今天，合规和安全团队定义了策略和更高级别的要求，开发人员可以灵活地选择他们想要的任何工具，只要它满足这些要求。这是一种“关注点分离”的做法，极大地提高了生产力。

即使在所有“左移”的开发人员自主权和生产力优势中，构成其软件供应链的开源组件也已成为恶意攻击者“青睐”的新目标。组织依旧需要意识到系统性安全问题，Log4J漏洞就是一个例证。

PART 06

开源非常适合开发人员，也适合攻击者

对于攻击者而言， 络安全已成为比以往更加困难的攻击媒介。但是开源？只需找到一个开源依赖项或库，以这种方式获取，然后转向所有其他依赖项。供应链实际上是关于组织及其软件工件之间的链接。这就是攻击者今天玩得很开心的地方。

使开源软件对开发人员如此出色的原因也使其对黑客如此出色。

它是开放的

开发人员喜欢：任何人都可以看到代码，任何人都可以为代码做出贡献。Linus Torvalds有句名言：“许多眼球使所有错误变得浅薄”，这是开源的一大好处。人们看东西的次数越多，发现错误的可能性就越大。

攻击者喜欢：任何拥有GitHub帐户的人都可以向关键库贡献代码。恶意代码提交经常发生。图书馆被接管并转移给没有考虑到每个人的最佳利益的不同所有者。

一个著名的例子是名为The Great Suspender的Chrome插件。维护它的人把它交给了其他人，后者立即开始插入恶意软件。这种从善意的贡献者到恶意贡献者的变化有很多例子。

它是透明的

攻击者：大量的开源使代码审计变得不切实际。此外，许多代码分布在与实际使用方式不同的源中。

例如，即使您查看Python或Node.js包的源代码，当您运行pip installor时npm install，您实际上是从已编译的内容中获取一个包，并且不能保证该包实际上来自源代码你审计的。

根据您使用源代码的方式，如果您实际上不是每次都在获取源代码并从头开始编译，那么很多透明度可能是一种错觉。一个著名的例子是Codecov漏洞，其中安装程序是一个bash脚本，该脚本被入侵并注入了可以窃取机密的恶意软件。这个漏洞被用作其他可能被篡改的构建的枢纽。

免费

开发人员：开源附带一个许可证，保证您能够自由使用其他人编写的代码，这太棒了。这比必须通过采购来获得内部改进的软件要容易得多。

攻击者：2014年的Heartbleed攻击是第一次敲响警钟，会显示互联 的关键基础设施有多少是靠志愿者工作运行的。另一个著名的例子是一个名为Jwt-go的Golang库。它是一个在整个Golang生态系统（包括Kubernetes）中使用的非常流行的库，但是当在其中发现漏洞时，维护者不再提供修复。这导致了混乱，人们使用不同的补丁来修复错误。在某一时刻，同一个错误有五六个竞争补丁版本，所有这些都在依赖关系树中运行，直到一个补丁最终出现并永久修复了该漏洞。

PART 07

开源也非常适合软件供应链安全

使所有这些链接更加牢固的唯一方法是共同努力。 区是我们最大的力量。毕竟，开源 区——所有投入时间和精力并共享代码的项目维护者——使开源在整个行业和每个人的供应链中无处不在。我们可以利用同一个 区来开始保护该供应链。

如果你有兴趣关注这个软件供应链安全领域的发展——无论你是开发人员，还是平台或安全工程团队的成员——这些都是你应该关注的一些开源项目：

SLSA

SLSA（Supply chain Levels for Software Artifacts，软件工件的供应链级别，发音为“salsa”）是一套规定的、渐进的构建系统安全要求。用户解释和实现的有四个级别。

Tekton

Tekton是一个在设计时考虑到安全性的开源构建系统。许多构建系统可以以安全的方式运行。Tekton是内置SLSA的良好默认设置的旗舰示例。

In-Toto

In-Toto和TUF都来自纽约大学的一个研究实验室，早在人们谈论软件供应链安全之前几年就已诞生。他们记录了供应链中发生的确切步骤集，并将可以根据策略验证的加密链连接在一起。In-Toto专注于构建方面，而TUF专注于分发方面（是否被篡改）。

TUF

TUF处理自动更新系统、包管理器、分发和通过仲裁签名的维护者集。TUF还专门研究发生故障时的加密密钥恢复。

Sigstore

PART 08

更好的软件供应链防护栏

在过去10年中，工具和安全性的选择都向开发人员转移。我相信我们将看到开发人员继续保持他们在选择最佳工具方面的自主权，但管理安全态势和相关政策的责任需要转回正确的方向。

一个常见的误解是，安全团队每天都在逐行审查代码以发现安全漏洞并确保没有漏洞。这根本不对。安全团队比开发团队小得多。他们在那里建立流程来帮助开发人员做正确的事情并消除漏洞类别，而不是一次一个安全漏洞。只有这样，安全才能跟上数百名工程师团队的步伐。

安全团队需要一套标准流程来锁定软件工件的信任根，开发人员需要一条清晰的路径来平衡开源选择与明确定义的安全策略。

开源提出了问题，开源也将有助于找到答案。有一天，开发人员有望可以通过部署经过审查的镜像以防止漏洞攻击。

原文链接：

https://www.infoworld.com/article/3663689/software-developers-have-a-supply-chain-security-problem.html

https://www.infoworld.com/article/3663689/software-developers-have-a-supply-chain-security-problem.html

Dan Lorenc是Chainguard的CEO兼联合创始人。此前，他是Google开源安全团队(GOSST)的高级软件工程师和负责人。他创立了Minikube、Skaffold、TektonCD和Sigstore等项目。