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.
At a glance
What this is: This is a software trust analysis arguing that SBOMs need signing, not just generation, to become verifiable evidence of what shipped.
Why it matters: It matters to IAM and security teams because release integrity, artifact provenance, and downstream verification increasingly depend on signed machine-generated evidence, not just inventory output.
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.
Context
Software bill of materials, or SBOM, adoption is rising, but an inventory file alone does not establish trust. In release pipelines, the governance gap is not whether a software bill exists, but whether recipients can verify that the document still matches the build they received.
For IAM, PAM, and NHI teams, this is a lifecycle and provenance problem rather than a documentation problem. SBOM signing ties the artifact to a known pipeline and key holder, which is what turns a compliance file into evidence auditors and customers can independently verify.
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. An unsigned SBOM may still help with component visibility, but it cannot prove origin, detect tampering, or support strong provenance claims. Security teams should require signature verification before using the SBOM for audit, incident response, or supply chain assurance.
Q: How should organisations use SBOMs to improve software supply chain governance?
A: Treat SBOMs as a live control input. Connect them to vulnerability management, licence review, build approvals, and supplier assurance so they drive action across the product lifecycle. That approach turns inventory into governance and exposes where third-party dependencies create unacceptable risk.
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. That weakens audits, slows vulnerability response, and creates room for altered or misleading component lists to pass as trustworthy. The governance gap is not visibility, but evidentiary reliability.
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.
Technical breakdown
Why unsigned SBOMs cannot prove release integrity
An SBOM is a structured list of components, versions, licences, and dependencies inside a software artifact. By itself, it is only an assertion. If the file can be edited after generation, redistributed from an unrelated location, or detached from the exact build, it cannot support provenance, integrity, or authenticity claims. The trust model depends on the SBOM being bound to a specific artifact and protected from post-build alteration.
Practical implication: Treat SBOM generation and SBOM integrity as separate controls, and do not accept an unsigned inventory file as release evidence.
How SBOM signing creates verifiable proof
Signing adds a cryptographic attestation layer over the SBOM so consumers can confirm who produced it and whether it changed. The value is not visibility alone, but enforceable trust: authenticity proves origin, integrity proves the content stayed unchanged, and traceability links the document to a specific build or release. That combination is what lets downstream teams verify software claims without relying on manual assurance.
Practical implication: Automate signing at release time and require verification before internal or customer consumption of SBOM data.
Why key protection is part of software trust governance
SBOM signing depends on the security of the keys used to produce the signature. If those keys are exposed, a signature can no longer be treated as trustworthy evidence, because the attestation layer itself becomes compromiseable. In practice, this makes signing a non-human identity and workload governance issue as much as a software supply chain issue, because keys, certificates, and signing workflows must be owned, controlled, and retrievable across the release lifecycle.
Practical implication: Place signing keys in protected systems and govern their lifecycle with the same discipline used for other production credentials.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Software trust now includes the lifecycle of the proof itself. The problem is not only inventory completeness, but whether the evidence can be produced, signed, stored, and retrieved consistently across pipelines. This is where software supply chain governance overlaps with identity governance, because the signer, the key, and the artifact must remain bound across the release path. Teams should govern proof generation as part of the delivery process, not as an afterthought.
Key protection is the control boundary for SBOM credibility. A signature is only as reliable as the system protecting the private key and the process that issues it. That makes signing workflows part of non-human identity governance, not just build engineering. The practitioner takeaway is to treat signing keys as production trust assets with lifecycle ownership, rotation discipline, and auditability.
Auditability becomes operational only when verification is routine. If customers, auditors, or internal responders cannot independently verify SBOM authenticity, the organisation still depends on trust claims rather than cryptographic proof. That is a weak posture in a supply chain where altered evidence can hide tampering or obscure a compromised release. Security teams should make verification as standard as generation, because provenance that cannot be checked is not governance.
Signed SBOMs create a new minimum bar for release governance. As software delivery accelerates, the organisations that can prove what shipped will outlast those that can only describe it. This is not a niche compliance refinement. It is the emerging baseline for software trust, and teams that do not embed proof into release workflows will keep inheriting avoidable uncertainty.
From our research library:
- 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.
- Read next: NHI Lifecycle Management Guide
What this signals
Proof layer governance is becoming the real SBOM maturity test: organisations can no longer stop at export capability, because unsigned evidence cannot survive audit scrutiny or downstream verification. The practical shift is from inventory production to lifecycle control over the proof that accompanies each release.
Signed SBOMs also expose a non-human identity management requirement that many release programmes still miss. The signing key, the automation that invokes it, and the artifact it attests to must be governed together, or the release record remains only partially trusted.
For practitioners
- 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.
- Require downstream verification before reliance Make consumers validate signature status and artifact linkage before they use SBOM contents for audit, response, or procurement decisions.
Key takeaways
- The core issue is not whether SBOMs exist, but whether they can be trusted as evidence after the build has completed.
- DigiCert cites a large adoption gap, with only 11% of organisations actively providing SBOMs and only 17% always signing them.
- Teams that automate SBOM signing, protect the keys, and verify the signature downstream turn release metadata into auditable proof.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Signing keys and release evidence are only trustworthy if private material is protected. |
| NHI-07 — Long-Lived Secrets | Persistent signing credentials weaken release trust when they remain usable across pipelines. | |
| Recommendation — Protect SBOM signing keys from exposure and revoke any compromised credential immediately. Reduce long-lived signing credentials and rotate trust material on a defined lifecycle. | ||
| SLSA | L3 — Build integrity | SBOM signing depends on provable build provenance and artifact integrity. |
| Recommendation — Use provenance and attestation controls to bind SBOM evidence to the exact shipped artifact. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signing keys function as authenticators for release evidence and need lifecycle control. |
| Recommendation — Manage signing credentials under IA-5 and enforce rotation, storage, and revocation discipline. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Compromise of signing keys turns trusted evidence into an attack surface. |
| Recommendation — Monitor for credential access against build-signing infrastructure and investigate any key exposure. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- SBOM Signing: SBOM signing is the cryptographic process of attesting that a software bill of materials was produced by the expected pipeline and has not changed since creation. It turns an inventory file into evidence that can support audit, provenance, and release integrity claims.
- Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.
- Cryptographic Attestation: Cryptographic attestation is a method of proving that a workload or service is genuine by using cryptographic evidence instead of static shared secrets. It is especially useful for short-lived access models because identity proof is tied to runtime context rather than reusable credentials.
Deepen your knowledge
NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or supply chain assurance programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org