GitHub 发布两项新功能以提升仓库安全性和弹性

GitHub 最近发布了两项新功能，旨在提升仓库的安全性和弹性。第一项功能允许 Dependabot 作为 GitHub Actions 工作流运行，支持使用托管和自托管的运行器。第二项功能引入了 Artifact Attestations 的公开测试版，简化了仓库维护者为构建工件生成来源信息的过程。

Dependabot 作为 GitHub Actions 工作流运行

这一功能是 GitHub 改进 Dependabot 底层基础设施计划的一部分。GitHub 产品经理 Carlin Cherry 解释说，该决策旨在将 Dependabot 的计算平台整合到 GitHub Actions 中。这一改进带来了多项好处，包括允许 Dependabot 在私有网络中使用自托管运行器，从而访问本地私有注册表并更新这些包。

此外，该版本还提高了 Dependabot 运行的吞吐量，并改进了日志记录。所有更新任务将在未来一年内迁移到 GitHub Actions 上运行。对于已禁用 GitHub Actions 的组织，GitHub 将提供进一步的指导，说明如何更新 Dependabot 配置。

Artifact Attestations 公开测试版

Artifact Attestations 简化了在 GitHub 内运行构建的来源信息生成过程。来源信息是关于如何构建工件的元数据，包括所有权、来源、依赖项和使用的构建过程等信息。这些证明可以在下游用于验证包是否为预期构建的产物。Artifact Attestations 利用了 Sigstore，这是一个为开源软件提供签名、验证和保护标准的开源项目。

要创建证明，GitHub Actions 工作流首先需要获得写入证明存储的权限：

permissions:
  id-token: write
  attestations: write
  contents: read

然后，可以更新工作流以创建证明：

- name: Attest Build Provenance
  uses: actions/attest-build-provenance@897ed5eab6ed058a474202017ada7f40bfa52940 # v1.0.0
  with:
    subject-path: "bin/my-artifact.tar.gz"

生成的证明可以通过 GitHub CLI 验证或下载。例如，验证证明是否有效时，需要指定控制原始操作运行的仓库的组织名称：

gh attestation verify my-artifact.tar.gz -o my-organization

对于生成 SBOM（软件物料清单）的构建，可以使用 attest-sbom 操作将 SBOM 与证明关联：

- uses: actions/attest-sbom@v1
  with:
    subject-path: 'bin/my-artifact.tar.gz'
    sbom-path: 'sbom.spdx.json'

GitHub 工程经理 Trevor Rosen 解释说，文档使用临时密钥对进行签名。公钥附加到与构建系统的工作负载身份相关联的证书上，私钥不会离开进程内存，并在签名后立即丢弃。

这一过程利用了 Fulcio 作为证书颁发机构。Fulcio 是 Sigstore 的根证书颁发机构部分，可以基于 OIDC 身份（如电子邮件地址）颁发签名证书。对于公共仓库，Sigstore 公共实例的 Fulcio 颁发证书；对于私有仓库，使用 GitHub 托管的 Fulcio 实例。

在所有情况下，所有内容都打包为 Sigstore 捆绑包，并存储在 GitHub 的证明存储中。对于公共仓库，证明还会写入 Sigstore 公共实例及其不可变分类账 Rekor。

更多关于 Dependabot 改进和 Artifact Attestations 发布的详细信息，可以在 GitHub 博客上找到。