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

105 阅读7分钟

安全团队需要一套标准的流程来锁定软件工件的信任根基,而开发者需要一条清晰的路径来平衡开源选择和安全政策。开放源码有答案。

谁拥有软件供应链的安全?开发人员?还是支持他们的平台和安全工程团队?

在过去,CIO、CISO或CTO和他们的安全团队会决定公司将从哪个Linux发行版、操作系统和基础设施平台获得支持合同和安全SLA。今天,开发人员在Docker Files和GitHub Actions中完成这一切,而且没有像以前那样的组织监督,事情转移到开发人员身上。

今天,合规性和安全团队定义了政策和更高层次的要求,而开发人员可以灵活地选择他们想要的任何工具,只要它满足这些要求。这是一种关注点的分离,大大加快了开发人员的工作效率。

但正如我之前所写的,Log4j是一盆冷水,让企业意识到系统性的安全问题。即使在所有这些向左转的开发人员的自主权和生产力的好处中,构成其软件供应链的开源组件已经成为坏蛋最喜欢的新目标。

开源对开发者来说是好事,对攻击者来说也是好事

对攻击者来说,网络安全已经成为一个比以前更困难的攻击媒介。 但是开源呢?只要找到一个开源的依赖或库,以这种方式进入,然后再转向所有其他的依赖。供应链实际上是关于组织和他们的软件工件之间的联系。而这正是今天攻击者所乐此不疲的地方。

开放源码软件对开发者来说是很好的,这也使它对黑客来说是很好的。

它是开放的

开发人员喜欢。任何人都可以看到代码,任何人都可以对代码做出贡献。Linus Torvalds有句名言:"眼高手低",这也是开放源代码的一大好处。越多的人看东西,就越有可能发现错误。

攻击者喜欢。任何拥有GitHub账户的人都可以为关键库贡献代码。恶意的代码提交经常发生。库被接管并转移到不同的所有者手中,而这些所有者并没有把所有人的利益放在心上。

一个著名的例子是名为 "大吊带 "的Chrome插件。维护它的人把它交给了其他人,后者立即开始插入了恶意软件。这种从善意的贡献者变为恶意的贡献者的例子很多。

它是透明的

开发人员喜欢。如果有问题,你可以看一下,找到它们,并审计代码。

攻击者喜欢。大量的开放源代码使得代码审计变得不切实际。另外,很多代码的分发方式与它的实际消费方式不同。

例如,即使你看了Python或Node.js包的源代码,当你运行pip installnpm install ,你实际上是从被编译的内容中抓取一个包,而且不能保证这个包确实来自你审计的源代码。

根据你消费源代码的方式,如果你不是每次都真正抓取源代码并从头开始编译,那么很多透明度可能是一种假象。一个著名的例子是Codecov漏洞,安装程序是一个bash脚本,它被破坏并被注入了恶意软件,从而窃取了机密。这个漏洞被用来作为其他可以被篡改的构建的支点。

它是免费的

开发人员喜欢。开放源码带有一个许可证,保证你能够自由使用别人编写的代码,这很了不起。这比通过采购来获得软件的内部改进要容易得多。

攻击者喜欢。2014年的Heartbleed攻击是第一个警钟,表明互联网的关键基础设施有多少是靠志愿者的工作来运行的。另一个著名的例子是一个名为Jwt-go的Golang库。这是一个在整个Golang生态系统(包括Kubernetes)中非常受欢迎的库,但当它被发现有漏洞时,维护者已经不在了,无法提供修复措施。这导致了混乱,人们用不同的补丁分叉来修复这个漏洞。有一次,同一个漏洞有五六个相互竞争的补丁版本,都在依赖关系树上打转,最后出现了一个补丁,永远修复了这个漏洞。

开放源代码对软件供应链安全也很有帮助

让所有这些环节变得更强大的唯一方法就是合作。而社区是我们最大的优势。毕竟,开源社区--所有投入时间和精力并分享他们的代码的项目维护者--使开源在整个行业和每个人的供应链内普遍存在。我们可以利用同样的社区,开始确保供应链的安全。

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

SLSA

SLSA(Supply chain Levels for Software Artifacts,发音为 "salsa")是一套关于构建系统安全的规定性、渐进性要求。有四个级别,由用户来解释和实施。第1级是使用一个构建系统(不要在笔记本电脑上手工操作)。第二级是输出一些日志和元数据(这样你就可以在以后查找东西和做事件响应)。第三级是遵循一系列的最佳实践。第四级是使用一个真正安全的构建系统。

Tekton

Tekton是一个开源的构建系统,设计时考虑到了安全问题。很多构建系统的运行方式都是安全的。Tekton是一个很好的默认值的旗舰例子,其中有SLSA的烘托。

In-Toto

In-Toto和TUF(如下图)都来自于纽约大学的一个研究实验室,比任何人谈论软件供应链安全的时间都早。他们记录了在供应链中发生的一系列确切的步骤,并将可以根据政策进行验证的加密链连接在一起。In-Toto专注于构建方面,而TUF专注于分发方面(是否被篡改?)

TUF

TUF(The Update Framework)处理自动更新系统、软件包管理器、分发以及通过法定人数签字的维护者集合。TUF还擅长在坏事发生时进行加密密钥恢复。

Sigstore

Sigstore是一个免费且简单的代码签名框架,用于开源软件工件。签名是一种建立可加密验证的监管链的方式,也就是软件来源的防篡改记录。

为软件供应链提供更好的护栏

在过去的10年里,工具安全的选择都转移到了开发者身上。我相信我们会看到开发人员继续保持他们在选择最佳工具方面的自主权,但管理安全态势和相关政策的责任需要重新转移到右边。

一个常见的误解是,安全团队整天都在逐行审查代码,寻找安全漏洞,确保没有漏洞。这根本不是它的工作方式。安全团队比开发者团队小得多。他们的工作是建立流程,帮助开发人员做正确的事情,并消除各类漏洞,而不是一次一个安全漏洞。这是安全团队跟上数百名工程师团队的唯一方法。

安全团队需要一套标准的流程来锁定软件工件的信任根基,而开发者则需要一个清晰的路径来平衡开源选择和明确定义的安全政策。开放源码提出了问题,而开放源码将帮助找到答案。有一天,开发人员将只部署经过审查以防止已知漏洞的图像。