使用SLSA框架保障软件供应链安全
自2020年SolarWinds事件以来,软件供应链安全成为热点话题。得益于"软件构件供应链层级"(SLSA)框架,软件行业正站在可持续解决开源软件安全构建和分发重大挑战的门槛上。
SLSA概述
SLSA 1.0规范定义了三个合规等级(SLSA构建级别1/2/3),通过发布适当的构建溯源文件实现。该文件标识构建平台(通常是托管CI/CD平台如GitHub Actions或Google Cloud Build)及生成最终构件的配置参数。对于GitHub Actions构建,溯源文件会包含工作流定义文件、构建的代码库和标签,以及触发构建的拉取请求ID等输入参数。平台还应尽力列出项目的所有直接和间接依赖项。
- 级别1:提供构建过程可见性以发现无心之过,只需包含上述数据并发布在可访问位置
- 级别2:确保构建溯源文件的真实性,要求文件必须由构建平台签名,并在专用基础设施上运行
- 级别3:通过额外平台强化防止伪造溯源文件,构建过程用户定义步骤不能访问签名密钥,且构建间不能相互影响
关键集成:PyPI中的PEP 740提案
Trail of Bits工程师起草的PEP 740规范草案为PyPI添加SLSA溯源支持。借助现有的可信发布机制,每个包的构建平台通过OIDC令牌为PyPI上传提供信任机制。溯源文件可利用相同OIDC令牌通过Sigstore生成无密钥签名,随包上传至注册表。该设计将攻击面缩小到仅两种可能:破坏包源代码或伪造GitHub OIDC令牌。
消费者如何利用SLSA
开发团队无需等待PEP 740完全实施即可逐步获益:
- npm生态已深度集成SLSA支持,
npm audit signatures
命令可自动验证依赖项的溯源 - 对于其他包管理器,可通过
slsa-verifier
工具手动验证发布资产中的溯源文件 - OCI兼容容器注册表允许将溯源文件作为制品上传,但缺乏标准化验证方式
实施建议优先级:
- 首先配置容器镜像验证
- 为每个新二进制依赖项实施SLSA检查清单
- 建立长期工作流为现有依赖项添加验证
- 要求上游供应商提供SLSA溯源
构建安全软件供应链的未来
理想状态是生态系统深度集成构建溯源,使包管理器能自动安全运作。在此之前,SLSA合规项目应明确定义策略,确保用户知晓何时应拒绝构件。关键建议:
- 若非使用官方SLSA溯源生成器,需告知消费者如何验证签名来源
- 在文档中包含强制性的验证说明
- 对软件供应商和消费者进行双向教育
我们的应用安全团队可帮助开源项目审计构建过程,也可协助企业更新依赖管理流程以最大化利用现有SLSA支持。如需帮助,欢迎联系我们!