Executive Order 14028 mandated Software Bills of Materials. The EU Cyber Resilience Act requires them. CMMC and FedRAMP assessors ask for them. Organizations have invested significant resources building SBOM generation into their software pipelines.
And yet the fundamental question remains unanswered: how do you prove that the SBOM you received accurately reflects the software that was delivered?
This is not a theoretical problem. It is the exact vulnerability that the SolarWinds, Log4Shell, and XZ Utils incidents demonstrated at scale. In each case, the failure was not that organizations lacked documentation — it was that their documentation could not be independently verified against the actual software state.
The core distinction: An SBOM is a description. A CBOM receipt is a proof. A description tells you what something is claimed to be. A proof gives you the means to independently verify that claim without trusting the claiming party.
What an SBOM Cannot Do
An SBOM — whether CycloneDX JSON, SPDX, or any other format — is a document. It is produced by a vendor or developer and delivered to a consumer. Its accuracy depends entirely on the integrity and competence of the producing party.
There is no cryptographic mechanism in the SBOM standard itself that allows a consumer to independently verify that the SBOM matches the software artifact it purports to describe. This means:
- An adversary who can modify a software artifact can also modify or substitute the accompanying SBOM
- An SBOM that was accurate at delivery time cannot be verified to still be accurate during an audit months later
- An organization that relies on an SBOM for compliance without independent verification has not meaningfully reduced its supply chain risk — it has created a document trail that may provide false assurance
- When a regulator asks for proof of software composition state at a specific point in time, an SBOM file with no cryptographic binding cannot provide it
This is not a criticism of SBOM adoption. SBOMs represent meaningful progress in software transparency. The problem is that transparency is not verification — and in adversarial conditions, they are not the same thing.
What a CBOM Receipt Does
A Cryptographic Bill of Materials (CBOM) receipt is a signed verification artifact issued against a software manifest at a specific point in time. Where an SBOM asserts, a CBOM receipt proves.
The process is straightforward. A CycloneDX or SPDX manifest is submitted to the CBOMCompliance.com verification system. The system:
- Normalizes each component string (trimming whitespace, ordering deterministically)
- Computes a SHA-384 hash of each normalized component
- Constructs a binary Merkle tree from the component hashes
- Derives the Merkle root — a single cryptographic commitment to the entire manifest state
- Issues a signed JSON Web Signature (JWS) receipt using RS256
- Returns the receipt to the submitter — retaining nothing
The result is a portable, independently verifiable artifact that proves the manifest state at the moment of issuance. Any party with access to the published public key can verify the receipt — without contacting CBOMCompliance.com, without access to the original manifest, without any coordination with NextGenRails™.
The Three Properties That Matter
1. Determinism
Given identical inputs, the CBOM protocol always produces identical outputs. Two independent parties processing the same manifest will arrive at the same Merkle root. This is the foundation of independent verification — if the outputs could vary, the proof would be meaningless.
2. Binding
The Merkle root is cryptographically bound to the manifest state. A change to any single component — one version number, one dependency name — changes that component's SHA-384 hash, which propagates through the Merkle tree to produce a different root, invalidating the receipt. The binding is enforced by mathematics, not procedure.
3. Independent Verifiability
Verification requires only the receipt and the publicly published key. It does not require the original manifest, access to the CBOMCompliance.com system, or any interaction with NextGenRails™. The issuing authority does not need to be online, cooperative, or even in existence for a receipt to be verified.
SBOM vs CBOM — Direct Comparison
| Capability | SBOM | CBOM Standard | CBOM Advanced |
|---|---|---|---|
| Component inventory | Yes | Yes | Yes |
| CycloneDX / SPDX compatible | Yes | Yes | Yes |
| Cryptographic commitment | No | SHA-384 + Merkle root | SHA-384 + Merkle root |
| Independent verifiability | No | Yes (JWS/RS256) | Yes (JWS/RS256) |
| Tamper detection | No | Yes | Yes |
| Vulnerability intelligence | No | No | OSV + NVD |
| Time-aware re-evaluation | No | No | Yes |
| Zero data retention | N/A | Yes | Yes |
| NIST-approved primitives (FIPS 180-4) | N/A | Yes | Yes |
Regulatory Alignment
Executive Order 14028: EO 14028 requires software vendors supplying the federal government to provide an SBOM meeting NTIA minimum element specifications. A CBOM receipt satisfies and extends these requirements — it incorporates all minimum SBOM elements while adding the cryptographic properties that SBOM alone cannot provide.
CMMC Level 2: Defense contractors subject to CMMC must demonstrate software supply chain risk management under NIST SP 800-161r1. CBOM receipts provide verifiable attestation of software composition at procurement and delivery — exactly the evidence that assessors need to evaluate supply chain controls.
EU Cyber Resilience Act: The EU CRA requires manufacturers to maintain a software bill of materials and address known vulnerabilities. The CBOM Advanced tier directly addresses both requirements: the signed receipt provides the composition record, and embedded vulnerability intelligence provides the known-vulnerability assessment at a specific point in time.
FedRAMP: FedRAMP authorization holders face ongoing software composition attestation requirements. CBOM receipts integrated into release pipelines create a time-stamped chain of verifiable software integrity records that satisfies continuous monitoring requirements.
Three Threat Scenarios Where SBOMs Fail
Scenario 1 — Vendor SBOM substitution: An adversary with access to a software delivery pipeline substitutes a clean SBOM for a manifest that reflects a compromised artifact. With an SBOM, the receiving party has no mechanism to detect this. With a CBOM receipt, the substituted manifest produces a different Merkle root — verification fails and the substitution is detected.
Scenario 2 — Post-delivery manifest alteration: An organization's SBOM records are altered after delivery to conceal a vulnerability. With an SBOM, the altered document is accepted as authoritative. With a CBOM receipt, the receipt is bound to the original manifest state — the altered manifest does not match the receipt, and forensic investigation can recover the original state from the receipt alone.
Scenario 3 — Unknown dependency vulnerability (Advanced tier): A software release includes a dependency that was clean at release time but is subsequently found to have a critical vulnerability. Standard SBOMs cannot tell you the vulnerability state at release time. CBOM Advanced receipts can be re-evaluated against current intelligence sources through the time-aware re-check path, identifying newly discovered vulnerabilities without resubmission of the original manifest.
Zero Retention Architecture
A concern often raised about third-party SBOM verification services is data custody: if you submit your software manifest to an external system, that system now has a record of your software composition — potentially sensitive competitive or security information.
The CBOMCompliance.com system is designed around a zero-retention architecture. No manifest data is written to any persistent storage layer at any point during processing. No component list, dependency graph, or intermediate hash state is retained after receipt issuance. The only persistent output of a verification run is the signed receipt returned to the submitter.
This design has a direct consequence: the issuing authority cannot reproduce the receipt from its own records. Verification relies entirely on the publicly published key and the receipt itself — which is precisely the independence property the protocol is designed to achieve.
Getting Started
CBOMCompliance.com accepts CycloneDX JSON and SPDX JSON manifests directly through the web interface. No account required for Standard tier receipts. Upload your manifest, receive your signed JWS receipt, verify it independently using the public key endpoint.
Organizations already generating SBOMs through existing tooling — Syft, Trivy, cdxgen, or any other CycloneDX/SPDX generator — can apply CBOM verification to their existing outputs without modification. The CBOM protocol is a verification layer, not a replacement for your existing SBOM tooling.
For enterprise integration, API access, and volume licensing, contact via cbomcompliance.com.