CBOM tells you what you run. P-CBOM tells you what it costs.

A CBOM tells you what cryptography you run. It doesn’t tell you what it costs. That gap is the whole reason P-CBOM exists.

CycloneDX’s Cryptography Bill of Materials is a genuinely good artifact, and it’s arriving at the right time — EO 14412 names the CBOM in federal post-quantum work, which means a lot of organisations are about to generate their first one. What it gives you is an inventory: this component uses ML-DSA-65, standardised under FIPS 204, implemented by this library. Full stop.

That is exactly the information you need to answer “what do we have?” It is exactly none of the information you need to answer “what will it cost us to run this?” An inventory line for ML-DSA-65 doesn’t tell you how it performs on the hardware you’re about to put it on, how large its signatures are on your wire, or how much of your connection budget it eats. Those are the numbers a migration is actually planned against, and the CBOM has no slot for them.

What P-CBOM adds

One thing: a performance record, attached to the same component the CBOM already describes, carrying the four fields that make a number checkable rather than quotable — a source, a run reference, a commit, and a timestamp.

That combination is the entire point. A performance figure with no commit and no date is a claim. The same figure carrying the run that produced it is a measurement someone else can reproduce or dispute. Attaching it to the inventory entry means the artifact your auditor already asks for starts carrying the evidence your architect already needs.

The design constraint, which is the interesting part

P-CBOM does not extend CycloneDX’s cryptoProperties object. That schema is closed by design, and adding a custom key inside it would produce documents that fail validation — which would make the extension worse than useless, because it would break the very tooling ecosystem that gives the CBOM its value.

Instead it rides in the properties[] array, CycloneDX’s own sanctioned extension point, under a dedicated namespace. The consequence is the design goal: a tool that has never heard of P-CBOM still parses the document as valid CycloneDX and quietly ignores the extra fields. No forks, no dialect, no flag day. Extending an ecosystem artifact that regulation already references beats inventing a competing one, and the way you earn that is by being invisible to anything that doesn’t want you.

Why we published it CC0

The specification is CC0; the tooling is Apache-2.0. A standard nobody can adopt without asking permission isn’t a standard, it’s a product with a marketing problem. We would rather P-CBOM end up in someone else’s emitter, uncredited, than own a format nobody uses.

There’s a self-interested version of that argument too, and it’s worth stating plainly rather than pretending otherwise: an inventory format that carries measured performance data is more useful when there is a continuously-measured source to populate it from. We run one. We also think the format should exist whether or not you use ours, which is why the spec doesn’t name us as the required source.

Where this goes

The open questions are the ones worth watching, and we don’t have all the answers:

• What makes an entry trustworthy? A source and a timestamp are necessary. Whether they’re sufficient depends on whether the source re-runs.
• What happens when the number goes stale? A performance record with a timestamp from eighteen months ago is honest but not useful. Freshness has to be legible in the artifact itself.
• Who else populates it? The format is more valuable the moment a second independent measurer emits into it.

Spec and tooling: github.com/Q-Advantage/p-cbom.