Why we used pedigree rather than inventing a field

The hardest input

In April 2014, one defect in one OpenSSL function exposed private memory on TLS endpoints across hundreds of vendor labels in a single day. Heartbleed is remembered as a bug, but for anyone measuring risk it was a concentration measurement taken the hard way. The products differed, but the code did not.

The Applied Quantum CBOM Profile asks for the input that would have shown the pattern in advance, implementation ancestry – which upstream codebase a deployed cryptographic implementation descends from. It is the hardest field in the taxonomy to collect. Suppliers rarely publish derivation, closed source hides it, and no deployed tool emits it.

It is also the input that layer 2 of the Cryptographic Concentration Framework depends on, implementation lineage in that framework’s vocabulary, because an estate can change vendors every year and keep the same inherited code throughout. The Profile’s other consumer, the PQC Migration Framework, doesn’t require the concentration tier at all, which is what tiering is for.

We put the layer 2 problem on the Profile’s cover in eight words: “Switching vendors moves the contract, not the dependency.”

Use what exists

CycloneDX already has the right structure. The pedigree object contains ancestors, descendants, variants, commits, patches and notes, and the specification defines it for forks, where the forked component includes an ancestor entry that references the original. That is the exact semantic ancestry recording requires, and it’s almost never populated.

So we didn’t define an ancestry property. The Profile requires pedigree.ancestors to be populated for cryptographic implementation components wherever ancestry is known or disclosed, and Section 7.1 states the reasoning in one line. Using the existing mechanism demonstrates an intended-but-dormant capability rather than requesting a new one, and any tooling that later populates pedigree becomes immediately useful.

One reading did need fixing, because ancestors is a set and the specification leaves the multiplicity question open. So we fixed it. Within the Profile, siblings at one level are a merge, several direct upstream sources at once, and a chain is expressed by nesting, one ancestor per level, each with a pedigree of its own.

Both forms occur in real cryptographic code. A deployed ML-KEM implementation deriving from mlkem-native, which derives from the pq-crystals reference, is a chain. AWS-LC, described by its maintainers as based on code from both BoringSSL and OpenSSL, is a merge. In a merge the component inherits from both parents directly. In a chain, depth matters, because a defect one hop up almost certainly reaches the descendant, while one several hops up may have been rewritten in between.

Two boundaries keep the record honest, and the first is that pedigree records derivation only. A library that a product merely uses or bundles goes in dependencies and provides, never in ancestors, because descends-from and depends-on propagate defects differently, and conflating them invents ancestry. And where two implementations look nearly identical and the direction can’t be resolved, variants is the honest entry, in preference to guessing.

Divergence claims have an evidence rule of their own. The preferred form is the commits and patches records, and closed-source implementations may substitute reproducible source comparison, supplier engineering attestation or validated provenance. Bare assertion is not admissible.

The lineage delta

What pedigree can’t say is how we know, and whether the supplier answered. That delta is the whole of appliedquantum:lineage. lineage:evidence grades the ancestry claim E1 to E5 on the Profile’s evidence ladder, and project-name-only identification grades as inferred. lineage:disclosureStatus records the supplier interaction and separates declined from no-response, because a refusal and a silence mean different things about supplier governance. lineage:cmvpCertificate points at a validation record whose published security policy sometimes names the libraries inside, corroboration for ancestry without being ancestry evidence itself.

And where nothing is known, ancestors stays empty and the absence gets recorded, because a fabricated ancestor defeats the measurement entirely.

Three tests

The discipline behind these choices is the Profile’s extension rule, and it has three tests. Where the standard already has the structure, use it. That is Section 7.1, and pedigree is its largest case. Where the standard is silent and the need generalises past one sector, add the field and propose it upstream. That is the Section 9 status for quantum vulnerability classification, migration state, harvest exposure, certificate references and entropy modelling, none of which is a financial-sector concern. Where the field is sector- or computation-specific, add it and keep it in the namespace permanently, because that is what vendor namespaces are for. Payment context and assessment scaffolding will never belong in a base inventory model. We ran every property in the four tiers through those tests, and Section 9 is the public record of the outcomes, field by field.

The registration and the ask

We filed the appliedquantum namespace with the CycloneDX property-taxonomy registry on that basis, as issue #189, RESERVED until the registry row is added, through the same mechanism BSI uses for TR-03183. Upstream proposals for the Section 9 fields follow this release candidate, and filing status is tracked in the taxonomy repository.

If you maintain CBOM tooling, the concrete request is to populate pedigree. The structure has been in the specification for years, and every ancestry record makes the monoculture question answerable one implementation sooner. The release candidate is open for comment through October 31, 2026, as issues on the same repository.