软件供应链安全白皮书总结
执行摘要
软件供应链是软件开发组织的关键组成部分，但 Solarwinds 攻击、Log4J 漏洞、xz 后门和 tj-actions 供应链攻击等事件表明供应链容易受到攻击。实施安全的软件供应链工具和实践可以提高可见性和透明度，降低风险。云原生公共部门用户组致力于通过推广安全、弹性的云原生软件来提高公共部门工作流程和供应链安全。
问题陈述
公共部门用户组希望利用安全的软件供应链 (S3C) 工具来保护软件开发生命周期。目标是利用开源维护者的 S3C 工作，使其易于被政府、中小企业和大型实体采用，并实现公共部门内部合作伙伴之间的信任和透明度。此外，还需要符合 NIST 标准和其他国际标准。
攻击向量
常见的软件供应链攻击向量包括：
- 依赖混淆
- 拼写错误
- 维护者受感染
- 构建服务器受感染
- CI/CD 管道中的代码注入
- 后门依赖
目标受众和期望成果
白皮书针对三类受众：
- 软件维护者和注册表运营商，倡导在软件发布中包含 SBOM、VEX 和 SLSA 证明等供应链相关工件。
- 政府组织，建议提供类似开源社区“公共产品”的基础设施，支持安全软件交付。
- 公共部门实体，提供一个参考架构，利用新工件保护软件供应链。
公共部门面临的挑战
公共部门组织在供应链安全方面面临诸多挑战，包括严格的采购要求和监管框架，以及地缘政治环境的不确定性。此外，还需要准备符合 NIST SP 800-204D 要求的供应链安全实践。
软件注册表
建议软件注册表（如 Maven、PyPI）除了分发软件工件外，还应托管和分发供应链相关工件（如 SBOM、SLSA 和 VEX 工件），并支持数字签名和可信发布者机制。
供应链参考架构
架构分为三个阶段：
- 建立信任：利用 NIST SP 800-63 指南建立数字身份管理，包括身份证明、认证和联盟，重点关注工作负载身份而非开发者身份。
- 生成 S3C 数据：收集和分析依赖项数据，生成 SLSA 构建证明和验证摘要证明，使用 Tekton、Witness、GitHub Actions 或 GitLab Runners 等工具。
- 共享 S3C 数据：使用 Harbor、Zot 或 Distribution 等工具安全存储和共享软件工件，并使用 Archivista 存储证明，利用 TUF 框架保护更新机制。
验证和分析 S3C 数据
消费者应采取两阶段方法确保安全阈值：
- 验证：使用 cosign 验证下载的依赖项工件。
- 分析：使用 Guac、DependencyTrack 和 CI/CD 管道等工具分析依赖项，并利用 OPA 和 OSCAL 等工具进行策略执行。
技术实施
白皮书提供了详细的技术实施图，推荐了具体工具和技术，包括：
- 构建管道：Tekton、Witness
- 政策执行：OPA、政策控制器
- 依赖项映射和分析：Guac、DependencyTrack
- 注册表/存储库：Harbor、Zot、Distribution
- 证书颁发：父证书机构
- 证明：Sigstore、Witness
采用路线图
- 政府承包商首先在内部采用消费者侧架构。
- 政府建立必要的基础设施，允许承包商之间安全共享 S3C 工件。
- 承包商使用政府提供的基础设施共享 S3C 信息。
结论
白皮书提出了一个灵活的架构，以应对不断变化的透明度需求，同时保持安全和运营完整性。政府应提供基础设施支持，软件注册表应提供对 S3C 工件的原生支持，公共部门组织应采用标准和联邦基础设施以确保身份、联盟和加密要求。
