Software bill of materials (SBOM) adoption is accelerating. But “having an SBOM” isn't the same as being able to trust it. Your customers and auditors want evidence that what shipped is what you documented. SBOM signing is how you turn an inventory list into verifiable proof.

DigiCert’s State of Software Supply Chain Security 2026 research shows the gap clearly. Only 11% of organizations are actively providing SBOMs today. And of the organizations that do provide SBOMs, only 17% always sign them.

What an SBOM is (in audit-ready terms)

A software bill of materials is a structured list of components in a software artifact. It typically includes package names, versions, licenses, and dependency relationships.

An unsigned SBOM is an assertion without proof. 

If an SBOM can be edited after the fact, it can’t support provenance claims. If it can't be tied to a specific build, it can't support release integrity.

Why SBOMs fail in the real world

An SBOM is supposed to answer a simple question: What components are in this software release?

Most programs struggle because SBOMs are operational, not conceptual. The State of SSC Security report highlights the biggest blockers. 

These aren’t edge cases. They’re the reasons SBOM programs stall after the first “we can export CycloneDX” demo.

SBOM signing: The missing link between inventory and integrity

Most SBOM discussions focus on visibility. Mature programs focus on enforceability.

The State of SSC Security report highlights an inconsistent approach to SBOM signing. Only 17% always sign SBOMs, while many sign conditionally or plan to implement later. 

Attackers don't target your strongest controls—they target your weakest. An unsigned SBOM can be modified to conceal tampering, misrepresent software contents, or obscure the source of a compromise.

This creates a verification gap. If recipients can’t confirm an SBOM’s authenticity, they’re forced to rely on trust, not cryptographic proof.

SBOM signing closes that gap by making software integrity verifiable.

What SBOM signing should guarantee 

A signed SBOM should give you three things:

• Authenticity:The SBOM came from your pipeline, not a shared folder.
• Integrity: The SBOM hasn't changed since it was produced.
• Traceability: The SBOM maps to a specific artifact, build, and release.

Make SBOM signing a hard requirement, not a best practice

The report’s strategic recommendation is direct: Make SBOM signing a non-negotiable step in delivery. That’s the difference between “we can produce SBOMs” and “we can prove what shipped.”

Here’s a pragmatic policy posture that scales:

• Every release artifact produces an SBOM in CI/CD.
• Every SBOM is signed automatically.
• Every signature is produced with protected keys.
• Every signed SBOM is stored and retrievable for audits.
• Every consumer can verify signatures before relying on contents.

A practical SBOM workflow that doesn’t slow down CI/CD

If you want SBOMs to work at release velocity, sequence matters.

1. Automate SBOM generation where the build happens.

SBOM generation should be part of the build process, not a separate compliance activity. Generate SBOMs automatically in CI/CD by default.

2. Bind the SBOM to the artifact you ship.

An SBOM without release context is hard to validate. Link the SBOM to a specific image, binary, or package using immutable identifiers like digests and build metadata.

3. Sign the SBOM automatically every time.

Manual signing steps often break down under release pressure. Automate SBOM signing as part of the release workflow.

4. Store signing keys in a protected system.

Signing keys stored on developer workstations create unnecessary risk. Mature programs use hardened key storage and embed key management into release workflows.

5. Make verification easy for downstream teams.

When a vulnerability emerges, teams need to quickly identify affected releases. That requires SBOMs that are reliable, retrievable, and verifiable.

Where DigiCert Software Trust Manager fits

Many SBOM programs stall because the “proof” layer is bolted on late.

DigiCert Software Trust Manager is designed to help operationalize policy-driven signing across the software supply chain. The report specifically calls out Software Trust Manager as a way to manage code-signing certificates, keys, and workflows, automate signing, prevent tampering, and enforce compliance with FIPS-compliant HSMs.  

In SBOM terms, that matters because SBOM signing needs:

• Strong key protection
• Consistent enforcement in CI/CD
• Audit-ready evidence by default

The goal isn't “more tools”—it’s fewer manual exceptions.

The SBOM maturity test

If you want a simple benchmark, ask yourself these questions:

• Can you generate an SBOM for every release automatically?
• Can you prove the SBOM hasn't been modified?
• Can customers verify SBOM authenticity independently?
• Can you retrieve SBOM evidence quickly during an audit?
• Can you enforce these practices across every pipeline, not just one?

If you answer “not consistently” to any of these questions, your SBOM program is still about visibility, not integrity.

Signed, automated SBOMs turn visibility into verifiable trust.