Build every release in CI with signed provenance

How to do it

Provenance records which repository, commit and workflow built a file, signed by the build service itself. Users can then prove a package came from your code and not from a stolen laptop. SLSA Build Level 2 asks for a hosted build service that signs the provenance. Level 3 also keeps the signing key away from the build steps. Code hosts and registries do the signing for you, such as GitHub artifact attestations, npm provenance and PyPI attestations. Publish through trusted publishing as Publish your packages without stored tokens says. Add the bill of materials from Publish what is in each release. Choose the version number as the engineering playbook's Check every release against the public API says.

Examples

YAML example

name: release
on:
  push:
    tags: ['v*']
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - run: make dist
      - uses: actions/attest@1e69f48acb82d1966a394da916b4c1698aa569d6 # v4.2.2
        with:
          subject-path: 'dist/*'

How to check

For every file in the latest release, gh attestation verify <file> -R example-shop/cart succeeds, or the registry's own check does, such as npm audit signatures. A file changed by one byte fails the check.

Sources

• SLSA 1.2 Build track basics
• GitHub Docs on artifact attestations
• npm Docs on provenance statements

Related rules

• SEC-77 Publish your packages without stored tokens in Adversarial testing
• SEC-74 Publish what is in each release in Adversarial testing
• ENG-51 Check every release against the public API in Engineering
• OSS-20 Publish only the files from the tagged source in Open source maintenance