Secure your software supply chain by automating SBOM generation and Sigstore signing in 2026. Protect every commit with our step-by-step guide. Read now.
Why SBOMs and signing belong in the same pipeline
A software bill of materials (SBOM) tells you what went into a build: packages, versions, and relationships between components. Sigstore gives you a way to prove who built an artifact and that the bytes have not changed since that moment. Used alone, each is useful. Used together, they close a gap that DevSecOps often leaves open: you can inventory the supply chain and cryptographically bind that inventory to the exact artifact you ship.
In practice that means every commit that produces a release candidate should leave two durable records. The first is an SBOM that reflects the dependency graph at build time. The second is a signature (and related verification material) that attests the artifact—and, when your tooling supports it, the SBOM itself. Reviewers and deploy systems then verify both: “this binary is what we signed” and “this is the component list we claimed for that binary.”
Automate SBOM generation at build time
Generate the SBOM in the same job that compiles or packages the software. Running it later, on a different machine or after manual packaging, invites drift: the inventory no longer matches what you actually distributed. Prefer a format your organization can consume in policy checks and vulnerability scanners, and store the SBOM next to the artifact in the same registry or release store so operators do not have to hunt for it.
Keep the generator deterministic where possible. Pin tool versions in CI, document the SBOM standard you emit, and fail the pipeline if generation fails or produces an empty graph for a project that clearly has dependencies. Treat a missing SBOM as a release blocker the same way you would treat a failed test suite—otherwise “secure the supply chain” stays optional.
Sign with Sigstore as part of every commit-driven release
Wire Sigstore signing into the path that runs after a successful build, not as a separate manual step. When a commit (or merge to a protected branch) triggers a build, the pipeline should produce the artifact, generate the SBOM, then sign the artifact—and sign or attach the SBOM so consumers can verify both. Use short-lived credentials issued for the CI identity rather than long-lived keys sitting in environment variables; that reduces the blast radius if a job is compromised.
Verification belongs as close to deployment as signing does to build. Admission controllers, package installers, or deployment scripts should reject unsigned artifacts and, where policy requires it, reject artifacts whose SBOM is missing, unsigned, or does not match the signed payload. Logging verification outcomes makes audits routine instead of forensic.
- Build and package from a clean CI environment after each protected commit.
- Emit an SBOM from that same environment and store it with the artifact.
- Sign the artifact (and preferably the SBOM) with Sigstore using CI-issued identity.
- Require verification of signature and SBOM presence before promote or deploy.
Operational habits that keep the chain honest
Integration is only half the work. Define who may re-sign after a rebuild, how SBOM formats are versioned when tools change, and what happens when a scanner finds a critical component in an already-signed release. Prefer rebuilding and re-signing from the same commit over patching an artifact in place. Keep runbooks short: how to verify a signature offline, how to fetch the SBOM for an image tag, and how to revoke trust in a compromised CI identity.
Start with one critical pipeline—your main service or public package—and make SBOM-plus-Sigstore mandatory there before expanding. Once generation, signing, and verification are boring and automatic on every commit, you have a DevSecOps 2.0 baseline: inventory and integrity for every release, not only the ones someone remembered to harden.