Guarding the CBOM: The Most Sensitive Document Your Security Program Produces

Introduction

In December 2025, three researchers took a compliance document and turned it into working exploits for pocket change.

Jiarou Deng and Yang Yang of Johns Hopkins, working with Michael Rushanan of Harbor Labs, obtained a de-identified, FDA-compliant software bill of materials from a real cardiac device. They ran it through OWASP Dependency-Track to match components against public vulnerability databases, which returned 45 vulnerabilities, filtered those to the high and critical findings, and selected nine for testing.

They passed each one to OpenAI’s o3 model with a fixed prompt asking for a vulnerable environment, an exploitation strategy, and a way to tell whether the exploit worked. Then they built each generated environment as a container and ran the generated exploit against it. Seven of the nine succeeded. Each cycle took between ten and thirty minutes of analyst time and under twenty cents of compute. The equipment was a laptop, an internet connection, and a consumer chatbot subscription.

That was an ingredients list. Components and versions, nothing more, and the attacker still had to look up what each one was vulnerable to.

Now picture handing them the weakness list instead. That is a cryptographic bill of materials, and its security is the part nobody wrote down.

Over the past two years I have watched a specific reaction in client meetings and at conferences. I describe a cryptographic inventory as a target list, and somebody in the room stops writing. Not because the idea is difficult, but because nobody had said it to them before. These are competent people running serious programs. They were handed a requirement, they built what the requirement asked for, and at no point did anyone tell them the output belongs in a different handling regime from the rest of their documentation. There is no reason they should have worked it out unprompted. Every regime compelling this artifact is silent on the question.

Four claims, then, and the rest of the article is the evidence.

1. Regulated organizations are being pushed toward a cryptographic bill of materials now, from several directions at once, even where no single rule names the complete artifact.
2. It is among the most sensitive documents a security program produces, because it is a ranked target list for attackers with a quantum computer and for attackers with nothing but a laptop.
3. It stays useful to an attacker for years. A pentest report goes stale as the findings get fixed. This one doesn’t, because the systems hardest to migrate are the ones that stay, and those are exactly the systems it lists. So you start protecting it on day one, before the first review cycle.
4. Almost nobody has told you any of this. One national CERT has said a version of it. No standards body has produced a handling model for the artifact, and as of August 15, 2026 none has been published.

The fourth claim is easy to misread, so here is what it does not say. None of this argues against building an inventory. Not knowing what cryptography an estate runs is not a security control, and I return to that at the end.

Claim one, the inventory is coming anyway

The regulatory drivers arrived from different directions and now overlap. Financial entities in the European Union are working through DORA. Manufacturers are working through the Cyber Resilience Act. Anyone taking card payments has PCI DSS requirement 12.3.3, which has required a documented inventory of cryptographic cipher suites and protocols in use since it became mandatory on March 31, 2025. Indian organizations have CERT-In’s bill of materials guidelines, which cover cryptographic and quantum BOMs alongside software ones.

American federal agencies and their contractors have Executive Order 14412, which gives CISA and NIST until March 2027 to define what a CBOM contains. Europol’s Quantum Safe Financial Forum asked the financial sector for a cryptography management framework, and the January 2026 prioritization work with FS-ISAC opens by telling institutions to inventory every business use case that depends on public key cryptography.

And one reason would survive if every regime above vanished tomorrow. Nobody migrates what they have not inventoried. Every serious migration methodology, mine included, starts with discovery, because a decade of work cannot be sequenced without knowing what is there. The CBOM is the operational spine of the program. The compliance requirement is downstream of it.

So the question is not whether you end up with this document. It is what you do with it once you have it.

Claim two, a target list for both threat models

Start with the part that does not involve quantum computing at all.

Across the cryptographic discovery engagements my team has run on enterprise estates, we find quantum-vulnerable cryptography every time. We also find cryptography that is broken right now, on today’s threat model, with no quantum computer required. SHA-1 still signing something in a legacy process nobody owns. Hardcoded keys in application code. ECB mode where someone needed encryption in 2011 and reached for the first example in the documentation. Static initialization vectors. Key reuse across environments. Self-signed certificates on internal services that turned out to be reachable from a partner network. TLS 1.0 endpoints that the asset register said were decommissioned in 2019.

This is not a side effect. The framework I use treats it as a first-class output. Phase 1 of the Applied Quantum PQC Migration Framework routes classically vulnerable findings to security operations for immediate remediation, separately from the migration backlog, because the two categories have different deadlines. NIST SP 1800-38B, the NCCoE discovery volume, is built around an architecture that combines contributed tools observing different parts of the estate, on the consortium’s finding that no single product finds every instance. A thorough program therefore runs several tools, and every one of them returns present-tense findings.

