Proving Your Crypto Inventory Is Complete Without Handing Over the Map
A zero-knowledge prototype and the CBOM disclosure problem
In December 2025, at a healthcare security workshop in Honolulu, three researchers showed that a compliance document could be turned into working exploit demonstrations for about twenty cents of model compute per tested vulnerability. The same week, they offered a way to answer the questions the document exists for without handing the document over.
Jiarou Deng, Yang Yang and Michael Rushanan presented both at the 2025 Annual Computer Security Applications Conference (ACSAC). They took the attack paper to the HealthSec workshop on December 9 and a zero-knowledge framework for validating software bills of materials (SBOMs) to the poster session. The framework is a working prototype, built on a sorted Merkle tree over component hashes. With a construction they call TreeGap, the authors use neighboring hashes to prove that a component is inside or outside a designated subset. They generate the proofs with Groth16 and use batching and Merkle forests to handle larger inventories.
In the poster, the authors describe a three-party workflow under regulatory oversight, with a customer or patient as a fourth verifying role. A manufacturer commits to the inventory and publishes proofs, a trusted third party analyzes vulnerabilities and issues signed assessment reports, and a regulator validates them.
With the prototype, an organization can prove narrow but useful claims. For example, a manufacturer can show that its inventory contains no components with known vulnerabilities as of a given date, or that it does not include the component affected by a particular CVE. Richer statements are possible over a suitably committed inventory, but what the authors demonstrate with this prototype is proof that a specific component is in a designated list or absent from it. The authors call the first a membership proof and the second a non-membership proof.
A cryptographic bill of materials (CBOM) is an inventory of the algorithms, keys and certificates an organization runs and of where each one is used. I believe it is one of the most sensitive documents a security team can produce. Regulators have started asking for these documents, yet they have said almost nothing about how to protect them. Once the March 2027 guidance discussed below is published, these requests will become routine.
I covered that gap in a companion piece and stopped where most CISOs are stuck today: the requests are already arriving. Insurers are starting to price quantum readiness and want to see the document behind the answers. Enterprise customers now use supply-chain questionnaires to ask for evidence, not assurances.
Sending the document as-is is the problem. A CBOM is a map of exactly which systems still run breakable cryptography and where they are. In Honolulu, the researchers started from a thinner document, an SBOM with only components and versions, and still produced working exploit demonstrations for pocket change. With a CBOM, the job would have been easier still. Every copy an organization sends out can leak. As I showed in the companion piece, once everyone’s copies are collected in one place, that collection becomes the incident.
Say you have classified the inventory, split aggregate from detail and put query logging on the joins, as I recommended in the companion piece. The legitimate requests will still arrive, and once you hand a copy over on purpose, you can no longer rely on any of those controls. Unlike harvest-now-decrypt-later, where an adversary has to wait for a quantum computer before reading anything, this problem is due next quarter.
With Deng’s framework, an organization can prove to a supervisor what its inventory contains. What supervisors care about most, though, is evidence that the inventory covers the whole estate, and nobody can prove that with a proof system. The researchers building these systems say as much in their own papers. Most of the gap can still be closed today with signed commitments and attested discovery runs, neither of which requires new cryptography.
Content claims and coverage claims
The first thing a regulator or an insurer wants from an inventory is a set of content claims. These are statements about the record itself, the kind you would want to demonstrate to an outsider. Each content claim is a predicate, a yes-or-no question about the inventory written precisely enough for a machine to answer it. With a proof of a predicate, someone can check the answer without ever seeing the inventory.
For example, you might want to show that no entry has RSA-2048, an internet-facing endpoint and restricted data at the same time. A system with all three is weak, reachable and worth an attacker’s effort, so an inventory full of such systems is a target list. You might also want to show that ninety-four percent of Tier 1 entries have a migration owner and a target date, or that every certificate in the payment path chains to an approved root.
Zero-knowledge proofs are well suited to content claims. The organization first commits to the inventory, which means it publishes a cryptographic fingerprint of the inventory and keeps the document itself. The organization then uses a zero-knowledge proof to convince a verifier that a statement about the fingerprinted document is true without revealing anything else. The verifier gets the answer but never sees the inventory. Deng’s team uses TreeGap in exactly this way to show that a component is in a designated list or absent from it.
Of course, the verifier still learns something about the inventory from each answer, and from the sequence of questions it is allowed to ask.
The second thing a regulator or an insurer wants is a coverage claim. This is a statement about the world: that nothing in the estate is missing from the record. When supervisors ask for a comprehensive inventory, this is what they mean. Without it, nobody reading the content proofs can tell whether they are about the whole estate or only part of it. And nobody can produce a coverage claim with a zero-knowledge proof.
No matter how efficient the circuit, a verifier checking a zero-knowledge proof learns only that a statement is consistent with the committed document, meaning the inventory that was fingerprinted. The prover decides which inventory to commit, and at no point does anyone compare it with what the organization actually runs.
So an organization that commits to the clean forty percent of its estate, cherry-picked, gets proofs that all check out. A verifier reading them learns about forty percent of the estate but believes it has learned about all of it.
What four SBOM research teams say about completeness
Any reviewer could raise this objection, and the researchers building these systems have done so themselves, in the limitations sections of their own papers. Read four of those sections side by side and you find a different piece of the same limitation in each.
The group at KTH Royal Institute of Technology in Stockholm that built zkSBOM states the problem plainly in its limitations section. The authors do not address SBOM accuracy, and they assume that the supplier generates the inventory honestly. As a result, an artifact can be proven safe while a vulnerable dependency is simply missing from the record. As remedies, the authors suggest attestation-based approaches or verifiable execution in a zero-knowledge virtual machine (zkVM). I think that is the right instinct, though both remain future work.
Petra is a redaction and selective-disclosure system from Eman Abu Ishgair, Chinenye Okafor and Santiago Torres-Arias at Purdue University and Marcela Melara at Intel, accepted at USENIX Security 2026. Its authors use ciphertext-policy attribute-based encryption to control who can read each part of an SBOM. They go further than the KTH group and rule the problem out by name. In the paper’s own words, detecting maliciously crafted SBOMs that conceal malicious components is out of scope. With encryption, a supplier can keep parts of an SBOM confidential, but it cannot use encryption to show that every component is listed.
In VeriSBOM, Castiglione, Ebrahimi and Khakpour add an auditor who validates compliance metadata and records it in a second Merkle structure alongside the package tree. The authors simply assume that the supplier’s SBOM is correct and complete, and they concede that the design depends on trusting the auditor. They do not discuss staleness in their limitations section; the KTH team raises that criticism in its related-work section.
Deng’s team lists four open challenges of its own:
- Data normalization across inconsistent naming and version formats
- Scalability of proof generation
- Snapshot freshness and reissuance as new vulnerabilities are disclosed
- Governance of the roles among manufacturers, trusted third parties and regulators
Completeness is not on the list. Two of the four research teams do introduce a trusted institution. VeriSBOM’s auditor validates policy metadata over the SBOM it receives, and in Deng’s framework the trusted third party analyzes vulnerabilities in whatever inventory it is given. Neither one is asked to look at the product itself and check that the inventory covers all of it.
So in all four systems, completeness is left out of both the human roles and the proofs. Reading the four limitations sections together, I’d say the researchers have tacitly agreed to leave it that way.
The proof-of-solvency precedent
Cryptocurrency exchanges ran into the same completeness problem years ago, with customer money at stake. With a proof of solvency, an exchange demonstrates that its reserves are enough to settle every customer account.
In 2015, Gaby Dagher, Benedikt Bünz, Joseph Bonneau, Jeremy Clark and Dan Boneh made these proofs privacy-preserving with Provisions, published at the ACM CCS conference. With Provisions, an exchange proves that its assets exceed its liabilities without revealing its addresses, its totals or any customer balance. The authors implemented it and showed it was practical for an exchange with millions of customers.
Then, in 2019, Kexin Hu, Zhenfeng Zhang and Kaiwen Guo published Breaking the Binding in Computers & Security. They showed that the Maxwell protocol and the summation Merkle tree underlying this family of schemes are not secure against the exchange itself. An exchange can produce a valid proof over only a subset of its liabilities, and an omitted customer finds out only by running the inclusion check themselves. In their analysis, the lower bound on successfully verified liabilities is the largest single account balance in the exchange’s dataset.
Konstantinos Chalkias, Panagiotis Chatzigiannis and Yan Ji later cataloged further failures in Broken Proofs of Solvency, a paper from a workshop at the 2022 Financial Cryptography conference that appeared in the 2023 proceedings. Each of these proofs was valid for the accounts the exchange included, so anyone who read it as covering every customer was wrong. The cryptography was sound, but the omission happened earlier, when the exchange chose which accounts went into the committed set. A verifier checking a proof about that set learns nothing about the accounts left out.
A cryptographic inventory has exactly the same structure. If anything, omissions are harder to catch, because nobody audits a CBOM the way an exchange’s customers audit their own balances. So when a vendor offers zero-knowledge proofs over a CBOM, ask what the proof is over and who decided what went into it.
Why the CBOM case is harder than the SBOM case
When the KTH team measured how much a verifier learns from SBOM proofs, they found an asymmetry. From a non-inclusion proof, a verifier learns fewer than two additional components on average. From an inclusion proof, by contrast, it learns between seventeen and a hundred and twenty, depending on the package registry. The team counted leaked components and did not measure the cost of generating the proofs.
I expect the leakage from a cryptographic inventory to be worse, because the possible values are few and correlated. Package registries contain hundreds of thousands of components, while the key establishment algorithms in production use across an enterprise number in the dozens.
So a verifier who learns that no system uses RSA-2048 on an internet-facing endpoint can rule out far more possibilities than one who learns that no application depends on a particular npm package. A verifier who asks enough questions like that can reconstruct a good part of the inventory from the answers alone. As of August 15, 2026, I have found no published measurement of leakage from cryptographic-inventory predicates, and somebody should run that study.
The predicates supervisors care about in cryptography are also joins. With an SBOM proof, a verifier gets an answer about one dimension, namely whether a component is present. A supervisor asking about cryptography wants to know about exposure, data sensitivity, retention horizon and remediation ownership at the same time. With every condition you add, the verifier learns something about one more dimension of the inventory.
Discovery tools also produce inconsistent results, and for SBOMs we know by how much. In a large-scale empirical study published in ACM Transactions on Software Engineering and Methodology in January 2026, researchers analyzed 55,444 SBOMs that six tools generated across 3,287 repositories. Depending on the language, inter-tool consistency for package detection was between 7.84 and 12.77 percent, with license accuracy below twenty percent. And those tools were only reading package manifests, which is a comparatively easy problem with a written ground truth.
Cryptographic discovery tools have a much harder job. They have to read binaries, network captures, configuration files and hardware. NIST’s National Cybersecurity Center of Excellence (NCCoE) built SP 1800-38B around a multi-tool architecture for source code, running systems and network traffic. In that preliminary draft, NCCoE demonstrates the architecture without measuring how closely the tools’ results match, and I have not found an equivalent figure for cryptographic discovery anywhere else. Until someone measures it, a verifier checking a proof over one tool’s output learns only what that one tool found.
Three layers for narrowing the coverage gap
The first two layers below are unglamorous, but organizations can deploy them today and solve most of the problem with them. Most researchers focus on the third.
Layer one, commitment
Sign and timestamp a Merkle root of each inventory snapshot and record it in a transparency log. For almost no cost, the organization gets a tamper-evident inventory, so nobody can quietly improve it after an incident. A claim made in 2027 can still be checked in 2032 against what the organization actually held. The 2026 SBOM minimum elements already include an author signature element, so this layer is an increment rather than an invention.
In June 2026, the IETF published the transparency-log part as RFC 9943, the Supply Chain Integrity, Transparency and Trust (SCITT) architecture. In it, the IETF specifies an append-only transparency service, COSE-signed statements and receipts, and lists compliance with auditing procedures and regulatory requirements among its goals.
Insurers should want this layer more than either of the other two, because their exposure is the claims-time dispute about what the insured knew and when.
Layer two, provenance of discovery
To address comprehensiveness, we change what the organization attests: instead of the findings, it attests how its scanners found them. This means recording which scanners ran at which versions, against which address ranges, repositories and cloud accounts, over what time window. It also means recording whether the scans were authenticated and what failed.
A regulator can then verify that the scanners covered ninety-six percent of the asset register and that the organization reconciled that register against network observation, without ever seeing a finding. Coverage becomes a claim about how the discovery was run, which is something an organization can attest to, unlike the ground truth of its estate.
The maintainers of the in-toto framework for software supply-chain attestations have already defined typed predicates for build provenance, SBOMs, vulnerability scans and verification summaries, and their envelope format could be reused for coverage. As of August 15, 2026, however, the vetted in-toto predicate directory had no type for discovery or scanning coverage, that is, for what population was targeted, which methods were used, what was reached and what failed.
Layer three, predicate disclosure
In the near term, predicate disclosure means selective opening under sampling, where the assessor draws a random sample using a public randomness beacon so the organization can’t prepare for it. The organization then opens those entries with inclusion proofs against the committed root. This approach is statistically strong and cryptographically simple, and organizations can use it today without any new research.
In the longer term, predicate disclosure means zero-knowledge proofs of aggregate predicates, which is what all four research teams above are working toward. How much those proofs will cost depends on the circuit, the commitment structure and the normalization rules, and nobody has yet published enough results to show a general trend. So if someone promises you cheap aggregate proofs over a whole estate, ask to see the benchmark.
Designing a coverage predicate
At Applied Quantum, we are building this layer-two piece as part of our Cryptographic Concentration Framework, and we will publish it at CCFramework.org with a resolvable predicate type URI. The work is still in progress and hasn’t had any outside review yet, but three of the design decisions are settled. I believe anyone building a similar predicate would make the same three choices.
First, coverage is asserted against a named reference set, identified by its cryptographic digest. Nobody can observe an estate directly, so a claim to have covered all of it can’t be falsified. A claim to have covered this configuration-management database (CMDB) export, these cloud accounts and this repository manifest, each pinned by its hash, can be checked by anyone who holds the same reference.
ETSI’s TC CYBER quantum-safe cryptography group, for example, agreed a work item at its QSC#31 meeting to build a protocol inventory cataloging the quantum-safe status of each identified protocol, but stopped it at QSC#38 in September 2025. A public catalog like that is exactly what a coverage claim could be measured against. I read the decision to stop as a warning about how hard such catalogs are to keep up.
Second, the gap register, a record of which targets the scanners tried and failed to reach, is mandatory. Without it, an organization overstates its coverage. Yet under voluntary disclosure, the gap register is the first field organizations leave out.
If the scanners couldn’t authenticate to the mainframe, couldn’t reach the operational-technology (OT) segment and timed out on two cloud accounts, the organization still has a legitimate result, just one with three named holes. Leaving those holes out of the attestation is worse than attesting nothing at all, because the regulator then reads a partial scan as a clean one.
Third, the organization puts scanner provenance and findings into two separate artifacts for two different audiences. The organization sends the coverage attestation, which contains no findings at all, to the regulator, the insurer and the customer. The organization keeps the inventory itself under the controls I described in the companion article. By separating the two, it can manage the disclosure problem without any zero-knowledge circuit.
Nobody can use a coverage predicate to show that the reference set itself is right. I expect vendors selling this idea to leave that part out. If a CMDB is missing a quarter of the estate, a perfect attestation against it is only good for three quarters of the estate. Yet the figure on the certificate will still be ninety-six percent.
My own practitioner estimate in Quantum Ready is that asset registers contain substantial errors, worst in operational technology and decentralized estates. That’s why I put observed-versus-recorded reconciliation into Phase 1 of the PQC Migration Framework instead of leaving it for later. With the predicate, an organization turns the denominator from an unstated assumption into a named, versioned and checkable object. An organization and its supervisor can then argue about a specific artifact instead of about confidence.
Measuring concentration across a sector
Supervisors also need to know how many institutions depend on the same hardware security module (HSM) firmware, the same TLS implementation or the same certificate authority. This is a concentration question about the whole sector, and answering it today would require every institution to hand its inventory to a central authority. Supervisors would then be rebuilding the aggregation problem from the companion article, only at sector scale.
Secure multi-party computation was built for exactly this kind of question. With it, several parties can compute a joint result without revealing their inputs to each other.
In 2012, Emmanuel Abbe, Amir Khandani and Andrew Lo showed in the American Economic Review how to compute concentration indexes across institutions without a trusted third party. A year later, Mark Flood, Jonathan Katz, Stephen Ong and Adam Smith made the case for secure computation in financial supervision in a US Office of Financial Research working paper. They even include a section on the limits of secure computation.
The technique has been used on real data for years. In January 2008, the organizers of a Danish sugar-beet auction used it to clear 25,000 tons of production rights across 1,200 bidders in about thirty minutes. In a paper at USENIX Security in 2010, the researchers behind SEPIA used it to aggregate network security statistics from up to 140 input providers across multiple domains. The Boston Women’s Workforce Council has been running recurring wage-gap computations across roughly a hundred employers and 165,000 employees for a decade, without any of those companies disclosing its payroll.
In financial supervision, however, nobody has taken it past the pilot stage. The Bank for International Settlements (BIS) Innovation Hub’s Project Aurora is a proof of concept on synthetic data. Participants in the UK Financial Conduct Authority’s 2019 TechSprint produced no market-ready solution. Transaction Monitoring Netherlands, a shared utility set up by Dutch banks, ran on pooled data and kept the privacy-preserving computation on a separate research track, and it wound down before either became supervisory infrastructure. The Monetary Authority of Singapore runs its COSMIC platform in production. It is a secure sharing system, though, and the MAS has not said publicly that multi-party computation is part of it.
Thirteen years after that 2013 working paper, the technology is deployable. Yet as of August 15, 2026, I have found no documented production deployment in which a financial supervisor uses secure computation for cross-institution statistics.
What I would ask for in the March 2027 CBOM guidance
Under Executive Order 14412, the US Cybersecurity and Infrastructure Security Agency (CISA) and NIST have until March 19, 2027 to publish minimum elements for a cryptographic bill of materials. In the companion article I argue that those elements should include a handling model. The other half of my ask is a disclosure profile with four parts:
- Commitment, so that inventories are tamper-evident and claims can be checked later.
- Provenance attestation of how discovery was performed, so that coverage can be demonstrated without disclosing the inventory.
- Predicate disclosure, so that a recipient can verify a property without receiving the document.
- Defined redaction tiers, so that a regulator, an insurer, a customer and the public each receive a different artifact rather than a copy of the same one.
India already has a precedent for the last of these. In July 2025, CERT-In, India’s national computer emergency response team, told organizations in its guidelines to keep a complete internal bill of materials and to give consumers a customized version. Organizations are to tailor that version to the consumer’s security requirements without exposing sensitive data. In other words, CERT-In wrote two-tier disclosure into a national guideline almost a year before Executive Order 14412.
The limits of the three layers
An organization that wants to hide a system can still do so with all three layers in place. It simply leaves the system out of the reference set, and the attestation will then be truthful about a denominator chosen to flatter.
Once the inventory is committed, that choice is on record and can be checked later. With a provenance attestation, the denominator is explicit, and an assessor who samples entries can test ones the organization did not pick. With all three in place, a supervisor can detect dishonesty after the fact. An honest organization can also disclose without exposing its inventory. A good auditor does the same three things: fixes the denominator, preserves the evidence as it stood and tests what the audited party did not choose in advance.
The alternative is the status quo, where supervisors keep asking for the document and organizations keep sending it until the copies pile up somewhere and become the incident.
In 2012, the US Securities and Exchange Commission adopted Rule 613, which led to the Consolidated Audit Trail, a central database of US stock and options orders. Fourteen years later, the Commission published a concept release to ask whether the design had been right. For cryptographic inventories, that design question is still open. Building the disclosure model in now will cost less than retrofitting it later.
