Notifications
Clear all
Topic starter
23/06/2026 7:25 pm
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
25/06/2026 3:24 am
SBOM packaging without signing is proof theatre: A generated inventory tells you what a build claims to contain, but it does not prove who produced it or whether it changed afterward. That distinction matters because auditability depends on verifiable artefacts, not on well-formed documents. The practitioner conclusion is simple: if the SBOM is not signed, it is still a draft of evidence, not evidence itself.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- The same research found that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how quickly new tool ecosystems create fresh exposure surfaces.
A question worth separating out:
Q: How can organisations tell whether their SBOM process is actually working?
A: A working SBOM process can generate an SBOM for every release, sign it automatically, let consumers verify it independently, and retrieve the record quickly during an audit or incident. If any one of those steps is inconsistent, the process is only partially controlled.
👉 Read our full editorial: SBOM signing is the missing proof layer for software trust
