Enhancing Build Provenance: Why GitHub Actions Attestations Need More Runner Detail for True Productivity

The Unseen Builders: A Gap in GitHub Actions Attestations

In the evolving landscape of software supply chain security, understanding the provenance of your build artifacts is paramount. GitHub Actions, a cornerstone for many CI/CD pipelines, offers build provenance attestations to help verify the origin and integrity of your code. However, a recent community discussion on GitHub, initiated by user 'amiller', highlights a critical gap: these attestations currently lack crucial details about the specific runner environment that produced the build.

This oversight poses a significant challenge for robust verification, especially for organizations leveraging custom GitHub-hosted larger runners. While the discussion itself was closed for not following a template, the technical insights it raised are vital for anyone concerned with supply chain security and maintaining high standards for developer productivity.

The Problem: Missing Runner Identity in Attestations

The core issue lies in the ambiguity of the runner environment. An organization can configure GitHub-hosted larger runners with custom images, and these runners might share the same runs-on label (e.g., ubuntu-latest) as GitHub's standard pool. The problem is that the resulting artifact attestation, including the SLSA predicate and the OIDC token, fails to differentiate between these environments beyond a generic github-hosted label.

Consider amiller's example:

- run: echo 4 > answer.txt
- uses: actions/attest-build-provenance@v2

This simple workflow, with no checkout or inputs, was run in three scenarios:

• On GitHub's standard pool.
• On an organization runner booting an *unmodified* custom image.
• On an organization runner booting a *modified* custom image (which produced a different artifact, 5 instead of 4 ).

Despite the critical difference in the third run, nothing in the attestation — not runner_environment, builder.id, or any field in the Fulcio extension registry or Rekor entry — could distinguish these three runs. The organization runner reported github-hosted, just like GitHub's standard pool.

Impact on Trust and Verification

This lack of granular detail severely hampers a verifier's ability to trust the provenance. If a verifier cannot definitively tell whether an artifact came from GitHub's standard, trusted pool, an organization's unmodified custom runner, or a potentially compromised/modified custom runner, the entire purpose of provenance is undermined. For instance, the command gh attestation verify --deny-self-hosted-runners would still accept builds from an organization's custom GitHub-hosted runner, even if it were compromised, because it reports as github-hosted.

The integrity of the build environment is a cornerstone of supply chain security. Without clear identification of the runner's group, size, or specific image, organizations cannot fully attest to the security posture of their build process. This creates a blind spot that could be exploited, leading to compromised artifacts that appear legitimate.

The Proposed Solution: Greater Transparency for Enhanced Productivity

Amiller's ask is clear and practical: carry the runner_group_id, or a boolean indicating if the build was served by the standard pool, into the Actions OIDC token, and subsequently into the certificate and SLSA predicate. GitHub already computes this information and exposes it in the workflow jobs API (where 0 signifies the standard pool). Integrating this into the attestation process would provide the necessary transparency without requiring new data generation.

Implementing this change would significantly enhance the trustworthiness of GitHub Actions attestations. For teams utilizing productivity monitoring software, this improved transparency means more reliable data on build integrity, reducing the time and effort spent on manual verification or incident response related to build provenance. A secure and transparent build pipeline is a foundation for true developer productivity, allowing teams to focus on innovation rather than constantly questioning the integrity of their deployments.

Beyond the Discussion: Implications for Developer Productivity

While the initial discussion focused on security, the implications for developer productivity are profound. When build provenance is ambiguous, security teams must dedicate more resources to auditing and verifying build environments, diverting attention from other critical tasks. Developers, too, might face delays or rework if the trustworthiness of an artifact is called into question.

By providing comprehensive runner details in attestations, GitHub can empower organizations to build more secure and transparent supply chains. This, in turn, fosters an environment of greater trust and efficiency, directly contributing to improved developer productivity. Reliable, verifiable builds are not just a security feature; they are a fundamental enabler of high-performing development teams.