Supply Chain Attestation Tools

Tools for SLSA: sigstore, cosign, in-toto.

Sigstore

Supply-chain attestation needs tools that turn the conceptual goal (prove the artifact is what we say it is) into an operational practice. The ecosystem has converged on a specific stack: Sigstore for signing, in-toto for attestations, and CI integration that makes both routine. Teams adopting this stack today get supply-chain integrity with minimal operational overhead.

What Sigstore offers:

• Open-source signing infrastructure.: Sigstore provides keyless signing using OIDC identities. The signer authenticates with their existing IDP (Google, GitHub, Microsoft); Sigstore mints a short-lived certificate; the signature is recorded in a public transparency log. No long-lived keys to manage.
• Cosign for containers.: Cosign signs container images with Sigstore. The signature is attached to the image as an OCI artifact; verifiers can pull the image and verify the signature against the issuer's identity. Container security policies can require signed images.
• Gitsign for commits.: Gitsign signs git commits using the same Sigstore infrastructure. Commits are signed with the author's OIDC identity rather than a long-lived GPG key. The verification proves the commit came from the claimed author at the claimed time.
• Public transparency log (Rekor).: Every signature lands in a public, append-only log. Verifiers check both the signature and the log entry. Tampering with signatures is impossible because the log copy survives independently. The transparency layer is what makes the trust model work without a trusted central authority.
• CNCF graduated, broadly adopted.: Sigstore is a CNCF project with broad industry adoption (Kubernetes, Helm, Cargo, npm, Python). The tooling is stable; the standards are settled; the integration patterns are well-documented.

Sigstore is the modern default for software signing. Teams not using it are either using older tooling (which has known gaps) or are not signing at all (which has bigger gaps).

in-toto

Sigstore signs artifacts. The complement is in-toto, which produces attestations: structured statements about how an artifact was built. The signature alone proves "this artifact is from this signer"; in-toto attestations prove "this artifact was built through this specific process from these specific inputs."

• Attestation framework.: in-toto defines a schema for attestations: predicate type, subject (the artifact being attested), and the statement. The schema is extensible; predicate types exist for build provenance, vulnerability scans, license compliance, and many other use cases.
• Records build steps.: The provenance attestation captures which CI built the artifact, which commit, which inputs, which outputs. The chain from "engineer pushed code" to "artifact ran in production" is reconstructable from the attestations.
• SLSA framework alignment.: The SLSA (Supply chain Levels for Software Artifacts) framework is built on in-toto attestations. SLSA Level 2 requires signed provenance; SLSA Level 3 requires hardened, hermetic builds with provenance. The attestation format is the same.
• Multiple attestations per artifact.: An artifact can have many attestations: one for build provenance, one for SBOM, one for vulnerability scan results, one for license compliance. Each is independent; verifiers can require any combination.
• Verifiable independently.: The attestation is signed (typically with Sigstore) and verifiable against the signer's identity. Anyone can verify the chain end to end without trusting a central authority. This is what makes attestations useful for supply-chain transparency between organizations.

in-toto is the structured attestation format. Combined with Sigstore signing, it produces verifiable supply-chain claims that survive independent verification.

Integrate

The third leg is CI integration. Modern CI platforms ship Sigstore and in-toto integration as built-in features. The team configures the workflow to produce signed attestations; the CI does the rest.

• GitHub Actions support.: GitHub Actions ships actions/attest-build-provenance and actions/attest-sbom that produce signed in-toto attestations as part of any workflow. Adding attestation to an existing workflow is a few lines of YAML; the security gain is large.
• Modern CI native support.: GitLab CI, CircleCI, Buildkite, and others have similar integrations. The tooling has matured to the point where teams can opt in by changing their workflow files, not by writing custom signing code.
• Verification at deploy time.: Kubernetes admission controllers (Kyverno, OPA Gatekeeper, sigstore policy controller) can verify attestations before allowing pods to run. The cluster refuses unsigned or improperly-attested artifacts. The verification is the final gate.
• SBOM integration.: The CI also produces SBOMs and signs them as in-toto attestations attached to the artifact. Customers and security teams can pull the SBOM, verify its signature, and inspect the dependencies. The supply-chain story is end-to-end.
• Backwards-compatible adoption.: Teams can adopt incrementally: sign artifacts first; add provenance attestations next; add SBOM attestations later; add deploy-time verification last. Each step is independently valuable; the full stack takes a quarter or two to land.

Sigstore for signing, in-toto for attestations, and CI integration for the workflow together produce the modern supply-chain integrity stack. Nova AI Ops integrates with the major signing and attestation tools, surfaces the cases where production artifacts lack expected attestations, and tracks the supply-chain coverage across the artifact registry so the security team has visibility into the chain.