Signed, Sealed, Delivered: SBOMs, SLSA & Sigstore for Verifiable Software Supply Chains
Why verifiable supply chains matter now
Modern software is assembled more than it is written. We stitch together open source modules, container base images, operating system packages, CI plugins, and cloud build services across organizational boundaries. That composability accelerates delivery, but it also expands the attack surface: a compromise in one dependency, build step, or distribution channel can silently taint thousands of downstream systems. The last few years have made this painfully clear—from dependency confusion to compromised build systems and malicious backdoors hidden in widely used libraries.
Verifiable supply chains answer a simple question with cryptographic proof instead of trust: what exactly am I running, and how do I know it came from where it claims, built the way it claims? The building blocks of that answer are three complementary layers:
- SBOMs (Software Bills of Materials) to describe what is inside.
- SLSA (Supply-chain Levels for Software Artifacts) to govern how it was produced.
- Sigstore to bind identities and metadata to artifacts via transparent, easy-to-verify signatures and attestations.
Together, they let organizations go beyond “secure by intention” to “secure by verification,” enabling automated controls at build, release, deploy, and runtime. This post explains the concepts in depth, shows how they interlock, and offers pragmatic implementation patterns you can adopt without rewriting your toolchain.
The modern supply chain risk landscape
Supply chain threats exploit trust boundaries. An attacker rarely needs to break your production cluster if they can slip malicious code into a transitive dependency, compromise a CI credential, or convince a developer to run a tainted tool. Notable incidents highlight different weak points:
- A widely publicized dependency backdoor forced organizations to reassess how deeply they trust CI-produced binaries versus independently verifying sources and builds.
- Log4Shell showed that even non-malicious flaws in popular components propagate instantly across industries, making inventory and impact analysis critical.
- An attempted backdoor in a ubiquitous compression library demonstrated the sophistication of contributor social engineering and the need for provenance checks, not just code review.
The common thread is opacity: organizations often lack machine-readable inventories, provenance, and signatures that let them trace artifacts back to specific sources and build processes. Visibility turns into verifiability when we can tie identities to actions and artifacts with cryptographic evidence that can be checked automatically at scale.
SBOMs: the inventory that makes risk visible
An SBOM is a manifest of software components in an artifact or system—names, versions, relationships, and metadata. Two de facto standard formats dominate:
- SPDX, a Linux Foundation standard that models packages, files, licenses, and relationships with rich semantics.
- CycloneDX, an OWASP standard focused on application security use cases, including components, services, vulnerabilities, and attestations.
Both support JSON and XML serializations and can be generated by widely used tools. For containers and compiled applications, teams often use Syft, BuildKit SBOM plugins, ORT, Gradle/Maven/Cargo/NPM analyzers, or language-specific builders. Many distros and registries now expose SBOMs alongside packages and images.
What a “good” SBOM looks like
SBOMs enable analysis workflows only if they are accurate, scoped, and linked to the artifact they describe:
- Accuracy: Component names and versions should match what is actually shipped, including transitive dependencies and embedded libraries.
- Scope: Decide whether the SBOM is build-time (what the build consumed), deploy-time (what the artifact contains), or runtime (what is actually loaded). Each serves a different purpose.
- Binding: The SBOM should reference the artifact by content digest (e.g., OCI image digest), not just a mutable tag or version string.
At minimum, include component identifiers (e.g., purl or CPE), versions, hashes when possible, licenses, and supplier information. Align with NTIA’s “minimum elements” so downstream consumers can integrate your SBOM into tooling without custom adapters.
From SBOM to action with VEX
SBOMs say what you have; VEX (Vulnerability Exploitability eXchange) says whether known issues are exploitable in your context. For a component with a CVE, a VEX document can assert “not affected” with justification (e.g., vulnerable code path not present or not reachable). This helps teams avoid noisy, unnecessary patching while still documenting risk decisions for auditors and customers. CycloneDX and CSAF are common VEX carriers; some vendors embed VEX statements as annotations next to SBOMs.
SLSA: a framework for trustworthy builds and provenance
SLSA is a community framework that defines progressive safeguards for source integrity, build integrity, and verifiable provenance. It moves organizations from “we run CI” to “we can prove that this artifact was built from this source, in this environment, by this builder, with tamper-evident logs.”
Core ideas, not just levels
- Provenance: A signed record describing the artifact’s origin—source repository, commit, builder identity, build steps, parameters, and materials. The builder produces and signs it so developers cannot forge post hoc explanations.
- Isolated, auditable builders: Use a hosted or self-managed build service where the environment is configured as code, credentials are short-lived and scoped, and the build runs in isolation from the developer’s workstation.
- Source and dependency integrity: Pin exact versions by content digest, verify checksums, and ensure the source is the one actually built (e.g., via verified commits or protected branches).
- Hardening over time: Adopt hermetic builds, reproducibility, and two-person review for sensitive components as you mature.
In practice, many teams aim first for non-falsifiable provenance—meaning the builder, not the developer, signs the provenance and publishes it where anyone can verify it. Cloud-native build systems like Tekton, GitHub Actions, GitLab CI, and Google Cloud Build integrate with SLSA-compatible provenance formats and signing tools to make this attainable.
Sigstore: making signing and verification usable
Signing existed long before Sigstore, but operational friction—key management, distribution, revocation—prevented widespread adoption. Sigstore reduces that friction by combining identity, signing, and transparency into a cohesive experience designed for CI/CD.
Building blocks
- Cosign: A CLI and library to sign and verify container images, files, and attestations. It stores signatures and attestations alongside OCI artifacts or in external stores.
- Fulcio: A certificate authority that issues short-lived X.509 certificates binding an OIDC identity (e.g., a GitHub workflow or corporate SSO account) to a public key. This enables “keyless” signing.
- Rekor: A public, append-only transparency log that records hashes of signatures, certificates, and metadata. Anyone can query it to independently verify that a given signature was recorded and has not been tampered with.
Why transparency matters
A signature by itself proves possession of a key, but not whether the event was public and auditable. Rekor’s Merkle tree makes publication verifiable: once an entry is logged with an inclusion proof, removing or altering it would be detectable. Transparency logs deter covert signing, simplify incident response (you can search for compromised identities or time windows), and help prove when and by whom something was signed.
Keyless, identity-bound signing
With keyless mode, CI jobs authenticate to an OIDC provider (e.g., GitHub, Google, or your enterprise IdP), receive a short-lived identity token, and obtain a Fulcio certificate that binds that identity to a transient key pair. Cosign uses the key to sign artifacts and records the event in Rekor. Verifiers check the signature, certificate chain to Fulcio, OIDC claims (like repository name or workflow), and Rekor inclusion. There’s no long-lived private key to leak, rotate, or escrow.
Bringing it together: signed SBOMs and SLSA provenance
SBOMs and SLSA provenance become trustworthy when you can verify who produced them and for which artifact. Sigstore provides the mechanism; in-toto and DSSE provide a standard envelope for attestations.
In-toto attestations and DSSE
An in-toto “Statement” is a small JSON envelope that names a subject (e.g., an image digest) and a predicate (the metadata you want to attest to). DSSE (Dead Simple Signing Envelope) wraps this statement for signing in a consistent, unambiguous way. Common predicate types include SLSA provenance and build metadata; you can also reference SBOMs by digest or embed them when practical.
Practically, your pipeline might produce three things for an image digest:
- The image itself, pushed to an OCI registry.
- An SBOM (SPDX or CycloneDX), stored either as a separate artifact or embedded in an attestation.
- A SLSA-compatible provenance attestation describing the build.
Cosign can attach signatures and attestations to the image digest. Registries that implement OCI “referrers” allow these attachments to be discoverable alongside the image. Verification at deploy time then becomes: fetch the image by digest, fetch its signatures and attestations, validate them against policy, and proceed only if they pass.
From policy to enforcement: blocking on verification
Once artifacts carry signed SBOMs and provenance, you need gates that enforce rules. Good policy tooling is declarative, fast, and easy to audit.
Policy examples
- Only run images whose signature chains to Fulcio with an identity claim matching your GitHub org and repository, from a protected branch.
- Require a SLSA provenance attestation that lists no unpinned dependencies and was produced by your approved builder.
- Block deployments unless an SBOM exists and contains no components with critical vulnerabilities lacking a VEX “not affected” justification.
Enforcement tools
- Kubernetes admission: Sigstore Policy Controller, Kyverno, or OPA Gatekeeper can verify Cosign signatures and attestations before pods are admitted. Connaisseur focuses on image signature verification and works with multiple signing systems.
- Registry gates: Some registries enforce signature or provenance presence before promoting images between repositories.
- CI/CD checks: Pre-deploy jobs can fail early if attestation policies are not met, preventing time-consuming rollouts that will be blocked later.
These gates should operate on immutable digests and fail closed when verification cannot be performed, while providing clear error messages so teams can remediate quickly.
Real-world scenarios and lessons learned
Rapid vulnerability response with SBOMs
When a high-profile vulnerability hits, organizations scramble to answer: where are we exposed? Teams with SBOM coverage can query a central catalog for component coordinates and versions, identify images and services affected, and prioritize remediation by business impact. If VEX documents indicate that a product is not affected by the vulnerability in its shipped configuration, teams can reduce unnecessary churn while documenting the reasoning for auditors.
Defending against compromised builds
A malicious actor who gains access to a CI runner might inject code into outputs while keeping source clean. If your verification policy requires non-falsifiable SLSA provenance signed by the builder and containing the source commit, builder version, and reproducible build parameters, a tampered build that bypasses the builder’s signing step will fail at admission. Rekor queries can also reveal anomalous signing identities or time windows that correlate with suspicious outputs.
Open source ingestion at scale
A fintech company ingesting hundreds of third-party images set an admission policy: run only images with a valid Sigstore signature from the publisher and a CycloneDX SBOM attached. For images without a publisher signature, they rebuild from source in a controlled builder, generate their own SBOM, publish their own signatures, and use an internal registry as the source of truth. This ensured that everything in production had verifiable provenance and a local inventory, even when upstreams were not yet signing.
A pragmatic implementation roadmap
Phase 1: Establish inventory and integrity
- Generate SBOMs for critical artifacts using a standard format and store them with the artifacts in your registry or artifact repository.
- Start signing releases with Cosign. If keyless is not yet possible, use a KMS to manage keys and rotate regularly.
- Publish signatures to Rekor and ensure verification can be performed from developer laptops and CI.
Phase 2: Introduce provenance
- Have your build system produce in-toto SLSA provenance for each artifact. Integrate with Tekton Chains or CI plugins that emit provenance.
- Attach provenance attestations to artifacts and verify them in pre-deploy jobs.
- Enforce digest pinning across Dockerfiles, Helm charts, and IaC to remove tag ambiguity.
Phase 3: Enforce policies
- Roll out admission controls in a canary environment: start with audit mode, then move to warn and finally enforce.
- Codify policies for acceptable signers, required attestations, allowed builders, and vulnerability thresholds. Version-control the policies.
- Add exception workflows using VEX and time-bound approvals for edge cases.
Phase 4: Harden builders and sources
- Isolate build environments, eliminate long-lived credentials, and enable workload identity for cloud resources.
- Adopt hermetic builds where feasible (e.g., containerized toolchains with network egress restricted to declared dependencies).
- Pursue reproducible builds for high-assurance components and compare build outputs from independent builders.
Under the hood: data models that make verification possible
In-toto statement structure
An in-toto statement includes:
- Subject: A list of artifacts with their digests (e.g., sha256 of an OCI image manifest).
- Predicate type: The schema that defines the meaning of the predicate (e.g., a SLSA provenance URI).
- Predicate: The metadata payload—buildType, builder ID, invocation parameters, materials (inputs), and timestamps for provenance.
DSSE wraps the statement to avoid ambiguity and ensure that the exact bytes signed are consistent. Cosign can sign this envelope and attach it to the artifact.
Rekor entries and inclusion proofs
When Cosign logs a signature, Rekor returns a log index, UUID, and an inclusion proof. Verifiers can look up the entry by artifact digest, certificate fingerprint, or signature content. The inclusion proof ties the entry to Rekor’s Merkle tree root at a given time, enabling third parties to detect if entries disappear or the tree is rewritten.
Design decisions and trade-offs
Keyless vs. keyful signing
- Keyless: Simplifies ops, strongly ties identity to signatures, works well in cloud CI. Requires access to Fulcio, Rekor, and an OIDC provider. Good default for most teams.
- Keyful: Traditional keys held in KMS or HSM, useful for air-gapped or regulated environments where external dependencies are restricted. Puts more burden on key management and rotation.
Public vs. private transparency
- Public Rekor: Maximizes ecosystem-wide auditability and cross-organization verification.
- Private Rekor: Offers similar guarantees within organizational boundaries when publishing to a public log is not acceptable. Some teams dual-publish to both.
Trusting identities
Keyless relies on OIDC claims. Policies should pin not only the issuer (e.g., token was issued by a trusted provider) but also critical claims like repository, workflow, environment, and subject claims. For human signers, require MFA and conditional access; for workload identities, ensure repository and branch protections prevent impersonation.
SBOM completeness vs. performance
Deep file-level SBOMs can be expensive to generate for large images. Many teams start with package-level SBOMs and augment depth for critical components. Incremental SBOM generation and caching can keep pipelines fast while maintaining acceptable fidelity. Always bind SBOMs by digest to prevent mismatches.
Hermetic and reproducible builds
Hermetic builds reduce non-determinism by fixing inputs and network access. Reproducibility provides the ability to rebuild an artifact and get identical outputs given the same inputs. While not always immediately achievable, pursuing them for core libraries and base images dramatically increases assurance and simplifies incident response: you can verify third-party artifacts by rebuilding and comparing digests.
Beyond build time: continuous verification and runtime signals
Supply chain security does not end at release. Environments drift, dependencies update, and runtime behavior can diverge from what an SBOM predicts.
- Deploy-time verification: Admission controls evaluate signatures, SBOM presence, and provenance before pods run.
- Runtime attestation: Collect runtime inventories (e.g., loaded libraries) and compare against SBOMs to detect drift or unexpected components.
- Continuous vulnerability intelligence: As new CVEs emerge, correlate them with SBOM catalogs and update VEX statements to reflect exploitability in context.
- Recertification loops: On policy changes (e.g., raising the minimum SLSA standard), invalidate old attestations and require rebuilds.
Treat attestations as living documents that can be superseded or revoked. Record policy decisions in version control so you can reconstruct why something was allowed at a point in time.
Regulatory and contractual drivers
Even when security is not the primary motivator, compliance and customer expectations are pushing the market toward verifiable supply chains. Government guidance encourages SBOMs and secure development frameworks. Industry programs and procurement checklists increasingly ask for SBOM availability, vulnerability disclosure processes, and proof of build integrity. Medical device and critical infrastructure sectors have highlighted SBOMs as essential for risk transparency. Rather than treating these as check-the-box tasks, organizations can use SBOMs, SLSA, and Sigstore to create automation that reduces operational toil and elevates assurance.
Common pitfalls and how to avoid them
- Unsigned SBOMs: An unsigned SBOM can be swapped or spoofed. Always sign SBOMs or embed them in signed attestations bound to the artifact digest.
- Tag-based verification: Verifying “latest” is a footgun. Pin to digests everywhere—Dockerfiles, deployment manifests, and admission policies.
- Provenance gaps: If the developer’s laptop, not the builder, signs provenance, you lose non-falsifiability. Ensure the builder produces and signs provenance.
- Blind trust in identity: Policies that accept any certificate from a trusted CA without narrowing claims risk approving artifacts from the wrong repo or branch. Match on issuer and specific claims.
- SBOM drift: Generating SBOMs at build time only may miss runtime-loaded components. For critical apps, complement with runtime inventory and compare.
- Air-gapped surprises: Keyless signing needs network access. For disconnected environments, plan for keyful signing or deploy private Fulcio/Rekor instances.
- Time skew and expiry: Short-lived certs and timestamps matter. Keep CI clocks synchronized and ensure verification logic handles expiry windows and Rekor inclusion proofs correctly.
- Over-reliance on vulnerability counts: Policies that block purely on numeric severity can create friction without reducing risk. Incorporate VEX and exploitability context.
A practical blueprint for Kubernetes platforms
Build-time pipeline
- Build images in an isolated builder with workload identity and restricted egress.
- Generate an SBOM per image and store it in the registry as an OCI artifact or attestation.
- Produce in-toto SLSA provenance with the builder identity, source commit, build parameters, and materials.
- Use Cosign in keyless mode to sign the image, SBOM, and provenance; record entries in Rekor.
- Publish artifacts by digest and propagate digests down the deployment pipeline.
Pre-deploy checks
- Policy-as-code pipeline step verifies signatures, Fulcio chains, OIDC claims, and Rekor inclusion for all artifacts.
- SBOM inspection ensures no disallowed licenses and no unmitigated critical vulnerabilities; consult VEX where present.
- Attestation policy evaluation confirms that builds used approved builders and pinned dependencies.
Cluster admission
- Deploy an admission controller (e.g., Sigstore Policy Controller or Kyverno) configured with organization policies.
- Require digest references in manifests. Inject digests at CI if developers submit tags.
- Block if verification fails or attestations are missing; allow if all policy checks pass.
Operations and incident response
- Maintain a searchable catalog correlating digests, SBOM components, signatures, and deployments.
- On advisories, query the catalog to scope impact quickly and prioritize patches.
- Audit Rekor for entries signed by compromised identities; revoke trust and rotate policies as needed.
Tooling ecosystem highlights
- SBOM generation: Syft, BuildKit’s SBOM exporter, Gradle/Maven plugins, cargo-guppy, npm packagers, distro-native tools.
- Verification: Cosign verify and verify-attestation, policy engines (Kyverno, Gatekeeper), and registry plugins.
- Provenance producers: Tekton Chains, GitHub Actions with provenance generators, GitLab pipelines, cloud build services.
- Catalogs: Internal asset inventories that ingest SBOMs and signatures; some organizations extend their CMDB to include digest-anchored software records.
Economics of verification: speed, scale, and ergonomics
Verification must be faster than the operations it guards, or teams will circumvent it. A few principles help maintain velocity:
- Cache verification results keyed by digest and policy hash; reevaluate only when inputs change.
- Push verification left: fail in CI within seconds instead of at cluster admission minutes later.
- Keep policies simple and deterministic; explain denials with actionable guidance.
- Make “the right thing” the easiest path—templates and scaffolding that create signed, attested outputs by default.
The payoff compounds: once artifacts are consistently signed with attached SBOMs and provenance, new controls—licensing checks, dependency bans, environment pinning—are just policy updates. The security graph (who built what, from where, with which components) becomes queryable, enabling better risk ranking and faster audits.
Measuring progress
To track maturity, define metrics that reflect verifiability, not just process:
- Coverage: Percentage of production workloads with a verified signature, SBOM, and provenance attestation.
- Time to verify: Median time for pre-deploy verification and admission verification.
- Policy efficacy: Number of prevented policy violations (e.g., unsigned artifacts) versus false positives.
- Incident response speed: Time to inventory affected components when a new CVE is published.
- Builder integrity: Percentage of builds with no network egress beyond declared dependencies.
Set thresholds that ratchet up gradually as teams adopt tooling. Publish dashboards so development and platform teams can see—and take pride in—measured improvements.
Working with vendors and upstreams
Many organizations rely on commercial software and upstream open source projects. Ask suppliers for signed artifacts, SBOMs, and provenance. If they cannot provide them, ingest source and rebuild in your trusted builder, then attach your own attestations. Consider participating in upstream efforts to add signing and SBOM generation; the payoff extends beyond your organization as more of the ecosystem becomes verifiable by default.
Handling legacy and edge cases
Not every artifact can be rebuilt or retrofitted immediately. Triage legacy workloads:
- Critical and changeable: Rebuild under your controls and attach attestations.
- Critical and brittle: Wrap with additional runtime controls, isolate blast radius, and document compensating controls.
- Low risk: Monitor, plan for end-of-life, and avoid promoting to higher environments.
For environments with intermittent connectivity (edge, industrial), pre-stage signed artifacts and policies, sync verification logs back to a central system when connectivity returns, and use local verification caches to avoid blocking operations.
Interoperability and future-proofing
Choose open formats and APIs to avoid lock-in. SPDX and CycloneDX are widely supported; in-toto/DSSE is an open standard; OCI registries and referrers make attachments portable. Keep your policies declarative and versioned so that migrating from one admission controller to another is a mapping exercise, not a rewrite. Watch for evolving standards in artifact reference models and provenance schemas to ensure your pipeline produces metadata that others can verify without conversion.
Putting it all together: a mental model
Think of your software as a graph. Nodes are artifacts (source, dependencies, images), edges are transformations (builds, scans), and annotations are attestations (SBOMs, provenance, signatures). Sigstore binds identities to edges and nodes; SLSA constrains what edges are allowed; SBOMs describe the composition of nodes. Policy traverses the graph to decide whether a path from source to production is acceptable. With the right scaffolding, this graph is not just traceable—it’s enforceable, queryable, and explainable in minutes under pressure.