SBOM signing and software trust: is your release evidence verifiable?

TL;DR: Only 11% of organisations actively provide SBOMs and just 17% always sign them, leaving audit and provenance claims dependent on trust instead of cryptographic proof, according to DigiCert’s State of Software Supply Chain Security 2026 research. Unsigned SBOMs may still enumerate components, but they cannot prove release integrity or authenticity.

NHIMG editorial — based on content published by DigiCert: SBOMs need proof, not just packaging

By the numbers:

• Only 11% of organizations are actively providing SBOMs today.
• Of the organizations that do provide SBOMs, only 17% always sign them.

Questions worth separating out

Q: How should security teams implement SBOM signing in CI/CD pipelines?

A: Treat SBOM signing as part of the build, not a separate compliance task.

Q: Why do unsigned SBOMs create governance risk?

A: Unsigned SBOMs create governance risk because they can be edited after creation, detached from the artifact they describe, or used as evidence without cryptographic assurance.

Q: What breaks when SBOMs are produced but not signed?

A: What breaks is the trust model.

Practitioner guidance

• Make SBOM signing a release gate Require every build to generate and sign an SBOM automatically before release approval.
• Bind each SBOM to a specific artifact Use immutable build identifiers, digests, and release metadata so downstream teams can verify that the SBOM describes the exact binary or image that shipped.
• Protect signing keys like production credentials Store signing keys in hardened systems with restricted access and auditable use, rather than on developer workstations or loosely controlled shared systems.

What's in the full article

DigiCert's full blog covers the operational detail this post intentionally leaves for the source:

• How the Software Trust Manager workflow handles code-signing certificates, key protection, and release-time enforcement.
• The practical mechanics of storing signing keys in hardened systems and maintaining audit-ready evidence.
• The release workflow patterns that keep SBOM generation, signing, and retrieval tied to CI/CD without manual exceptions.
• The vendor's specific compliance framing for FIPS-compliant HSMs and controlled signing operations.

👉 Read DigiCert's analysis of why SBOMs need signing for software trust →

SBOM signing and software trust: is your release evidence verifiable?

Explore further

View Full Forum →  |  NHI Foundation Course →