GitHub 通过 GitHub Actions 启用 Dependabot，提高供应链安全性.

GitHub 发布了两项功能来提高存储库的安全性和弹性。第一个功能允许 Dependabot 使用托管和自托管运行器作为 GitHub Actions 工作流程运行。第二个版本引入了Artifact Attestations的公共测试版，简化了存储库维护者为其构建工件生成来源的方式。

启用 Dependabot 作为 GitHub Actions 工作流程是改进 Dependabot 底层基础设施的更大计划的一部分。GitHub 产品经理Carlin Cherry解释说，我们决定将 Dependabot 的计算机平台整合到 GitHub Actions 中。这提供了多项改进，包括“通过自托管运行程序在其专用网络上运行 Dependabot，允许 Dependabot 访问本地私有注册表并更新这些软件包”。

该版本还提高了 Dependabot 运行的吞吐量并添加了改进的日志记录。明年所有更新作业都将迁移到 GitHub Actions 上运行。对于已禁用 GitHub Actions 的组织，将提供有关如何更新 Dependabot 配置的进一步说明。

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

GitHub Artifact Attestations 高级工作流程（来源：GitHub）

要创建证明，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 操作将它们与证明相关联：

- 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 Public Good Instance 的 Fulcio 颁发证书；对于私有存储库，使用 GitHub 托管的 Fulcio 内部实例。

在这两种情况下，所有内容都打包为 Sigstore 捆绑包并存储在 GitHub 的证明存储中。对于公共存储库，证明也会写入 Sigstore 公共商品实例及其不可变账本Rekor。