Publish a release verification page: attestations, SLSA v1.2, one command

SLSA v1.2 was announced on 24 November 2025. It adds a Source Track beside the existing Build Track and is backwards compatible with v1.1. For a small vendor the useful part is the Build Track's idea that a release should carry provenance: signed evidence of what built it, from which source, by which process.

A customer who has asked about your supply chain can then run one command instead of reading a questionnaire answer. This post shows what to put on a verification page.

What's affected

The Build Track levels as the spec describes them:

The spec says L1 provenance "is trivial to bypass or forge," so it helps debugging but is not tamper protection. L2 puts signing in the platform's hands. L3 additionally requires that runs cannot influence each other and that the signing secret is not reachable from user build steps.

Which level you reach depends on your build platform's own claims, not on a badge you add. Read your platform's documentation before you state a level to anyone.

How to check if you're exposed

Take your last release and ask: can a customer verify, without contacting you, that this file was built by your pipeline from your repository? If the answer is "check our checksum on the website," that proves nothing if the website is compromised.

What to do now

1. Stop using long lived publish tokens where you can. npm trusted publishing lets a workflow publish through OpenID Connect, with a short lived signed token tied to the workflow. It needs npm CLI 11.5.1 or later and Node 22.14.0 or later, supports GitHub-hosted runners, GitLab.com shared runners and CircleCI cloud, and the workflow needs id-token: write. For public packages from public repositories on GitHub Actions or GitLab CI, npm generates provenance automatically.

2. Attest your build outputs. GitHub's documentation shows this step after the build, with the permissions it needs:

   permissions:
     id-token: write
     contents: read
     attestations: write
   
   steps:
     - name: Generate artifact attestation
       uses: actions/attest@v4
       with:
         subject-path: 'dist/myapp-linux-amd64'
   

   For container images, add packages: write, pass subject-name and subject-digest, and set push-to-registry: true.

3. Attest the SBOM too. GitHub's CLI can check SBOM attestations by predicate type, for example https://spdx.dev/Document/v2.3 for SPDX. CISA's 2025 draft says integrity and authenticity of SBOMs are most often supported by signatures, and to use existing signing infrastructure.

4. Write the verification page. It is short:

   # binary
   gh attestation verify myapp-linux-amd64 -R your-org/your-repo
   
   # container image (log in to the registry first)
   gh attestation verify oci://registry.example.com/your-org/app@sha256:DIGEST -R your-org/your-repo
   

5. Say what a pass means and what it does not. It means this artifact came from that repository's workflow. It does not mean the code has no vulnerabilities.

6. Pin the verification instructions to each release, next to the SBOM and VEX file.

How to avoid this trap

• Do not publish provenance and never verify it yourself. Run the command on a clean machine before each release.
• Do not claim an SLSA level you have not checked against the spec's requirements for your platform.
• Do not keep a long lived publish token alongside trusted publishing. Remove it once the workflow works.

Why it matters

Provenance shifts the conversation from "trust us" to "check this." SLSA's own framing is that the producer picks a capable platform, builds consistently and distributes the provenance, and the consumer validates it.

Try it yourself

Add the attestation step to one pipeline, build, and run the verify command from a different machine. If it fails, the failure message is the first thing to document on your page.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Announcing SLSA v1.2 (24 November 2025)
• SLSA v1.2 Build Track basics
• npm docs: trusted publishers
• GitHub docs: using artifact attestations
• CISA, 2025 Minimum Elements for a Software Bill of Materials, public comment draft (PDF)