供应链安全：来源工具正在成为开发者平台的标准配置

随着组织寻求保护其供应链免受篡改的方法，并遵守 SLSA 等新兴标准，软件来源正获得新的重要性。在最近的一篇博客文章中，HashiCorp 强调了其 HCP Packer 服务如何捕获构建元数据和 SBOMs，以支持软件构件供应链安全级别（SLSA）1级合规性。

像SolarWinds和CodeCov这样的攻击显示了一个受损的构建过程如何允许恶意代码到达数千个下游用户。监管机构已经做出了回应：在美国，14028号行政命令要求联邦软件供应商提供可验证的来源，而欧洲的《网络弹性法案》（Cyber Resilience Act）也规定了类似的义务。

对于实践者来说，其含义是明确的：能够准确地证明软件是如何构建的正变得至关重要。

两个开源项目塑造了行业如何处理来源：Sigstore提供了加密签名和透明基础设施，旨在广泛采用生态系统。该模型已经在 npm、PyPI 和 Kubernetes 等主要生态系统中获得了支持，在这些生态系统中，来源验证现在越来越自动化。

in-toto采用了一种不同的方法：它通过为每一步生成签名证明来保护整个管道，在构建、测试和发布期间验证“谁在何时做了什么”。它的布局模型定义了预期的步骤和受信任的参与者，如果任何阶段被跳过或更改，篡改就会变得可见。

HashiCorp 的 Packer长期以来一直包含元数据捕获——记录诸如 CLI 和插件版本、提交 SHAs 和 CI/CD 管道上下文等详细信息。最近它增加了 SBOM 生成。改变的是定位：HashiCorp 现在将这些特性作为核心来源功能呈现，强调 HCP Packer 可以为团队提供一个开箱即装的合规开端。

在这个领域，Packer 并不孤单。GitHub 在其 Actions 平台中引入了构件证明和SBOM生成，允许团队生成与 SLSA 规范一致的签名出处。红帽的 Konflux 是一种基于 kubernetes 的构建服务，在其管道中发布in-toto证明，将其与策略执行联系起来，形成一个完整的信任链。

这种定位强调了供应商仍然依赖于 OSS 工具来遍历 SLSA 框架的各个层次。更高的级别需要更强的保障。2 级要求签名的、防篡改的来源，Sigstore 的签名和透明日志是一个自然的选择。3 级和 4 级添加了经过验证的源代码控制和隔离的构建环境，在这些环境中，in-toto 的认证有助于确保每个管道步骤都遵循策略。

尽管有越来越多的人支持，但采用并不简单。来源格式仍在不断演变，SBOMs通常根据工具或生成阶段的不同而有很大差异，这使得比较和验证变得复杂。此外，一项分析了 233 个存储库中的 1523 个 GitHub 问题的定性研究发现，从业者在采用 SLSA 框架时面临着重大的障碍，其中包括需求和流程的“复杂实现”和“不清晰沟通”

对于工程团队来说，这些好处是实用的，也是规范性的。来源提供了构建过程的更清晰的图像，有助于调试、事件响应和审计准备。

来源越来越多地被内置为一个标准功能，而不是附加组件。像 Sigstore 和 in-toto 这样的开源项目继续定义通用实践，而供应商正在将来源集成到他们的平台中，以使其更容易采用。保证的级别仍然各不相同，但使用范围正在扩大到整个软件供应链中。

原文链接：

https://www.infoq.com/news/2025/08/provenance/