GitHub has released two features to improve the security and resilience of repositories. The first feature allows Dependabot to run as a GitHub Actions workflow using hosted and self-hosted runners. The second release introduces the public beta of Artifact Attestations, simplifying how repository maintainers can generate provenance for their build artifacts.
Enabling the usage of Dependabot as a GitHub Actions workflow is part of a larger plan to improve the underlying infrastructure for Dependabot. Carlin Cherry, product manager at GitHub, explains that the decision was made to consolidate Dependabot's computer platform to GitHub Actions. This provides several improvements, including running "Dependabot on their private networks with self-hosted runners, allowing Dependabot to access on-premises private registries and update those packages".
The release also improves the throughput of Dependabot runs and adds improved logging. All update jobs will be migrated to run on GitHub Actions over the next year. For organizations that have disabled GitHub Actions, further instructions will be provided on how to update the Dependabot configuration.
The second release, Artifact Attestations, simplifies generating provenance for builds running within GitHub. Provenance is metadata about how the artifact was built, including information on ownership, sources, dependencies, and the build process used. These attestations can be consumed downstream to validate that the package is what was built. Artifact Attestations leverages Sigstore, an open-source project that provides a standard for signing, verifying, and protecting open-source software.
To create attestations, the GitHub Actions workflow first needs permission to write to the attestations store:
permissions:
id-token: write
attestations: write
contents: read
From there, the workflow can be updated to create the attestation:
- name: Attest Build Provenance
uses: actions/attest-build-provenance@897ed5eab6ed058a474202017ada7f40bfa52940 # v1.0.0
with:
subject-path: "bin/my-artifact.tar.gz"
The resulting attestation can be either verified via the GitHub CLI or downloaded. For example, to verify the attestation is valid, the name of the organization that controls the repo where the original action ran needs to be specified:
gh attestation verify my-artifact.tar.gz -o my-organization
For builds that generate SBOMs (Software Bills of Material), those can be associated with the attestation using the attest-sbom action:
- uses: actions/attest-sbom@v1
with:
subject-path: 'bin/my-artifact.tar.gz'
sbom-path: 'sbom.spdx.json'
As part of this workflow, the document is signed with a temporary keypair. Trevor Rosen, staff engineering manager at GitHub, explains:
The public key is attached to a certificate associated with a build system’s workload identity, and the private key never leaves process memory and is discarded immediately after signing.
To accomplish this, Fulcio is leveraged as a certificate authority. Fulcio is the root Certificate Authority portion of Sigstore and can issue signing certificates based on an OIDC identity, such as an email address. For public repositories, Sigstore Public Good Instance's Fulcio issues the cert; for private repositories and GitHub hosted internal instance of Fulcio is used.
In both cases, everything is packaged as a Sigstore bundle and stored within GitHub's attestation store. For public repos, the attestation is also written to the Sigstore Public Good Instance and its immutable ledger, Rekor.
More details about the changes to Dependabot and the release of Artifact Attestion can be found on the GitHub blog.