Beyond SBOM: What CBOM, QBOM, and xBOM Actually Give You
Which Bills of Materials are real specifications, what each one can and can't tell you, and how to wire them into a delivery pipeline.
Executive brief
- A Bill of Materials is an inventory, not a verdict. An SBOM lists software components, a CBOM adds cryptographic assets, and a QBOM (still an emerging term) focuses on quantum-related cryptographic risk. None of them proves a system is secure on its own.
- SPDX and CycloneDX are the two established exchange formats. SPDX 2.2.1 is ISO/IEC 5962:2021, and CycloneDX is Ecma International ECMA-424. CycloneDX covers SBOM, CBOM, HBOM, AI/ML-BOM, SaaSBOM, and OBOM.
- xBOM is an informal umbrella word, not a specification, and QBOM definitions vary from source to source. Check the definition before you rely on either.
- "One scan, multiple BOMs" is a product claim. Each BOM type needs different evidence, so ask what each scan can and can't see.
- Generate BOMs in CI/CD, validate them, store them with the release, and enforce risk-based policy instead of failing builds on every finding.
- Adopt in phases: reliable SBOMs first, then cryptographic visibility, then quantum readiness.
Software supply chain security started with one question: what's inside the thing we build and ship? That question is still the right one to begin with, but it's no longer the only one. Software also depends on cryptographic libraries, algorithms, certificates, hardware, build tools, and external services, and a plain list of packages doesn't capture most of that.
So the family of BOMs has grown. CBOM, QBOM, and a handful of others stretch visibility into areas that matter more each year for security and compliance. The hard part is knowing which of these terms are established specifications, what each inventory delivers, and how to fit them into an engineering workflow without drowning in files nobody reads.
1. SBOM: the foundation of software transparency
An SBOM records the software components in an application or system. Depending on the tool and format, you'll get package names, versions, suppliers, dependency relationships, licenses, and other component metadata.
The classic payoff is the morning a vulnerability lands in a widely used library. Someone has to find every application that ships the affected version. With a current SBOM that's a query. Without one it's a day of chasing people on chat.
- Vulnerability management and impact analysis during incidents
- Open-source license compliance
- Third-party component risk assessment
- Supply chain transparency for customers and auditors
- Knowing, with evidence, what you shipped
Two specifications dominate exchange of this data. SPDX is an international open standard, published as ISO/IEC 5962:2021 for version 2.2.1, with version 3.0 available through the SPDX project. CycloneDX started at OWASP and is standardized as Ecma International ECMA-424. Primary sources: the SPDX specifications and the CycloneDX specification overview.
One caution before going further. An SBOM doesn't establish that software is secure. What it's worth depends on the completeness, accuracy, freshness, and provenance of the inventory, plus the process you've built to act on what it shows. A stale SBOM is worse than none, because people trust it.
Pick a production release from six months ago. Can your team list every third-party component in it, with exact versions, in under an hour?
2. CBOM: making cryptographic assets visible
Cryptography is everywhere in modern software: TLS connections, digital signatures, authentication, encryption, key exchange, data protection. Yet knowing which libraries an application contains doesn't tell you how cryptography is actually used across the whole system.
A Cryptography Bill of Materials (CBOM) closes part of that gap by documenting cryptographic assets and how they relate to software and systems. What you get depends on the tool and implementation, but a CBOM may capture:
- Algorithms and their parameters
- Cryptographic libraries and implementations
- Protocols and cryptographic operations
- Certificates, keys, and related metadata, where the tool supports it
- Where in the code or system those functions are used
- Relationships between cryptographic assets and system components
Take a financial services application. It might use one library for TLS, another for digital signatures, and a separate service for key management. A CBOM helps a security team map those dependencies and see where a cryptographic change would ripple.
CycloneDX supports CBOM, and its project describes the capability on the CycloneDX CBOM page. Coverage depth, though, comes from the scanner: supported languages, runtime visibility, and the analysis method. Generating a CBOM is not the same as discovering every cryptographic operation in a running system. Static analysis of source will miss a cipher suite set on a load balancer, and it won't see a certificate that lives only in a vault.
If your security team had to find every use of RSA across your estate by Friday, where would they start, and how sure would they be they'd found all of it?
3. QBOM: preparing for quantum-related cryptographic risk
Quantum computing is a longer-term problem for cryptography. Some widely deployed public-key algorithms, including RSA and elliptic-curve cryptography, are considered vulnerable to sufficiently capable quantum computers running suitable algorithms.
That doesn't make all current encryption equally exposed. Risk depends on the algorithm, how it's used, what quantum capability actually exists, and the security requirements of the system.
A Quantum Bill of Materials (QBOM) is an emerging term for an inventory of quantum-related cryptographic information. Depending on the definition in use, it can cover quantum-vulnerable algorithms, quantum-safe algorithms, and the cryptographic assets likely to change during a migration. Its terminology and scope are not yet as consistent as SBOM's.
It's turning up in real guidance anyway. India's CERT-In published technical guidelines in 2025 that address several BOM types, including SBOM, CBOM, QBOM, AI BOM, and hardware BOM (see CERT-In). On the algorithm side, NIST maintains its post-quantum cryptography project, which is where standardized replacements are tracked.
A QBOM-oriented inventory should help you answer questions like these:
- Where do we use algorithms that may be vulnerable to future quantum attacks?
- Which applications depend on them?
- Which systems handle information that has to stay confidential for many years?
- Which cryptographic dependencies need a closer look?
- Where should post-quantum migration planning begin?
The long-lived data point is the one that drives urgency. If you store sensitive financial, healthcare, or infrastructure data, what's captured today may still be valuable in ten years. An adversary can collect encrypted traffic now and try to decrypt it later, if the protection becomes breakable. People call this harvest now, decrypt later.
An inventory tells you where cryptographic dependencies exist. It doesn't tell you whether a system is vulnerable, and it can't prove a migration is finished. Pair it with cryptographic risk assessment, asset criticality, data retention requirements, and an actual migration plan.
Which of your systems hold data that must stay confidential for ten years or more, and which public-key algorithms protect that data in transit and at rest?
4. What about xBOM and the other BOM types?
You'll hear "xBOM" used as an umbrella for multiple or extended Bills of Materials. Treat it as a figure of speech. There's no single, universally defined xBOM specification, and it shouldn't be confused with one.
| BOM type | Primary purpose |
|---|---|
| SBOM | Inventory of software components and dependencies |
| CBOM | Inventory of cryptographic assets |
| QBOM | Quantum-related cryptographic inventory, depending on the adopted definition |
| HBOM | Inventory of hardware components |
| AI/ML-BOM | Inventory of machine learning models and related assets |
| SaaSBOM | Transparency into software-as-a-service components and dependencies |
| OBOM | Operational assets and configuration information |
CycloneDX supports several of these: SBOM, CBOM, HBOM, AI/ML-BOM, SaaSBOM, and OBOM. Maturity, adoption, and standardization vary a lot between them, so confirm the applicable specification and the tool's actual support before assuming two tools mean the same thing by the same acronym.
The goal isn't the biggest possible pile of BOM files. It's reliable information that supports specific engineering and security decisions.
5. SPDX and CycloneDX: why formats matter
BOM data is only useful if different tools can exchange it without losing meaning. SPDX and CycloneDX give you defined data models and serialization formats, so inventory can move between development tools, security platforms, and compliance systems. CycloneDX is the one to look at first if you want a single specification across software and cryptographic inventories.
Format support doesn't guarantee feature coverage, though. A tool can export a perfectly valid CycloneDX document that holds only a sliver of the component or cryptographic data available. When you evaluate a tool, check:
- Which specification versions it supports
- Which BOM types it can generate
- Whether it captures direct and transitive dependencies
- How it identifies and represents cryptographic assets
- Whether the output validates against the relevant schema
- How it records source information and scan provenance
- Whether downstream security tools can consume the export
Interoperability pays off only when the data is complete, accurate, and something a person can act on.
6. Integrating BOM generation into CI/CD
A BOM generated by hand before an audit is a snapshot of one afternoon. It gets valuable when generation is part of the delivery process, with analysis, policy, and publication attached. Here's the workflow we'd put in place.
- Generate inventories during the build
Produce an SBOM from the source tree, dependency manifests, build outputs, or the final artifact. Generate other inventories such as a CBOM where your tools and project requirements support it.
- Validate the output
Check that each BOM document is valid against its schema, carries the required metadata, and names the artifact or release it belongs to.
- Run security analysis
Correlate the component inventory with vulnerability data. Run cryptographic analysis to find algorithms and implementation risks, and apply policies for deprecated algorithms and post-quantum readiness where you have them.
- Enforce risk-based policies
Not every finding should stop a build. Set rules by severity, exploitability, business impact, regulatory requirements, and available mitigations. Block on a prohibited algorithm or a critical, exploitable dependency flaw, and send the rest to a documented exception or a remediation ticket.
- Publish and retain the results
Store BOMs and scan results next to the build artifacts, release metadata, or registry records, so anyone can tell which inventory belongs to which software version.
- Reassess after changes
A BOM is a snapshot. Dependency updates, build changes, new vulnerability disclosures, and cryptographic policy changes all age it. Regenerate when it makes sense, and rescan existing artifacts when new risks emerge.
On embedded Linux the build system is a good place to start, since it already knows what went into the image. Yocto, for example, can emit SPDX documents during the build, so the inventory comes from the same recipes that produced the firmware instead of from a scan bolted on afterward.
When a new CVE drops tonight, can your pipeline tell you which released versions are affected without anyone opening a spreadsheet?
7. What "one scan, multiple BOMs" really means
Generating several BOM types from a single scan sounds great. Less duplicated work, one place to look. But the phrase describes what a product does, not what an industry standard requires, and it deserves the same scrutiny as any vendor claim.
Different BOM types need different evidence. A package scanner may produce a fine SBOM and still have little visibility into cryptographic operations buried in application code. A binary scanner may find more, and still miss runtime behavior or cryptographic services hosted somewhere else entirely. So a single scan shouldn't be assumed to cover every inventory type.
A credible implementation can explain:
- Which BOMs it generates
- Which inputs and scanning methods it uses
- What each scan can and can't discover
- Which output formats and versions it supports
- How findings are validated and tracked
- Which extra tools or runtime data you'll still need
If a product says it generates five BOM types, it should name all five and show the coverage of each. A claim of five that lists four leaves the interesting question unanswered.
8. A practical adoption strategy
Nobody needs every BOM type on day one. A phased approach works better, and it keeps each step small enough to finish.
| Phase | Focus | What it involves |
|---|---|---|
| 1. Software transparency | SBOM | Reliable SBOMs for critical applications and production releases. Define ownership, storage, validation, and a vulnerability response process. |
| 2. Cryptographic visibility | CBOM | Identify cryptographic libraries, algorithms, protocols, and related assets. Introduce CBOM generation where supported and set policy for cryptographic risk. |
| 3. Quantum readiness | QBOM-oriented inventory | Find potentially quantum-vulnerable dependencies. Prioritize by data sensitivity, expected confidentiality lifetime, operational criticality, and migration complexity. |
| 4. Automation | CI/CD enforcement | Wire generation, validation, analysis, and policy checks into the pipeline. Track exceptions and remediation over time. |
| 5. Measurement | Coverage and quality | Track which critical applications have current inventories, whether findings have owners, and how fast identified risks get closed. |
Good measures here are inventory coverage, time to identify affected applications after a disclosure, unresolved cryptographic risks, and the age of the latest validated BOM. They tell you far more about supply chain readiness than a count of BOM files.
How old is the newest validated BOM for your most critical application, and who owns the findings in it?
9. The compliance angle
Regulation is already pulling inventories into the delivery process, especially for products that ship in the field. The EU Cyber Resilience Act expects manufacturers of products with digital elements to identify and document components, including by drawing up an SBOM, as part of vulnerability handling. Details and timelines are on the European Commission's Cyber Resilience Act page. In the US, FDA expects an SBOM as part of premarket cybersecurity documentation for cyber devices. CERT-In's guidelines, mentioned earlier, take the idea further across several BOM types.
If you build regulated or embedded products, the point to take away is practical: an audit-ready BOM is one you can regenerate for any released version, on demand, from the pipeline.
Inventory is the starting point, not the outcome
SBOMs remain the base layer. CBOMs extend visibility into cryptography, and QBOM-oriented approaches help you plan for quantum-related risk. SPDX and CycloneDX make the data portable, but what you get out depends on what your tools discover and what your engineers do with it.
For DevSecOps teams the next step is unglamorous: generate consistently, validate quality, tie findings to real risk, set clear policy, and keep it all current. The aim isn't to know what a system contains. It's to know which dependencies matter and what has to change before the risk reaches production.
Frequently asked questions
What is the difference between SBOM and CBOM?
An SBOM inventories the software components in a build: packages, versions, suppliers, and dependencies. A CBOM inventories cryptographic assets such as algorithms, libraries, protocols, certificates, and keys, and where they're used. You need the first to track vulnerable dependencies and the second to understand how cryptography is used across a system.
Is QBOM an official standard?
Not in the way SPDX or CycloneDX are. QBOM is an emerging term and its scope varies by source. It generally refers to an inventory of quantum-related cryptographic information, such as quantum-vulnerable and quantum-safe algorithms. Check the definition a tool or guideline actually uses before you rely on it.
What does xBOM mean?
xBOM is an informal umbrella term for multiple or extended Bills of Materials. It isn't a single specification. When someone uses it, ask which specific BOM types they mean and which format they're exported in.
Which format should I use, SPDX or CycloneDX?
Both are established standards. SPDX 2.2.1 is ISO/IEC 5962:2021, and CycloneDX is Ecma International ECMA-424. CycloneDX supports several inventory types including CBOM, which matters if you want one specification across software and cryptographic assets. Pick based on what your downstream tools and customers consume.
Can one scan generate every BOM type?
Treat that as a product claim, not a standard. Different BOM types need different evidence. A package scanner may produce a good SBOM but see little of the cryptography in application code, and neither a source scan nor a binary scan sees runtime behavior or external cryptographic services. Ask any vendor what each scan can and can't discover.
Should every finding block a build?
No. Block on clear policy violations, such as a prohibited cryptographic algorithm or a critical, exploitable dependency vulnerability. Route other findings to a documented exception or a remediation ticket, based on severity, exploitability, business impact, and regulatory requirements.
Want the pipeline side done, not just the policy?
Stonetusker runs fixed-scope 90 day engagements that put SBOM and CBOM generation, validation, and release gating into your CI/CD, including Yocto and other embedded builds. If you'd rather prove it on one product line first, we start with a pilot, billed by milestone.
Talk to us about your supply chain pipelineTerminology and specification references reviewed in October 2026. BOM definitions and implementation support may change as the ecosystem develops.
