Supply Chain Verification
This guide is for integrators wiring AICR artifact verification into CI pipelines, clusters, and audit tooling. It collects the full command walkthroughs for verifying build provenance, SBOMs, and image/bundle attestations, plus admission-policy enforcement and offline/air-gapped verification.
For a quick trust overview and how to report a vulnerability, see the
top-level SECURITY.md.
Prerequisites and Setup
Verification uses Cosign,
the GitHub CLI (gh), crane (or docker),
jq, and — for in-cluster enforcement — kubectl. Binary and bundle
verification (aicr verify) need only the aicr binary.
Export the following variables once; the rest of this guide reuses them.
Tags are mutable and can be repointed to a different image, so resolve the
tag to an immutable @sha256: digest and verify against the digest.
Authentication (if the registry requires it):
Verifying Build Provenance (SLSA)
AICR produces SLSA build provenance through GitHub Actions: builds are
defined as code and provenance is service-generated (signed by GitHub’s
OIDC-authenticated attestation service via actions/attest-build-provenance)
rather than self-asserted, then logged to the public Rekor transparency log.
Note on the SLSA Build Level. GitHub’s attestation service yields Build Level 2 by default; Build Level 3 additionally requires build isolation via a dedicated reusable workflow. AICR currently attests from its release job using composite actions (not an isolated reusable workflow), so the exact level claimed elsewhere in the docs is being reconciled with the build architecture in #1536.
Method 1: GitHub CLI
Method 2: Extract and inspect provenance
The signed certificate binds the artifact to its source repository, commit SHA, workflow, and run. A representative slice:
Build process transparency
All AICR releases are built using GitHub Actions with full transparency:
- Source Code — Public GitHub repository
- Build Workflow —
.github/workflows/on-tag.yaml(version controlled) - Build Logs — Public GitHub Actions run logs
- Attestations — Signed and stored in the public transparency log (Rekor)
- Artifacts — Published to GitHub Releases and GHCR
View build history:
Verify in the transparency log (Rekor):
Verifying the SBOM
AICR provides SBOMs in SPDX v2.3 JSON format: binary SBOMs embedded in CLI binaries (generated by GoReleaser) and container image SBOMs attached as Cosign attestations (generated by Syft/Anchore).
Binary SBOM (CLI)
Container image SBOM
SBOM format
Both binary and container SBOMs are SPDX v2.3 JSON. A representative package entry (the full document lists every Go module and its transitive dependencies, licenses, and package URLs):
SBOM use cases
Verifying Image and Bundle Attestations
Container image attestations
Method 1: GitHub CLI (recommended)
Method 2: Cosign (SBOM attestations)
CLI binary attestation
CLI binary releases are attested with SLSA Build Provenance v1 using Cosign
keyless signing via GitHub Actions OIDC. Each release archive (.tar.gz)
contains the aicr binary and an aicr-attestation.sigstore.json Sigstore
bundle. The attestation is logged to the public
Rekor transparency log and can be verified
offline.
The install script (./install) runs this verification automatically when
Cosign is available. The Build Attested Binaries workflow
(.github/workflows/build-attested.yaml) can be triggered manually from the
Actions tab to produce attested binaries from any branch without cutting a
release.
Bundle attestation
When aicr bundle runs with --attest, it signs the bundle using Sigstore
keyless OIDC, binding the bundle creator’s identity to the bundle content
(via checksums.txt) and the binary that produced it (via
resolvedDependencies). Attestation is opt-in; bundles are unsigned by
default. The bundle output includes bundle-attestation.sigstore.json
(SLSA Build Provenance v1 for the bundle) and a copy of the binary’s
aicr-attestation.sigstore.json (provenance chain).
This verifies checksums against checksums.txt, the bundle attestation
against the Sigstore trusted root, and the binary attestation provenance
chain (identity pinned to NVIDIA CI). Enforce a minimum trust level:
For full CLI flag documentation, see the
CLI Reference (aicr verify,
aicr bundle --attest, aicr trust update). For a hands-on walkthrough,
see the Bundle Attestation Demo.
Enforcing with Admission Policies
You can enforce provenance verification at deployment time with a Kubernetes admission controller. AICR’s images carry GitHub Artifact Attestations, which are Sigstore bundles — so the admission policy must verify the Sigstore bundle format (not the legacy Cosign signature format):
- Kyverno — verify with
type: SigstoreBundle; see Kyverno’s Verifying Sigstore Bundles guide. - Sigstore Policy Controller — Sigstore-bundle support requires
v0.13.0+ and
signatureFormat: bundle; see the Sigstore bundle format docs. Enforcement only runs in namespaces labeledpolicy.sigstore.dev/include=true.
Verify against AICR’s release identity:
- issuer:
https://token.actions.githubusercontent.com - subject:
https://github.com/NVIDIA/aicr/.github/workflows/on-tag.yaml@refs/tags/*(the release workflow; narrow to the release pattern rather than trusting every workflow/ref)
Validated, cluster-tested copy-paste policies (Kyverno
SigstoreBundleand Policy Controllerv0.13+) are tracked in #1537. The earlier inline examples used the legacy Cosign format / a pre-bundle Policy Controller version and were removed rather than ship policy that silently fails to verify.
Offline and Air-Gapped Verification
Container image verification uses GitHub’s attestation API
(gh attestation verify) because images are already fetched from a
registry — an inherently online context. Binary and bundle verification
uses sigstore-go with a local trusted root instead. Verification is a
read operation that may run frequently — in CI pipelines, in clusters
verifying deployed bundles, or by audit tools — and must not be coupled to
external API availability or rate limits. Cryptographic security is
identical in both cases; the Rekor inclusion proof is embedded in every
.sigstore.json bundle and verified locally.
Trusted root management
Bundle verification uses a Sigstore trusted root (CA certificates and Rekor public keys) to validate attestation signatures offline.
Three layers of trust resolution (in priority order):
- TUF cache (
~/.sigstore/root/) — updated byaicr trust update - Embedded TUF root — compiled into the binary, used to bootstrap
- TUF update —
aicr trust updatecontacts the Sigstore TUF CDN
Verification itself never contacts the network — it uses the cache or the
embedded root. The install script runs aicr trust update automatically
after installation.
Run this when Sigstore rotates their keys (a few times per year) or if verification reports a stale root.