软件安全的新希望

本文首发公众号网络研究院,微信关注获取更多。

2021 年 12 月的Log4j 漏洞凸显了软件供应链是一个被严重忽视的安全领域。它揭示了我们的软件工件之间的相互关联程度,以及我们的系统的安全性如何取决于其最薄弱的环节。

它还强化了这样的想法:我们可能认为安全性是我们可以购买的东西,但实际上这与我们作为开发团队的运作方式有关。

从那时起,我们就一直在努力改进。

也许最值得注意的是,Google 开源的 Sigstore 项目成为软件工件事实上的签名方法,被所有主要语言生态系统采用,包括 Java、Python、Node、Ruby 等。它成为历史上采用最快的开源安全项目之一,并为开发人员提供了真实性的“蜡封”,用于确定其软件构建块的起源和出处。

2021 年 5 月白宫法令引入的软件物料清单 (SBOM) 概念仍然让人感觉遥远。这种供开发人员共享软件包中成分列表的通用语言概念具有多种新兴格式(SPDX、CycloneDX),这使事情变得复杂。

更糟糕的是,目前尚不清楚 SBOM 如何真正融入开发人员的工作流程以及开发人员在此过程中将获得哪些具体优势。

开始将所有这些整合在一起并更加紧迫地围绕软件签名、SBOM 和开发人员工作流程创建一个有凝聚力的策略是监管,这将要求对软件安全完整性进行更严格的所有权。

早在 4 月份,网络安全和基础设施局 (CISA) 就新提出的安全软件开发证明表发出了征求意见的请求,该表将让软件公司的首席执行官有责任证明他们的软件是在安全的环境中构建的,并且已经做出了善意、合理的努力来维护可信的源代码供应链。

到目前为止,“合理”的努力似乎是 FedRAMP 的容器漏洞扫描要求和美国国家标准与技术研究所的安全软件开发框架中规定的指导方针。但对新的自我证明要求的更细致、更深入的解释是在涵盖软件中纳入的第三方代码的条款中。

简而言之,软件提供商将对他们在供应链中使用的没有资金、没有维护的流行开源软件承担责任。

CISO 的这种令人眼花缭乱的考虑因素已成为许多 Twitter 梗的笑柄:

供应链工具链

这是一个有点令人震惊的,如果有必要的话,检查开源的不受限制的采用。我并不是建议公司不应该使用开源,恰恰相反。天下没有免费的午餐,包括当它被打包为免费(和开源)软件时。有人需要付费来维持维护人员的正常运转,有人需要帮助开发人员理解所有这些入站的开源软件。

Chainguard可能就是这样的人。

Chainguard 是一家由前 Google 员工领导的公司,负责 Sigstore 项目。它试图将所有这些整合到一个为开发人员提供的有凝聚力的工具链中。

该初创公司的早期工作重点是锁定构建过程,并使签名、出处和 SBOM 等功能成为软件供应链和软件构建过程的原生功能。去年,他们与 Wolfi 一起推出了第一个专门围绕供应链安全原语构建的社区 Linux(非)发行版。他们还推出了 Chainguard Images,这是独立二进制文件、nginx 等应用程序以及 Go 和 C 编译器等开发工具的基础映像。

最近,Chainguard 对其 Enforce 平台进行了另一项重大更新,将用于锁定构建系统的构建块扩展到位于开发人员和安全团队之间的工具链。

开发人员、安全专业人员甚至审计人员都需要了解部署了哪些软件包、部署在何处以及由谁部署。SBOM 旨在帮助回答这些问题以及更多问题,但环境越复杂,实现起来就越困难。

集群通常运行数百个工作负载和数百个容器映像,而每个容器映像都有数百个甚至数千个包。我们在 SBOM 方面还处于早期阶段,大多数软件包都没有附带 SBOM;它们需要被生成。

Chainguard 的目标是解决问题的两端。首先,作为 Sigstore 维护者,该公司一直在将软件签名、证明和证书管理器引入所有主要编程语言和注册表中,以便这些开源项目创建 SBOM 的方式具有统一性和一致性。在最近发布的 Enforce 中,该平台将使用 Syft 自动创建 SBOM,以便开发人员无需执行任何其他步骤即可查看每个映像的全面包信息。

新的自认证监管要求面临的最严峻挑战是容器镜像往往落后于上游更新,因此供应链仍然运行具有已知漏洞的镜像。此外,当今大多数常见漏洞和暴露 (CVE) 扫描器都使用包数据库来查看容器内安装了哪些包,但扫描器看不到安装在这些系统外部的软件。

通过让开发人员能够轻松地为尚未包含 SBOM 的软件包获取或自动创建 SBOM,Chainguard 为漏洞检测提供了保真度更高的数据集。此外,Enforce 的新漏洞扫描可以告诉团队他们是否以及在何处运行带有 CVE 的工件。

这一切来得正是时候。没有开发人员希望成为第一个弄清楚如何使用 SBOM 的人。然而他们别无选择:FedRAMP 和自我证明要求的结合正在推动对软件包和自动化流程的一致可见性的迫切需求,以查找和根除漏洞。

如果您想向美国联邦政府出售产品,SBOM 很快就会成为一项要求。但这不仅仅适用于那些向政府出售产品的人。可以合理地假设,为不安全软件分配法律责任的新自我证明模型可能会使 SBOM 成为整个科技行业的共同安全费用,或者至少对于那些不想在未来集体诉讼中被提及的软件公司而言。

猜你喜欢

转载自blog.csdn.net/qq_29607687/article/details/131970861
今日推荐