Summary

AICR's docs and SECURITY.md claim SLSA Build Level 3 provenance, but the build architecture appears to meet Build Level 2, not L3. This needs a maintainer decision: either adjust the claim to L2, or change the build to satisfy L3's isolation requirement.

Evidence

GitHub's SLSA guidance: actions/attest-build-provenance yields Build Level 2 by default; Build Level 3 additionally requires build isolation via a dedicated reusable workflow (uses: ./.github/workflows/<build>.yaml), so the provenance is generated in an isolated context the build job cannot tamper with.

In this repo the release build is not isolated in a reusable workflow:

• on-tag.yaml job build-ko runs the build + attestation inline, via composite actions (./.github/actions/generate-slsa-predicate, ./.github/actions/go-build-release). Composite actions execute in the caller's job — no isolation.
• build-attested.yaml similarly attests from a normal build-and-attest job on ubuntu-latest.
• The only uses: ./.github/workflows/ in the build path is qualification.yaml (tests), not the build/attest step.

So the provenance is service-generated and OIDC-authenticated (good — that's L2), but not produced by an isolated build → it does not meet L3 as GitHub defines it.

Claim locations (to reconcile if downgraded)

• SECURITY.md:149 — "SLSA Build Level 3 (provenance v1)"
• docs/README.md:8 and :107
• docs/user/installation.md:47
• docs/integrator/supply-chain-verification.md (Verifying Build Provenance section)

Options

1. Downgrade the claim to Build Level 2 across the docs above (accurate to the current architecture).
2. Achieve L3 by moving the build+attest into a dedicated reusable workflow (workflow_call) so the build is isolated, then keep the L3 claim.

Related

Surfaced during the docs review of #1528. The supply-chain doc was reworded to describe the provenance mechanism without asserting a specific level pending this decision.