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

Twenty-cent exploits from a cardiac device SBOM

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 its components against public vulnerability databases and found 45 vulnerabilities. After filtering those to the high and critical findings, they selected nine for testing.

They gave each one to OpenAI’s o3 model and used the same prompt every time to ask for a vulnerable environment, an exploitation strategy and a way to tell whether the exploit worked. Then they built each environment as a container and ran the model’s 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.

The SBOM they started from was only an ingredients list of components and versions, so they still had to look up what each one was vulnerable to. A cryptographic bill of materials (CBOM) is much closer to a list of weaknesses. It contains the algorithm, key length and protocol version for each system.

Over the past two years, I have noticed the same reaction in client meetings and at conferences. When I describe a cryptographic inventory as a target list, someone in the room usually stops writing.

These are competent people running serious programs. They were given a requirement and built what was asked, and nobody told them to handle the result differently from their other documentation. I don’t think they should have had to work that out on their own, because almost none of the regulators asking for this artifact say anything about protecting it.

I make four claims:

1. Regulators are already pushing organizations toward a CBOM, from several directions at once, even though no single regulator has defined the complete artifact yet.
2. A CBOM is one of the most sensitive documents a security team produces, because attackers can use it as a ranked target list, whether they have a quantum computer or nothing but a laptop.
3. It stays useful to an attacker for years. A pentest report goes stale as teams fix the findings. A CBOM doesn’t, because the systems that are hardest to migrate stay in service longest, and those are exactly the systems recorded in it. Security teams therefore need to protect it from day one, before the first review cycle.
4. Almost no regulator says how to handle a CBOM. India’s CERT-In is the one exception I have found, and as of August 15, 2026, no standards body had published a handling model for the artifact.

Organizations should still build the inventory and protect it from the day they start building it.

Claim one, regulators already expect a cryptographic inventory

Regulators have come at cryptographic inventory from different directions, and their requirements now overlap. In the European Union, DORA, the Digital Operational Resilience Act, applies to financial entities and the Cyber Resilience Act to manufacturers. Since March 31, 2025, entities in PCI DSS scope have had to keep a documented inventory of the cryptographic cipher suites and protocols they use, under requirement 12.3.3. In India, the national computer emergency response team, CERT-In, has issued bill of materials guidelines for cryptographic and quantum BOMs as well as software ones.

For US federal agencies and their contractors, there is Executive Order 14412. Under it, NIST and CISA, the US cybersecurity agency, have until March 19, 2027 to define what a CBOM contains. In its call to action, Europol’s Quantum Safe Financial Forum asked the industry for a cryptography management framework. In its January 2026 prioritization report, Europol, with contributors from financial institutions, starts by telling institutions to inventory every business use case that depends on public key cryptography.

Organizations would need the inventory even without any of these rules, because they can’t migrate cryptography they haven’t found. Everyone who has written a serious migration methodology, me included, puts discovery first. Nobody can sequence a decade of work without knowing what is there. Migration teams work from the CBOM every day, so the organization meets the compliance requirement almost as a by-product. Whatever the regulators decide, every regulated organization will end up with this document and will have to work out how to protect it.

Claim two, a CBOM is a target list for classical and quantum attackers

In the cryptographic discovery engagements my team has run on enterprise estates, we find quantum-vulnerable cryptography every time. We also find cryptography that is already broken under today’s threat model, with no quantum computer required, such as:

• SHA-1 still used for signatures 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 recorded in the asset register as decommissioned in 2019

I treat these findings as a first-class output of discovery. In Phase 1 of the Applied Quantum PQC Migration Framework, we route classically vulnerable findings to security operations for immediate remediation, separately from the migration backlog – the two categories have different deadlines.

NIST’s National Cybersecurity Center of Excellence (NCCoE) built its discovery volume, NIST SP 1800-38B, around a multi-tool architecture that covers source code, running systems and network traffic. A thorough team therefore runs several tools, and every one of them returns findings that are exploitable today.

A CISO who treats CBOM protection as a quantum problem for the 2030s is about a decade late – the document is exploitable the day it is written.

Deng’s team started from components and versions. A CBOM contains much more: the algorithm, the key length, the protocol version, the certificate and its expiry, the library and its version, and the implementing hardware. Whoever maintains the inventory then enriches each entry with context, such as 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.

With those fields, a security team can rank its systems by exposure. A team with a mature inventory runs queries such as this one: 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.

