利用SLSA框架保障软件供应链安全
自2020年SolarWinds安全事件以来，软件供应链安全一直是热点话题。得益于软件构件供应链层级（SLSA）框架，软件行业正站在可持续解决开源软件安全构建和分发重大挑战的门槛上。
SLSA概述
SLSA是一项安全标准，帮助消费者验证开源软件构件的创建过程。其核心是来源证明文件——由构建平台签名的文档，证明二进制文件、容器镜像或其他文件如何通过项目特定的构建流水线从源代码生成。不过SLSA仍是相对较新的标准（1.0版于2023年4月发布），要充分发挥其效益，需要多方采纳和实施。
为加速SLSA采用，我们起草了PEP 740规范，为PyPI添加SLSA来源证明支持并利用可信发布的力量。但无需等待所有工作完成就能享受SLSA的好处。
SLSA合规等级
SLSA 1.0指定了三个合规等级（SLSA构建等级1、2和3），可通过发布适当的构建来源证明文件实现。该文件标识构建平台本身（通常是托管的CI/CD平台，如GitHub Actions或Google Cloud Build）以及用于生成最终构件的配置参数。
- 等级1：提供构建过程可见性，可发现无心之失。来源证明文件只需包含上述数据并在可访问位置发布
- 等级2：确保构建来源证明文件的真实性。关键要求是来源证明文件必须由构建平台签名，且构建必须在专用基础设施上运行
- 等级3：额外的构建平台强化防止来源证明文件伪造。构建平台必须防止构建过程中的用户定义步骤访问签名密钥，且任何两个构建都不能相互影响
如果目标项目达到SLSA 3级合规，大多数针对构建和分发过程的攻击将面临重大障碍。
最后一步：集成到包生态系统
虽然已有这些工具，但SLSA的效益似乎触手可及。但还有一个关键环节：将这些符合SLSA的工具集成到开发者日常使用的包分发工具中。
这些未解决的问题是SLSA效益尚未完全实现的原因。SLSA工具的参考实现奠定了基础，但需要每个包管理系统来操作化该框架，以便消费者无需手动解决歧义。
PEP 740与PyPI中的来源证明
PEP 740是由Trail of Bits工程师起草的规范草案，旨在为PyPI添加SLSA来源证明支持。借助现有的可信发布支持，每个包的构建平台本身通过向每个构建运行颁发的OIDC令牌为PyPI上传提供信任机制。
作为消费者利用SLSA
开发团队无需等待PEP 740和其他包管理器采用类似标准，即可逐步获得SLSA的好处。一些包管理器已经内置支持下载和验证签名来源证明。
目前，SLSA支持集成最深入的包生态系统是npm。npmjs.com上每个包的页面都汇总了最新版本的构建来源证明，并链接到相关的Sigstore透明度日志。
其他包管理器尚不能自动定位、下载和验证来源文件及其签名。许多符合SLSA的项目在其发布资源中托管来源证明，编写下载和验证这些文件及其签名的脚本相当简单。
我们建议按以下优先级安排SLSA验证工作：
- 首先配置容器镜像验证
- 实施SLSA检查清单，必须为分发给构建系统的每个新依赖项完成
- 启动长期工作流，为所有现有依赖项添加来源证明验证
- 向尚未发布来源证明的上游供应商请求SLSA来源证明
迈向安全的软件供应链
与许多安全问题一样，理想的未来状态遵循"设置即忘记"模式：生态系统将深度集成构建来源证明，使包管理器能够安全工作，而无需消费者手动操作。
如果您的项目符合SLSA，请在文档中包含验证说明，并将其视为强制性步骤。确保您的客户知道，如果他们忘记验证您发布的来源证明，就跳过了一个关键步骤。
我们的应用安全团队可以通过审计构建过程（包括构建配置、来源证明分发和文档）来帮助您的开源项目，以便消费者可以放心下载和使用您的软件。从消费者方面，我们的工程师可以帮助您更新依赖管理流程，从现有SLSA支持的供应商中获得最大价值，并为更多组织加入做好准备。