Supply Chain Attestation

Attest builds. SLSA framework.

SLSA levels

SLSA (Supply chain Levels for Software Artifacts) is the framework for proving that the software you ship is actually the software you intended to ship. It is the answer to the supply-chain attack class that has dominated security headlines since SolarWinds. The framework defines progressive levels of supply-chain integrity, each adding stronger guarantees about the build's provenance.

What the SLSA levels actually require:

• Level 1: builds are documented.: The build process is scripted (not run by hand on a laptop). The provenance metadata records what the build did: which commit, which builder, which inputs. This is the entry-level commitment. Teams without it cannot reason about their supply chain at all.
• Level 2: hosted, signed builds.: The build runs on a hosted CI service that the team does not control directly (GitHub Actions, GitLab CI, hosted CircleCI). The provenance is signed by the build platform. Tampering with the build process requires compromising the platform, not just an engineer's laptop.
• Level 3: hardened builds with verifiable isolation.: Builds run in ephemeral, hermetic environments. The build cannot affect other builds. Provenance includes the full input set with cryptographic hashes. The signature chains all the way back to the source. This is the level most enterprise software vendors aspire to.
• Level 4: hardened with two-party review.: Plus mandatory code review by a second engineer for every change, hermetic builds with byte-for-byte reproducibility. Enterprise-grade for software that ships into highly-regulated environments.
• Progressive maturity.: Most teams do not need Level 4. Most teams should aim for Level 2 as a baseline and Level 3 for revenue-critical or regulated services. The right level matches the threat model and the customer's expectations.

The SLSA framework gives the team a vocabulary and a target. Without it, supply-chain conversations are either ignored or scope-creep into "we need to fix everything." With it, they have a measurable maturity ladder.

Implement

The good news in 2026 is that the toolchain to reach SLSA Level 2 or 3 is widely available, mostly free, and integrated into the platforms teams already use. The implementation is configuration, not custom infrastructure.

• GitHub Actions with attestations.: GitHub Actions ships native SLSA Level 3 attestations via the actions/attest-build-provenance action. Every workflow run produces a signed provenance document attached to the artifact. The signature is made by GitHub's OIDC identity, which is trusted across the GitHub ecosystem.
• Sigstore for signing.: Sigstore (cosign, fulcio, rekor) is the open-source standard for signing software artifacts. The signing keys are short-lived, the signatures are recorded in a public transparency log, and verification is built into most container ecosystems. Costs nothing; integrates everywhere.
• Modern toolchains support it natively.: Docker buildx supports attestations. Kubernetes supports verifying signed images. npm has provenance for packages. Go modules have built-in checksums. Most major language ecosystems and runtime platforms have caught up.
• Per-stage attestations.: Build, test, scan, package, and deploy each emit their own attestation. The chain proves "this artifact came from this commit, was built by this CI, passed these tests, was scanned by this scanner, and was deployed by this account." The full chain is the audit story.
• SBOM as part of the package.: Software Bill of Materials documents are generated alongside the build, attached to the artifact, signed by the build process. Customers and auditors can verify what is inside the binary without reverse-engineering it.

The implementation cost is roughly a sprint of focused platform-team work to wire up attestations on the standard build pipelines. The ongoing operational cost is near zero. The benefit is a supply-chain story that satisfies customer security questionnaires and regulatory frameworks without further investment.

Verify

Generating attestations is half the practice. Verifying them at deploy time is the other half. An attestation that nobody checks is a checkbox; an attestation that gates deploys is real security.

• Deploy gate verifies attestation.: The deploy pipeline checks the artifact's attestation chain before promoting to production. Missing attestations, invalid signatures, or attestations that do not match the expected build process all block the deploy. The gate is automatic, not advisory.
• End-to-end trust chain.: The verification reads the attestation, confirms the signature chain back to a trusted root, and validates that the build process matches the team's policy. Anything that fails any link blocks deploy. The chain is mechanical and auditable.
• Per-environment policy.: Production deploys require Level 3 attestations. Staging deploys can require Level 2. Dev deploys may not require attestation at all. The policy is per-environment so production gets the strongest protection without slowing down dev velocity.
• Admission control in Kubernetes.: The cluster admission controller (Kyverno, OPA Gatekeeper, sigstore policy controller) verifies images at admission time. An image without a valid attestation cannot run, even if a deploy pipeline tried to push it. The cluster is the last line of defense.
• Audit log of verifications.: Every verification (success and failure) is logged. The audit trail proves to security and compliance teams that the policy is actually being enforced, not just documented. Failed verifications are investigated; their pattern is reviewed quarterly.

Supply-chain attestation is the difference between "we trust our builds" and "we can prove our builds are what we think." Nova AI Ops integrates with sigstore, GitHub Actions attestations, and Kubernetes admission controllers to surface the attestation status of every running production artifact, so the team can verify supply-chain integrity continuously rather than only at deploy time.