A defender gets a migration sequence from that query. An attacker gets a target sequence with the difficulty of each target annotated, because the systems flagged as hardest to fix are the ones 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. An attacker holding a CBOM gets the ranking ready-made.

I hold other people to the gap between claim and evidence, so I’ll apply the same test to the researchers’ HealthSec workshop paper. The paper is about one device and one model. The researchers tested containerized rebuilds of the vulnerable components rather than the cardiac device itself, so we don’t know what would happen against real deployed hardware.

The researchers exploited seven of the nine CVEs they tested. They had selected those nine from a larger set of high and critical findings, so we don’t know the success rate for the device as a whole. The numbers they give for how the larger set became nine don’t add up, and the authors don’t explain the discrepancy. And the SBOM was never actually published. The researchers assumed publication in order to model the risk, so the scenario is hypothetical even though the exploits were real.

The researchers showed that the attack is feasible, though not how often it happens in the wild. Even so, three academics turned a compliance artifact into an attack plan, end to end, for the price of a coffee. Anyone holding a CBOM can do at least as much.

Claim three, a CBOM stays useful to attackers for years

Of the four claims, this is the one I most want CISOs to remember, because it contradicts what most of their teams have learned.

Security teams have handled sensitive assessment output, such as pentest reports, vulnerability scans and red team findings, for thirty years, and they have learned that these documents go stale. A pentest report is accurate for about two weeks. The team fixes the findings, and six months later most of the report is history. Most teams treat one as sensitive for about a year and then stop worrying about it, which is the right call for that kind of document.

Some parts of a CBOM go stale just as quickly. Certificates expire, endpoints come and go, and configurations drift, so teams have to refresh the inventory often. But the parts an attacker wants are the parts that don’t change. Typical examples are a component where a vendor controls the remediation, an embedded library in a device with a fifteen-year service life, an operational technology segment with no maintenance window and a system whose owner left in 2019 and was never replaced.

Migration teams flag precisely these entries as hard, and they stay on the list through several planning cycles. If a company leaks its CBOM in 2027, the part an attacker most wants will still be accurate years later.

Because a CBOM stays accurate for so long, you have to protect it from the moment you generate it. If someone runs discovery on a laptop, drops the output into a spreadsheet and mails it to four people, there is already a trail that will still be accurate when those four people work somewhere else.

For the same reason, harvest-now-decrypt-later applies to the CBOM itself. An adversary who records a CBOM in transit today, protected by classical key establishment, can read it once they have a cryptographically relevant quantum computer (CRQC). Most harvested traffic loses its value over the years of waiting, but the estate recorded in a CBOM is the one the attacker will find when the wait ends.

The attacker can also use it to decide which of their other harvested traffic to decrypt first. The certificate and signing inventory is in the same file, so the attacker can plan trust-now-forge-later attacks from it as well.

Protecting the CBOM repository

I have never once heard a security team ask what protects the CBOM repository. If the answer is your PKI, your identity provider and the TLS in front of the application, you are protecting the map with the cryptography you have recorded in it as weak.

Three years into a ten-year migration, much of the estate still runs unmigrated cryptography. Most of the CBOM repositories I have seen are internal web apps behind single sign-on, authenticating users against the very infrastructure recorded in them.

In every risk-scoring model I have built, the repository scores high on data sensitivity but low on exposure and business criticality. With weighted scoring, it ends up in the second or third migration wave, behind revenue systems. Put it in the first wave anyway, because an attacker who gets into the inventory can undermine the program that is supposed to fix everything else. I argue for a risk-driven approach elsewhere, and I now make one exception to it, for the inventory’s own repository.

Claim four, almost no regulator or standards body covers CBOM handling

Of the regulators above, only India’s CERT-In has published an enterprise handling model, one that goes well beyond a gesture. In recommendation 8.4.1.12, CERT-In 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. In best practice 8.4.2.1, it asks for a single access-controlled inventory of cryptographic assets, with access limited to authorized personnel.

In Section 5.3, CERT-In goes further for BOM data in general and specifies role-based access control, tighter restrictions on sensitive entries, a split between a public and a private BOM, and logging and auditing of access and changes. In Section 3.1, it tells organizations to keep a complete internal BOM and to give consumers a customized version, tailored to their security requirements, from which sensitive data has been removed.

In its July 2025 guidelines, CERT-In went further than any other body, with a two-tier disclosure model, an access model and an audit requirement. Anyone building a handling model should read Section 5.3 before inventing their own.