A CISO who files CBOM protection under quantum, and therefore under the 2030s, has misfiled it by a decade. It is exploitable the day it is written.

Set that against Deng’s experiment, whose input named components and versions and stopped there. A CBOM names the algorithm, the key length, the protocol version, the certificate and its expiry, the library and its version, and the implementing hardware. Then it adds the context that makes an inventory useful: whether the endpoint faces the internet, how sensitive the protected data is, how long that data stays sensitive, which vendor controls the remediation, and who owns the system.

Those fields are what turn a record into a ranking. Consider the query a mature inventory exists to answer: show me every system using RSA-2048 for key establishment, facing the internet, protecting data with a twenty-year confidentiality requirement, where a vendor controls the remediation. For defense that query produces a migration sequence. For offense it produces a target sequence with the difficulty of each target annotated, because the systems flagged as hardest to fix are the systems that will still be vulnerable when the attacker gets there.

Deng’s team needed a language model to turn an ingredients list into an attack plan. Nobody needs one to read a CBOM. Ranking exposure is what it is for.

I hold other people to the claim-evidence gap, so here is mine on the HealthSec paper. It is a workshop paper covering one device, one model, and containerized rebuilds of the vulnerable components rather than the cardiac device itself, so nothing here shows what happens against real deployed hardware. Seven of the nine tested CVEs were exploited, and those nine were the ones Deng, Yang and Rushanan selected from a larger high and critical set, so the success rate for the device as a whole is unknown. Their own account of how that larger set became nine does not add up in the paper, which they do not explain. And the SBOM was never actually published: they assumed publication in order to model the risk, so the scenario is hypothetical even though the exploits were real.

It shows feasibility. It does not show how often this happens in the wild. But the conversion from compliance artifact to attack plan is now cheap enough for three academics to run end to end for the price of a coffee, and that is all my argument needs.

Claim three, shelf life

This is the one I most want a CISO to take away, because it corrects an instinct rather than adding a fact.

Security teams have handled sensitive assessment output for thirty years. Pentest reports, vulnerability scans, red team findings. The instinct that comes with it is that these things go stale. A pentest report describes the estate for two weeks, the findings get fixed, and six months later most of it is history. Most teams treat it as sensitive for about a year and then stop worrying. That instinct is right, for that artifact.

It is wrong for this one. Yes, parts of a CBOM go stale fast. Certificates expire, endpoints come and go, configurations drift, all of which forces a refresh. But the parts an attacker wants are the parts that don’t move. A vendor dependency that controls the remediation. An embedded library in a device with a fifteen-year service life. An operational technology segment with no maintenance window. The system whose owner left in 2019 and was never replaced. Those are precisely the entries a migration program flags as hard, and they survive several planning cycles.

So the parts that decay fastest are the parts an attacker cares least about. An organization that leaks its CBOM in 2027 has not handed over a document that expires. It has handed over the durable core, which is the part an attacker wants.

Two things follow from that. First, protection has to start at generation, because there is no window in which the document is not yet dangerous. A CBOM generated on a laptop, dropped into a spreadsheet and mailed to four people has already left a trail that will still be accurate when those four people work somewhere else.

Second, harvest-now-decrypt-later applies to the artifact itself. A CBOM recorded in transit today under classical key establishment becomes readable to an adversary with a CRQC later. Most harvested traffic has to stay relevant across the years of waiting. This file does, because it describes the estate the attacker will find when the wait ends, and it tells them which of their other harvested traffic to decrypt first.

The same logic extends to trust-now-forge-later exposure, since the certificate and signing inventory is in the same file.

The recursion problem

Here is a question I have never once heard a program ask. What is protecting the repository?

If the answer is your PKI, your identity provider, and the TLS in front of the application, then you are protecting the map with the cryptography the map calls weak. Three years into a ten-year migration the estate is still running unmigrated cryptography, and the repository authenticates against the same infrastructure as everything else. That is not a corner case. Most of the CBOMs I have seen are internal web apps behind single sign-on, authenticating against the very thing they document.

So the repository breaks every risk-scoring model I have built. High on data sensitivity, low on exposure, low on business criticality, and a weighted model drops it into the second or third wave behind revenue systems. Put it in the first wave anyway. A compromised inventory compromises the program meant to fix everything else. The risk-driven approach I argue for elsewhere needs an exception for its own output, and I am adding one.

Claim four, the handling gap

Now check those same regimes against the question of protecting the output. Exactly one of them has a real answer, and it is India’s.

