GitHub Actions artifact attestations — actions/attest and the platform-native provenance

GitHub Actions produces SLSA build provenance and SBOM attestations natively. The actions/attest-build-provenance@v1 action generates a SLSA build provenance attestation for the workflow; the actions/attest-sbom@v1 action generates an SBOM attestation for a SBOM file produced earlier in the workflow. The attestations are signed using the OIDC identity of the workflow (the same pattern Part LXIX-03 taught for keyless cosign signing), stored in the GitHub attestations API and as OCI referrers in the registry, and exposed in the GitHub UI for audit. The platform does the work; the workflow declares the input.

The build provenance action

The provenance action is a single step in the workflow that runs after the artifact is built:

- name: Build artifact
  run: ./build.sh
- name: Attest build provenance
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: ./dist/app-binary

The subject-path is the file or directory the attestation covers. The action computes the digest, generates a SLSA build provenance attestation with the workflow’s identity as the signer, signs the attestation with the OIDC token, and uploads the attestation to the GitHub attestations API. The attestation carries the SLSA build provenance shape (buildDefinition, runDetails, metadata); the verifier downstream reads the attestation and checks the source against the policy.

The SBOM action

The SBOM action attaches an SBOM to an artifact as a signed attestation. The SBOM is generated upstream (by syft, by trivy, by the team’s own tool) and passed to the action as a file:

- name: Generate SBOM
  run: syft packages dir:./dist -o spdx-json > sbom.spdx.json
- name: Attest SBOM
  uses: actions/attest-sbom@v1
  with:
    subject-path: ./dist/app-binary
    sbom-path: sbom.spdx.json

The subject-path is the artifact the build produced; the sbom-path is the SBOM file the upstream tool wrote. The action wraps the SBOM in an in-toto Statement with predicateType: https://spdx.dev/Document, signs the statement with the workflow’s OIDC identity, and uploads the attestation to the GitHub attestations API.

flowchart LR
    A["Source (commit)"] --> B["Build step"]
    B --> C["Artifact"]
    B --> D["SBOM (syft)"]
    C --> E["attest-build-provenance@v1"]
    D --> F["attest-sbom@v1"]
    E --> G["OIDC token"]
    F --> G
    G --> H["Signed attestation"]
    H --> I["GitHub attestations API"]
    H --> J["OCI referrer"]
    I --> K["Verifier"]
    J --> K
    K --> L["Admit"]
    K --> M["Deny"]

What the action produces

The action produces three artifacts: a GitHub attestations API entry (queryable from the GitHub UI and via gh attestation), an OCI referrer for container images (the same shape as the SBOM in Part LXVIII-04), and a Sigstore bundle that includes the Fulcio certificate and the Rekor entry. The three artifacts are the same attestation in three locations; the verifier can fetch from any of them.

The workflow identity

The attestation is signed with the OIDC identity of the workflow. The canonical value is:

https://github.com/org/repo/.github/workflows/build.yml@refs/heads/main

The verifier pins the workflow path and the ref. The wildcard https://github.com/org/.* is too permissive (the same lesson from Part LXIX-03). The OIDC issuer is https://token.actions.githubusercontent.com; the verifier pins the issuer as well. The two pins together are the policy that turns the attestation into a verifiable claim.

Production discipline

1. Add both actions to every build workflow. The provenance and the SBOM are the two claims the verifier expects.
2. Pin the workflow path in the verifier. A wildcard is too permissive; the specific path is the policy.
3. Verify the attestation in the admission controller. The attestation is the policy input; the verifier is the policy enforcer.
4. Audit the attestations in the GitHub UI. The attestations API is the audit interface; the team can search by artifact, by workflow, by date.

Cross-course references

• Git, CI/CD & GitOps — Part LXIX-03 (Keyless Signing with Fulcio) is the OIDC identity pattern the actions reuse.
• Git, CI/CD & GitOps — Part LXVIII-04 (SBOM Distribution and Attestation) is the SBOM attestation shape the attest-sbom action produces.
• Git, CI/CD & GitOps — Part LXX-04 (SLSA Source Track) is the source side that the provenance names.

Quiz