However, CERT-In did not build its model specifically for CBOMs. It repeats the same provisions almost word for word for SBOMs, CBOMs, AIBOMs and HBOMs, so it wrote them for bills of materials as a category. Handling a ranked map of weaknesses like a CBOM requires several provisions that the guidelines lack:

• rules on which fields are dangerous in combination
• redaction profiles that differ by audience
• an account of why a CBOM stays useful longer than a vulnerability scan
• monitoring of the queries people run, on top of control over who has access
• any provision for the aggregator holding four hundred clients’ inventories in one tenancy

The other regulators say even less. Executive Order 14412, for example, does not require anyone to produce a CBOM. Instead, it requires agencies to review their inventories of high-value assets and their heads to name a migration lead for cryptographic inventory. The FAR Council, the body that writes federal procurement regulations, has to propose new requirements for contractors. CISA and NIST have to define what a CBOM contains and make it suitable for automated assessment.

I have read the order four times looking for anything on how the resulting document should be classified, handled, shared or protected, and found nothing.

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 and seventeen partners, including France’s ANSSI, Germany’s BSI, CERT-In, Italy’s ACN and the Dutch NCSC – with the European Commission’s DG CONNECT contributing to the drafting. Its authors produced a careful document and incorporated more than ninety public comments.

They put data management and storage practices out of scope. They also removed Access Control as a stand-alone element and folded it into Distribution and Delivery, reasoning that practice has moved on since 2021. For an ingredients list, that is defensible.

The 2026 document also contains the beginnings of a redaction concept, in an element few people will read closely. Under its Explicitly Identifying Unknown Information element, authors have to distinguish data that is actually unknown from data they are deliberately withholding. Recipients should also have a way to ask about redacted security-related content. That element exists because somebody on the drafting team thought about audiences.

Most tools emit CBOMs in CycloneDX, the format Ecma International ratified as ECMA-424. I expect CISA and NIST to build on its CBOM object model in their March 2027 guidance.

I had assumed the CycloneDX maintainers ignored handling, until I looked at the schema. In version 1.7, they added distribution constraints to BOM metadata, including a Traffic Light Protocol classification that, in the schema’s own words, controls the sharing and distribution of the data that the BOM describes. In the proposal, filed as issue 595, its authors argued that a BOM can contain information its creator considers sensitive and may want shared only with an appropriate audience. Ecma’s TC54 committee accepted it.

The classification is one optional label for the whole document, and its default value is CLEAR. Under a real sensitivity model, a cryptographic inventory would be security-sensitive by definition rather than at the author’s discretion. With a redaction profile, the author would know which fields a regulator receives and which a supplier does not. CycloneDX has neither, and its schema includes nothing on storage, access, query logging or retention.

The engineers behind the Internet Engineering Task Force’s remote attestation work took far more care with a much less sensitive artifact. In RFC 9334, the Remote Attestation Procedures architecture from January 2023, they specified how a device proves its own state to a remote verifier. In Section 7.2, they warn that this evidence may contain sensitive or personally identifiable information, could be used to identify a system 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. In CycloneDX 1.7, an organization can record the cryptographic weaknesses of its entire estate, yet the only handling field is a five-value enum. I checked the schema on August 15, 2026.

I don’t blame the people involved. The CycloneDX maintainers added the sharing label before any regulator was compelling CBOMs at scale. The authors of the SBOM minimum elements were writing for a different artifact. CERT-In treated BOM sensitivity as a problem for all bills of materials.

What exists today is a set of fragments: generic handling advice, a document-level label, a distinction between withheld and unknown data, and an access-control recommendation. Even if a security team combines them, it still has no handling model for a document built to rank weaknesses. Anyone who waits for the standards bodies to supply that model will still be waiting when their CBOM is already circulating.

Five controls for protecting a CBOM

I would build five controls, in this order.

Classify at the top tier and mean it. Give the CBOM, the quantum risk assessment and the prioritized migration backlog the organization’s most restrictive standard classification. Most security teams have already taken this cheap step on paper without changing who can actually run a query.

Split aggregate from detail. Broad audiences get posture metrics, coverage percentages and trend lines. Only the named roles that act on system-level detail get to query it. A steering committee needs four numbers and a freshness curve. I have never seen one make a better decision after it got a query interface.

Log and alert on the queries themselves. If someone runs a query that filters for quantum-vulnerable, internet-facing systems holding long-retention data, the security team should treat it like a bulk read of the vulnerability management database and review it, whoever ran it and whatever their job title. With this control, a security team can catch a compromised service account or a departing consultant. In the programs I have reviewed, almost nobody has implemented it.

