# 构件认证

了解工件声明的用法和安全优势。

## 概述

工件证明使您能够为所构建的软件提供不可伪造的来源可追溯性和完整性保障。 反过来，使用软件的人员可以验证软件是在哪里以及如何构建的。

当您使用您的软件生成工件证明时，您会创建经密码学签名的声明，用于确立您的构建来源，并包含以下信息：

* 与该构件关联的工作流链接
* 该工件的仓库、组织、环境、提交 SHA 值以及触发事件
* OIDC 令牌中用于确立来源的其他信息。 有关详细信息，请参阅“[OpenID Connect](/zh/enterprise-cloud@latest/actions/concepts/security/openid-connect)”。

您还可以生成包含相关软件物料清单 (SBOM) 的制品证明。 将你的版本与它们中使用的开放源代码依赖项列表相关联可提供透明度，并使使用者能够遵守数据保护标准。

## 项目证明的 SLSA 级别

SLSA 框架是用于评估供应链安全性的行业标准。 它按级别进行组织。 每个级别都表示软件供应链的安全性和可信度不断提高。 项目证明本身满足 SLSA v1.0 生成级别 2 的要求。

这在你的项目及其构建说明之间建立了链接，但你可以更进一步，通过要求构建使用已知且经过审核的构建说明来实现。 要执行此操作，最好是让生成工作在组织中许多存储库共享的可重用工作流中进行。 可重用工作流可以在生成过程和调用方工作流之间提供隔离，以满足 SLSA v1.0 生成级别 3 的要求。 有关详细信息，请参阅“[使用项目证明和可重用工作流来实现 SLSA v1 生成级别 3](/zh/enterprise-cloud@latest/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating)”。

有关 SLSA 级别的详细信息，请参阅 [SLSA 安全级别](https://slsa.dev/spec/v1.0/levels)。

## GitHub 如何生成工件证明

若要生成构件证明，GitHub 使用 Sigstore；这是一个开源项目，提供了一套全面的解决方案，用于借助证明对软件构件进行签名和验证。

生成工件证明的**公共存储库**使用 [Sigstore 公共良好实例](https://openssf.org/blog/2023/10/03/running-sigstore-as-a-managed-service-a-tour-of-sigstores-public-good-instance/)。 生成的 Sigstore 捆绑包的副本随GitHub一起存储，还写入到 Internet 上可公开读取的不可变透明度日志。

**Private 存储库**使用 GitHub 的 Sigstore 实例生成工件认证。 GitHub的 Sigstore 实例使用与 Sigstore Public Good 实例相同的代码库，但它没有透明度日志，并且仅与GitHub Actions该实例联合。

## 何时生成证明

仅生成证明并不能提供任何安全优势，必须验证证明才能实现该优势。 下面是有关如何考虑签署内容和签署频率的一些指南：

你应该签署：

* 你发布的软件希望用户能够运行 `gh attestation verify ...`。
* 人们会运行的二进制文件、会下载的包，或包含详细内容的哈希的清单。

**不应**签署：

* 用于自动测试的频繁生成。
* 单个文件，如源代码、文档文件，或嵌入图像。

## 验证工件声明

如果您使用发布工件证明的软件，则可以使用 GitHub CLI 来验证这些证明。 由于证明提供了有关软件在哪里以及如何构建的信息，因此可以使用这些信息来创建和强制实施安全策略，从而提高供应链安全性。

> \[!WARNING] 请务必记住，项目证明\_不能\_保证项目是安全的。 相反，项目证明会将你链接到源代码和生成它们的生成说明。 可以定义策略标准，通过评估内容来评估该策略，并在使用软件时做出明智的风险决策。

## 后续步骤

要开始生成和验证生成项目证明，请参阅 [使用项目证明确立生成的来源](/zh/enterprise-cloud@latest/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations)。