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.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “SBOMs need proof, not just packaging”.
By the numbers:
- Only 11% of organisations actively provide SBOMs today, according to DigiCert research.
- Of the organisations that do provide SBOMs, only 17% always sign them, according to DigiCert research.
Key questions
Q: How should teams handle SBOMs that are generated but not signed?
A: Treat them as informative inventory, not as trusted evidence of release integrity.
Q: How should organisations use SBOMs to improve software supply chain governance?
A: Treat SBOMs as a live control input.
Q: What breaks when SBOMs are treated as documentation instead of evidence?
A: The organisation loses the ability to prove that the release record is authentic and unchanged after generation.
Practitioner guidance
- Make SBOM signing mandatory at release time Require every release artifact to produce and sign an SBOM automatically inside the build pipeline, with no manual exception path.
- Bind SBOMs to immutable build identifiers Attach each SBOM to the specific image, binary, or package it describes using digests and build metadata so provenance can be verified later.
- Protect signing keys as production trust assets Store private keys in hardened systems and limit signing authority so a stolen workstation or ad hoc script cannot generate trusted evidence.
Bottom line: The core issue is not whether SBOMs exist, but whether they can be trusted as evidence after the build has completed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:24 am
SBOM signing is the control that separates documentation from evidence. A generated SBOM answers what a release contains, but a signed SBOM answers whether that statement can be trusted after the build completes. That distinction matters because audit readiness and customer assurance depend on verifiable proof, not on the mere existence of a file. Practitioners should treat unsigned SBOMs as informational artefacts, not trusted release evidence.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations prioritise SBOM signing or SBOM generation first?
A: They need both, but signing should be treated as the point where SBOMs become operationally useful. Generation creates the inventory, while signing makes it defensible. If a team can export SBOMs but cannot verify them later, it still lacks trusted release evidence.
👉 Read our full editorial: SBOM signing is the missing proof layer for software trust