Decide whether to store the dangerous joins at all. This one is an open question, and I don’t have a settled answer. If a team stores the joined result as materialized data, an attacker who steals it once gets a pre-assembled target list. If the team keeps the data in separate stores and joins it only on demand, with logging and an access decision each time, an attacker would have to break into several stores to get the finished product.

That design costs query performance, and the team gains something only if the separation is a real trust boundary. If one identity, one service account or one administrator can reach every store, the team has only moved the join. My instinct is that operators of high-consequence estates should pay the cost, but I would want to see it built before I recommend it without qualification.

Protect the map from being rewritten. The first four controls are designed against theft, but the worst 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 and no alert fires, yet the organization keeps making decisions from a map with holes in exactly the places the attacker chose.

The systems the attacker pushes out of the first wave stay vulnerable for years, and the migration team itself schedules them that way. To prevent this, a team needs tamper-evident records of discovery provenance, enrichment changes and migration-state transitions, along with versioned snapshots. It also needs separation between the people who run discovery and the people who mark items done, and periodic reconciliation against raw scanner output.

One constraint from the repository discussion applies to all five: don’t protect the CBOM repository with cryptography you have recorded as weak. In practice, that means moving the repository and its access path into the first migration wave.

Why a CBOM can’t simply be locked away

An organization gets value from a CBOM only by connecting it to other systems. Each time it connects one, more people and services can reach the data.

In our framework, we connect the record to CI/CD, so the pipeline can block deployments that introduce unjustified quantum-vulnerable cryptography. We also connect it to the SOC, so analysts have cryptographic context for detection, and to GRC, so compliance reporting stays current. We use it for vendor exchange and audit snapshots as well. Each of these connections is correct, but each one means one more copy, credential and export path.

So the controls have to be built into how the CBOM is stored and connected, since no custodian can watch every copy. Some copies also end up with parties outside the organization’s perimeter, such as vendors, auditors and regulators.

Custody at the enterprise, product and aggregator level

Each of the three levels has its own custody problem.

The enterprise CBOM is the one I have discussed so far.

The product CBOM is a different artifact. Under Executive Order 14412, the CBOM definition due by March 2027 covers the cryptographic assets used by a hardware or software element. I read that wording as describing a record of a vendor’s product.

An attacker who combines a product CBOM with version data can narrow the search across every deployment of that product, including deployments run by owners who have never heard of a CBOM. A product supports several algorithms and modes, so the vendor can only record what is available and has no way of knowing what each site turned on. Even so, from a single document an attacker can find thousands of installations worth a look.

Manufacturers of cyber devices – the FDA’s term for connected medical devices – face this first. The FDA already expects SBOM information in their premarket submissions and encourages them to make it available to users. Deng and Rushanan studied a cardiac device for that reason.

The aggregator CBOM exists wherever one party holds many organizations’ inventories 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 firms submit to them.

No individual client can see this concentration. Each one sees only its own contract and its own security questionnaire, and none of them knows how many other inventories are stored in the same tenancy. At this level, a single compromise becomes a sectoral incident instead of an organizational one.

European regulators already pool comparable data under DORA, where Article 28(3) requires financial entities to maintain a Register of Information covering every contractual arrangement with an ICT third-party provider. In Commission Implementing Regulation (EU) 2024/2956, the European Commission sets out fifteen interlinked templates in a machine-readable taxonomy.

Each entity files with its national competent authority. Every year by 31 March, starting in 2026, the national authorities pass the registers on to the European Supervisory Authorities (ESAs). According to the regulation, one purpose of the pooled registers is the annual process in which the three ESAs – the EBA, EIOPA and ESMA – designate critical ICT third-party providers. They designated the first nineteen in November 2025.

So EU supervisors already collect compelled inventories from national authorities and pool them specifically to find sector-wide concentration. Everything a cryptographic version would need is already in place and in use.

There is an older precedent in US securities markets. After the flash crash of May 2010, the Securities and Exchange Commission (SEC) adopted Rule 613 and required the exchanges and FINRA, the industry’s self-regulatory organization, to build a Consolidated Audit Trail of every order, cancellation, modification and execution in US equity and options markets.

