CBOM - compliance information item for Post-Quantum Cryptography

[pietrodematteis]

I'm currently working on Post-Quantum Cryptography use cases based on CBOM.
I'd like to ask whether the specification considers a way to represent or export compliance information related to frameworks or guidelines such as NIST Post-Quantum Cryptography.

Similar to SBOMs use case, where vulnerabilities can be exported (using for example Dependency-Track tool) and their applicability communicated through VEX documents, is there an equivalent concept within the CBOM ecosystem for reporting deprecated algorithms, quantum-vulnerable assets, or PQC migration status with respect to a specific framework or guideline, such as the NIST PQC standards and migration guidance?

If not, is there a recommended approach for modeling and exchanging this type of information in a CBOM?

[stevespringett]

Good question.

One reframe first: for crypto, "vulnerable" usually depends on intended use. RSA-2048 protecting a short-lived session token is a very different risk from the same algorithm protecting data that has to stay secret for decades. So, applicability here is mostly a question of how the asset is used, which is where behaviors come in.

Today (1.6/1.7), most of this is expressible by pairing a CBOM with CycloneDX Attestations (CDXA):

• Intrinsic posture is on the asset: nistQuantumSecurityLevel, classical strength, protocol, and function details.
• Conformance to a guideline (NIST PQC, FIPS 203/204/205, SP 800-131A): model it as a standard with requirements, then attest an asset's bom-ref with evidence and a conformance.score. That is your exportable, VEX-style meets / partially meets / does not meet, independent of the CBOM.
• Applicability: a deprecated algorithm can be a vulnerability whose affects targets the cryptographic-asset component, with the usual VEX analysis.

What's missing today is intended use, a real migration status, and a framework-agnostic risk object. That is what 2.0 adds:

• Behavior: captures how and why an asset is used, which is what actually decides "vulnerable" in context.
• Risk: a first-class, framework-agnostic risk that affects the asset and links to the standard, claim, and weakness.
• Weakness: shared classification (CWE-327 fits).
• Control + mitigation: the migration is a control whose implementationStatus is the machine-readable migration state; a riskResponse records the plan.
• Requirement / use case: the guidance as requirements, the intended use as a useCase.
• Assessment: wraps it all as a PQC-readiness exercise you can run periodically or continuously.

Two open issues are the best place to push this: #670 (declaring usage context, which ties into the behavior work and calls out PQC readiness directly) and #669 (grouping assets under the named standard they implement). We're also planning to generalize certification beyond today's FIPS 140 and Common Criteria enum so any component, party, or crypto asset can carry any certification type.

Happy to sketch a concrete worked example, and the Cryptography WG call is a good place to take it further.

[ngr-dev1]

Great question — I've been building tooling in exactly this space (mapping CBOM assets to the EO 14412 / NIST IR 8547 timeline), so let me share where I've landed, because I think the honest answer is "partly, and the gap you're sensing is real."

What CycloneDX gives you today, natively:

• Asset condition: relatedCryptoMaterialProperties.state (NIST SP 800-57 lifecycle) for keys/certs, and algorithmProperties (primitive, parameterSetIdentifier, nistQuantumSecurityLevel, cryptoFunctions) for algorithms. That's enough to say "this asset is quantum-vulnerable" on its own terms.
• Attested claims: CDXA / the Declarations model (claims, evidence, conformance, signatory) — tightened in 1.7 and aligned with in-toto/SLSA — is the closest thing to a "VEX for crypto." It's designed to assert conformance-to-a-standard with evidence.

What's genuinely missing, and I think is the heart of your question: there's no standardized framework-conformance vocabulary for PQC. VEX works because "affected / not affected / fixed" is a small, agreed enum against a CVE. There's no equivalent agreed enum for "compliant / migrate-by-2030 / migrate-by-2031 / already-disallowed" against a named framework revision.

Two things I learned the hard way building this that I think matter for any spec proposal:

1. The conformance verdict can't be derived from the algorithm alone — it depends on usage. RSAES-OAEP is a 2030 item (key establishment); RSASSA-PKCS1-v1_5 is a 2031 item (signatures). Same modulus, same key length, one year apart — and lots of generators emit both as just "RSA-2048." So any framework-mapping field has to hang off the (primitive × cryptoFunction/usage) pair, not the asset name. A flat "deprecated: true" would lose exactly the distinction that matters.

2. The mapping is versioned and time-dependent. "Compliant against IR 8547" means something different in 2026 vs 2031. Whatever carries the verdict needs to pin the framework revision and an assessment timestamp, or it's not reproducible.

My take: the cleanest path is probably a CDXA conformance profile for PQC frameworks (EO 14412, IR 8547, CNSA 2.0) with a defined status vocabulary keyed on usage — rather than new fields on the crypto-asset itself. Happy to share concrete examples of where the usage-vs-name problem bit me if it's useful to the proposal.