CERT-In’s guidelines are the counterexample, and they go further than a gesture. Recommendation 8.4.1.12 requires that CBOM and QBOM data be stored and transmitted securely using encryption, access control and data integrity mechanisms, to protect sensitive technical and architectural information. Best practice 8.4.2.1 asks for a single access-controlled inventory of cryptographic assets with access limited to authorized personnel.

Section 5.3 goes further for BOM data generally, specifying role-based access control, restricted access for sensitive entries, a split between a public BOM and a private one, and logging and auditing to track access and changes. Section 3.1 tells organizations to maintain a complete internal BOM while producing a customized version for consumers that addresses their security requirements without exposing sensitive data.

A two-tier disclosure model, an access model, and an audit requirement, in a July 2025 document. Further than anyone else has gone. Anyone building a handling model should read Section 5.3 before inventing their own.

What it is not is a model built for this artifact. The same provisions repeat almost word for word across SBOM, CBOM, AIBOM and HBOM, so they were written for bills of materials as a category, when the thing in front of us is a ranked weakness map. Nothing on which fields are dangerous in combination. No redaction profile that changes by audience. Nothing on why this inventory outlasts a vulnerability scan, nothing on watching the query rather than the access, and nothing at all on the aggregator with four hundred clients’ inventories in one tenancy.

Everyone else has less. Executive Order 14412 does not order anyone to produce a CBOM. It has agencies review their high-value-asset inventories, names a migration lead for each agency’s cryptographic inventory, directs the FAR Council to propose contractor rules, and tells CISA and NIST to define what a CBOM contains and make it machine-consumable. I have read it four times for anything on how the resulting document should be classified, handled, shared or protected. It is not there.

The nearest existing template is the 2026 Minimum Elements for a Software Bill of Materials, published on July 29, 2026 by eighteen authoring organizations, CISA plus seventeen partners including ANSSI, the BSI, CERT-In, Italy’s ACN and the Dutch NCSC, with the European Commission’s DG CONNECT contributing to the drafting. It is a careful document that incorporates more than ninety public comments. Its scope section puts data management and storage practices out of bounds, and it removes Access Control as a stand-alone element, folding those considerations into Distribution and Delivery on the reasoning that practice has moved on since 2021.

For an ingredients list, that is defensible. The 2026 document also contains the seed of something better, in a place nobody is looking: its Explicitly Identifying Unknown Information element requires authors to distinguish data that is genuinely unknown from data being deliberately withheld, and expects a process through which recipients can ask about redacted security-related content. That is the beginning of a redaction concept, and it exists because somebody thought about audiences.

The format tells a similar story. CycloneDX, ratified as ECMA-424, defines the CBOM object model that most tooling emits and that federal guidance will most likely adopt. It is not silent on handling, and I had that wrong until I checked the schema. Version 1.7 added distribution constraints to BOM metadata, with a Traffic Light Protocol classification that, in the schema’s own words, controls the sharing and distribution of the data the BOM describes. The proposal behind it, issue 595, argued the case directly: a BOM can contain information its creator considers sensitive, and the creator may want it shared only with an appropriate audience. Ecma TC54 accepted it.

That amounts to one optional label, applied to the whole document, defaulting to CLEAR. It is not a sensitivity model for the content, which would establish that a cryptographic inventory is security-sensitive by construction rather than at the author’s discretion. It isn’t a redaction profile, which would specify which fields a regulator receives and which a supplier does not. And it says nothing about storage, access, query logging, or retention.

Now look at what the attestation people did with a much less sensitive artifact. RFC 9334, the Remote Attestation Procedures architecture from January 2023, describes how a device proves its own state to a remote verifier. Section 7.2 warns that this evidence may carry sensitive or personally identifiable information, may make a system identifiable, and must go only to trusted parties under a handling policy. Five named engineers decided that evidence about one device’s state deserved a confidentiality section.

CycloneDX 1.7 describes an entire enterprise’s cryptographic weakness, and its answer to the handling question is a five-value enum. I checked the schema on August 15, 2026.

None of this is a criticism of the people involved. CycloneDX added the sharing label before anyone was compelling CBOMs at scale, the SBOM minimum elements were written for a different artifact, and CERT-In got further than anyone by treating BOM sensitivity as a category problem.

What you have is fragments. Generic handling advice, a document-level label, a withheld-versus-unknown distinction, an access-control recommendation. Taken together they still fall short of a handling model for a document whose whole job is to rank weakness. A program that waits for the standards process to supply that model will still be waiting after the document is already circulating.

Controls

Four controls, in the order I would build them.

Classify at the top tier and mean it. The CBOM, the quantum risk assessment, and the prioritized migration backlog take the organization’s most restrictive standard classification. This is the cheap part, and the part most programs already do on paper without changing who can run a query.

