概述
项目证明使你能够为自己构建的软件创建不可伪造的来源和完整性保证。 反过来，使用软件的人员可以验证软件是在哪里以及如何构建的。
使用软件生成项目证明时，将创建加密签名的声明用于确立生成的来源，并包含以下信息：
- 指向与项目关联的工作流的链接。
- 项目的存储库、组织、环境、提交 SHA 以及触发事件。
- OIDC 令牌中用于确立来源的其他信息。 有关详细信息，请参阅“OpenID Connect”。
还可以生成包含关联的软件物料清单 (SBOM) 的项目证明。 将你的版本与它们中使用的开放源代码依赖项列表相关联可提供透明度，并使使用者能够遵守数据保护标准。
项目证明的 SLSA 级别
SLSA 框架是用于评估供应链安全性的行业标准。 它按级别进行组织。 每个级别都表示软件供应链的安全性和可信度不断提高。 项目证明本身满足 SLSA v1.0 生成级别 2 的要求。
这在项目及其生成说明之间建立了链接，但你可以通过要求生成工作使用经过审查的已知生成说明以进一步完善此方法。 要执行此操作，最好是让生成工作在组织中许多存储库共享的可重用工作流中进行。 可重用工作流可以在生成过程和调用方工作流之间提供隔离，以满足 SLSA v1.0 生成级别 3 的要求。 有关详细信息，请参阅“使用项目证明和可重用工作流来实现 SLSA v1 生成级别 3”。
有关 SLSA 级别的详细信息，请参阅 SLSA 安全级别。
GitHub 如何生成项目证明
为了生成项目证明，GitHub 使用 Sigstore，它是一个开放源代码项目，提供了一个全面的解决方案，用于通过证明对软件项目进行签名和验证。
生成项目证明的公共存储库使用 Sigstore Public Good 实例。 生成的 Sigstore 捆绑包的副本随 GitHub 一起存储，还写入 Internet 上公开可读的不可变透明度日志。
生成项目证明的专用存储库 使用 GitHub 的 Sigstore 实例。 GitHub 的 Sigstore 实例使用与 Sigstore Public Good 实例相同的代码库，但它没有透明度日志，并且仅与 GitHub Actions 联合。
何时生成证明
仅生成证明并不能提供任何安全优势，必须验证证明才能实现该优势。 下面是有关如何考虑签署内容和签署频率的一些指南：
应签署：
- 你发布的软件希望用户能够运行
gh attestation verify ...。 - 人们会运行的二进制文件、会下载的包，或包含详细内容的哈希的清单。
不应签署：
- 用于自动测试的频繁生成。
- 单个文件，如源代码、文档文件，或嵌入图像。
验证项目证明
如果使用发布项目证明的软件，则可以使用 GitHub CLI 来验证这些证明。 由于证明提供了有关软件在哪里以及如何构建的信息，因此可以使用这些信息来创建和强制实施安全策略，从而提高供应链安全性。
警告
请务必记住，项目证明_不能_保证项目是安全的。 相反，项目证明会将你链接到源代码和生成它们的生成说明。 可以定义策略标准，通过评估内容来评估该策略，并在使用软件时做出明智的风险决策。
后续步骤
要开始生成和验证生成项目证明，请参阅 使用项目证明确立生成的来源。