The Commission approved the plan in November 2016, and the self-regulatory organizations reported full implementation in July 2024. In the fourteen years between the rule’s adoption in 2012 and the SEC’s concept release, critics kept raising the same objection. They accepted the oversight goal but warned that the resulting database would be an extraordinary target, with an aggregate value far beyond anything the individual contributors faced.

In October 2023, Senators Katie Britt and John Kennedy asked the GAO, the US Government Accountability Office, to investigate on privacy and security grounds. In April 2026, the SEC published a concept release seeking public comment on the audit trail, its costs and its alternatives. After fourteen years of building the audit trail, the SEC is now asking whether it should have been built at all. Regulators collecting CBOMs can still settle the aggregate-target question before such a database exists.

What custody means for procurement

Organizations can also lose control of an inventory through two other channels, both of them lawful.

Statutory protection can lapse. Anyone who assumes a submitted inventory is safe once it arrives should look at the Cybersecurity Information Sharing Act of 2015. Most organizations that share information voluntarily with the US government rely on the act’s exemption from the Freedom of Information Act (FOIA), its antitrust relief and its liability protection. Those protections apply only to qualifying cyber threat indicators and defensive measures, so an organization cannot count on them for every security-sensitive document it submits.

The act’s ten-year sunset date was September 30, 2025, and it lapsed during the government shutdown. Congress revived it on November 12 with a continuing resolution that ran through January 30, 2026, and it lapsed again for a few days in the next shutdown. In February, Congress moved the sunset to September 30, 2026 by changing one date in an appropriations act. All year, Congress has done no more than bolt short extensions onto funding bills. A legal protection that Congress has had to revive twice is not something to rely on for a document that stays sensitive for a decade.

Litigation and diligence. A CBOM may be discoverable in litigation where it is relevant, non-privileged and proportionate, subject to whatever protective order applies. A buyer in an acquisition will usually ask for it, and people who may not work for either party two years later will read it. In a breach lawsuit, the plaintiffs can use it to show what the defendant knew about its own weaknesses and when. For the defendant, the CBOM is both an accountability benefit and an exposure nobody has priced.

Choosing a discovery tool is also a custody decision. Organizations usually choose cryptographic discovery tools on coverage and output format, and I have published a comparison of the vendor categories on exactly those criteria. Coverage and format are still necessary but no longer sufficient. Whichever vendor runs discovery becomes the custodian of the most sensitive record the organization has. Before choosing a vendor, I would ask:

• Where is the index stored, and can the product operate without egress?
• Does the product send telemetry out of the estate, and can the customer disable it without losing function?
• In a multi-tenant platform, how does the vendor keep one client’s inventory apart from another’s, and has anyone outside the vendor tested that isolation?
• Does the vendor retain client data for benchmarking or model training, and has it committed to the answer in the contract or simply not ruled it out?
• Is there an assistant feature that ingests the inventory, and where does the vendor host that inference?
• When the contract ends, what does the vendor export and delete, and who attests that the data is gone?
• Which jurisdiction does the vendor operate under, and which governments could legally compel it to hand over data? I am asking about legal compulsion here, not about anyone’s integrity.

I made a related argument recently about endpoint agents and American offensive cyber policy, and the same reasoning applies here. A third-party risk team cannot answer the jurisdiction question with its existing processes. The disclosures it would need are unavailable by design.

Build the inventory anyway

An organization that doesn’t know what cryptography it runs gains no confidentiality from that ignorance. Attackers learn what they need about its external surface by scanning it, while the organization stays blind to the internal, embedded and operational technology cryptography that no external scan reaches. Organizations that ignore the asset discovery problem still have it.

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

The open problem of legitimate disclosure

Every organization with a CBOM will eventually be asked to hand it over. A regulator will want evidence that discovery was thorough. An insurer will want to see the organization’s posture before pricing the policy. Enterprise customers will send questionnaires, some of them asking for the artifact itself instead of a summary. At that point, the organization cannot rely on any of the controls above, because the disclosure is legitimate and refusing it is not an option.

Deng, Yang and Rushanan ran into the same problem from the healthcare side and proposed a solution based on zero-knowledge proofs. With their scheme, a manufacturer can present a trusted third party’s signed assessment that no listed component has an active high or critical vulnerability, without handing over the manifest. They presented a working prototype in the same conference week. Organizations can apply the same idea to a CBOM, but they will reach a limit they can’t get past with cryptography alone.

In the companion article, I look at what a disclosure architecture would need to contain and what a prover can and cannot establish with zero-knowledge proofs. I also explain why proving that an inventory is complete is harder than proving what is in it.

From the author