Split aggregate from detail. Broad audiences get posture metrics, coverage percentages, and trend lines. Queryable system-level detail goes to the named roles that act on it. A steering committee does not need a query interface; it needs four numbers and a freshness curve, and giving it more than that has never once improved a decision in my experience.

Log and alert on the queries themselves. An enumeration filtering quantum-vulnerable against internet-facing against long-retention data should trigger the same review as a bulk read of the vulnerability management database, whoever runs it and whatever their job title says. This control catches the compromised service account and the departing consultant. In the programs I have reviewed, almost nobody implements it.

Decide whether the dangerous joins get stored at all. This one is an open question, and I don’t have a settled answer. Stored as materialized data, that cross-product is a pre-assembled target list that one theft hands over whole. Held in separate stores and joined on demand, under logging and an access decision, it means no single theft delivers the finished product. It costs query performance, and it only counts if the separation is a real trust boundary: one identity, one service account and one admin reaching every store means the join has only moved. My instinct is that high-consequence estates should pay the cost. I would want to see it built before I recommend it without qualification.

Protect the map from being rewritten. Every control so far assumes the threat is theft. The worse case is a poisoned inventory. An attacker who can edit the record marks a vulnerable system as migrated, downgrades its classification, drops a vendor dependency, or fakes a freshness timestamp. Nothing is stolen, nothing alerts, and you keep making decisions from a map with holes in exactly the places they chose. The systems they push out of wave one stay vulnerable for years, by the program’s own design. So the provenance of discovery, the enrichment changes and the migration-state transitions all need tamper-evident records, versioned snapshots, separation between the people who run discovery and the people who mark items done, and periodic reconciliation against raw scanner output. A stolen inventory tells an attacker which targets to pick. A poisoned one tells them which you will leave behind.

And the constraint from the recursion problem: whatever protects the repository must not depend on the cryptography the repository calls weak, which puts the repository and its access path in the first migration wave.

Why the controls have to be structural

A CBOM cannot simply be locked in a vault, because everything that makes it valuable also widens who touches it.

The framework wires the record into CI/CD, so deployments that introduce unjustified quantum-vulnerable cryptography get blocked. Into the SOC, so detection has cryptographic context. Into GRC, so compliance reporting is current. Into vendor exchange, into audit snapshots. Every one of those is correct, and every one is another copy, another credential, another export path.

That is why the controls have to be structural rather than custodial, and why the next question is about who else has a copy, past your own perimeter.

Custody

Three levels, and the second is barely discussed anywhere.

The enterprise CBOM is the case everything above addresses.

The product CBOM is a different artifact. The CBOM definition that Executive Order 14412 commissions, due by March 2027, covers the cryptographic assets used by a hardware or software element, which points at a vendor-produced product record rather than an estate-level one.

Line one up with version data and it narrows the search across every deployment of that product, including the ones whose owners have never heard of a CBOM. A product supports several algorithms and modes, so it describes what is available rather than what a given site turned on. One document, thousands of installations worth a look. Medical devices hit this first because the FDA already wants SBOMs in premarket submissions and encourages sharing them with users, which is why Deng and Rushanan were working on a cardiac device rather than a bank.

The aggregator CBOM is whatever accumulates where many clients are served at once. Discovery platforms with inventories for hundreds of clients. Consulting firms with engagement archives nobody deletes. Auditors with point-in-time extracts, and regulators with whatever gets submitted to them. The concentration is invisible to each individual client, because each sees only its own contract and its own security questionnaire, and none of them can see how many other inventories share the same tenancy. At this level a single compromise stops being an organizational incident and becomes a sectoral one.

The regulatory version of that already exists for adjacent data. Article 28(3) of DORA requires financial entities in the European Union to maintain a Register of Information covering every contractual arrangement with an ICT third-party provider. Commission Implementing Regulation (EU) 2024/2956 sets out fifteen interlinked templates in a machine-readable taxonomy. Entities file with their national competent authority, which forwards to the European Supervisory Authorities, annually by 31 March from 2026. The implementing regulation states what the aggregate is for, including the annual process by which the EBA, EIOPA and ESMA designate critical ICT third-party providers. The ESAs designated the first nineteen in November 2025.

So compelled inventories go up from national authorities to a supranational one, pooled for the specific purpose of finding sector-wide concentration. Every piece of machinery a cryptographic version would need already exists and operates today.

SEC Rule 613 is the precedent, and it is older. After the flash crash of May 2010 the Commission adopted it, requiring the exchanges and FINRA to build a Consolidated Audit Trail capturing every order, cancellation, modification and execution across US equity and options markets.

The Commission approved the plan in November 2016. The self-regulatory organizations reported full implementation in July 2024. Across those fourteen years one objection recurred, and it was never whether regulators should be able to reconstruct market activity. It was that the resulting database would be an extraordinary target, with an aggregate value far exceeding anything the individual contributors faced. Senators Katie Britt and John Kennedy asked the GAO to investigate on privacy and security grounds in October 2023. In April 2026 the SEC issued a concept release seeking public comment on the audit trail, its costs, and its alternatives.

Fourteen years to build it, and then a concept release asking whether it should have been built. That is what settling the aggregate-target question after the aggregate exists costs.

What this means for procurement

Two other channels move an inventory outside its owner’s control, and both are lawful.

Statutory protection is not a stable foundation. If you are assuming a submitted inventory is safe once it arrives, look at the Cybersecurity Information Sharing Act of 2015. It provides the FOIA exemption, antitrust relief and liability protection that most voluntary sharing with the US government relies on. Its ten-year sunset date was September 30, 2025, and it lapsed in the shutdown. A continuing resolution brought it back on November 12 through January 30, 2026. It lapsed again for a few days in the next shutdown. February’s appropriations act moved the sunset to September 30, 2026 by changing one date. So it lapses again next month unless Congress acts, and the pattern all year has been short extensions bolted to funding bills. A shield renewed nine months at a time is not a foundation for a document with a decade-long tail.

Litigation and diligence. A CBOM may be discoverable where it is relevant, non-privileged and proportionate, subject to whatever protective order applies. In an acquisition it is the kind of document a buyer asks for, and it gets read by people who won’t be employed by either party in two years. In a breach lawsuit it is the document showing what the defendant knew about its own weaknesses and when, which is simultaneously an accountability benefit and an exposure nobody has priced.

All of which turns tool selection into a custody decision. Cryptographic discovery tooling gets selected on coverage and output format, and I have published a comparison of the vendor categories on exactly those criteria. Coverage and format are necessary and no longer sufficient, because the tool that performs discovery becomes the custodian of the most sensitive record the program produces.

Where is the index stored, and can the product operate without egress? Does telemetry leave the estate, and can it be disabled without losing function? In a multi-tenant platform, what separates one client’s inventory from another’s, and has anyone outside the vendor tested the separation?

Does the vendor retain client data for benchmarking or model training, and does the contract say so or merely fail to prohibit it? Is there an assistant feature that ingests the inventory, and where does that inference execute? On termination, what gets exported, what gets deleted, and who attests to the deletion? And under whose jurisdiction does the holder operate, which is a question about legal compulsion rather than about anyone’s integrity.

That last one connects to an argument I made recently about endpoint agents and American offensive cyber policy, which I won’t rerun here. The short version is that existing third-party risk processes cannot answer it, because the disclosure it would need is unavailable by design.

The argument this is not

This argument gets misused in one specific way.

None of it is a reason to delay building a cryptographic inventory, and anyone citing me to that effect is citing me dishonestly. An organization that doesn’t know what cryptography it runs has not achieved confidentiality. It has achieved ignorance, and the asymmetry favors the attacker entirely. They learn what they need about your external surface by scanning it, while you stay blind to the internal, embedded, and operational technology cryptography that no external scan reaches. The asset discovery problem does not improve by being ignored.

The correct response to a dangerous document is custody. Build the inventory, then handle it as the operational intelligence product it has become.

The problem this leaves open

One problem the controls do not solve, and you will hit it.

You will be asked to hand the thing over. A regulator will want evidence that discovery was thorough. An insurer will want to see posture before pricing the policy. Enterprise customers will send questionnaires, and some will ask for the artifact rather than a summary. At that point every control above is beside the point, because the disclosure is legitimate and refusing it is not an option.

Deng, Yang and Rushanan hit the same wall from the healthcare side, and proposed a way through. Zero-knowledge proofs, so a manufacturer can show that no listed component has an active high or critical vulnerability without handing over the manifest. They have since built a prototype. The same idea works for cryptographic inventories, and then it meets a limit the cryptography cannot fix on its own.

That is the subject of the companion article, which works through what a disclosure architecture would need to contain, what zero-knowledge proofs can and cannot establish, and why proving your inventory is complete is a harder problem than proving what is in it.

Disclosure: Applied Quantum, the firm I run, advises organizations on cryptographic discovery and PQC migration, and sells work adjacent to several recommendations above. This article also identifies a standards gap that Applied Quantum’s own framework work is positioned to fill, and names that work in the body. Read the argument accordingly.