A September 1 BankInfoSecurity interview on CBOM automation highlights a practical risk: organizations can automate cryptographic discovery and still miss legacy systems, operational technology, custom implementations, and other assets outside a tool’s reach. The resulting document may look authoritative while providing a false sense of completeness.
The article is secondary reporting rather than a new standard, but its warning is operationally important. Automation is essential at enterprise scale. The mistake is treating one method’s output as proof that every relevant cryptographic dependency has been observed.
Every discovery method has a boundary
Source-code analysis can identify direct library calls but miss runtime services, generated code, opaque binaries, or infrastructure termination points. Package analysis can identify components that provide cryptography without proving which algorithms are configured or used. Network observation can see negotiated protocols but not offline signing, data-at-rest encryption, or dormant paths. Certificate collection can reveal public keys and signatures without showing private-key custody or application dependencies.
Cloud APIs, configuration systems, architecture documents, supplier attestations, and interviews each add another view. None is universally complete. A mature CBOM program uses several signals and records where each signal can and cannot see.
This makes provenance part of the inventory. Each observation should carry its method, source, timestamp, scope, confidence, and evidence location. Reviewers can then distinguish a verified runtime fact from an inferred dependency or an unassessed area.
“Not detected” is not “not present”
Negative findings are especially dangerous. If a scan does not detect RSA in a system, that may mean RSA is absent. It may also mean the relevant component was offline, excluded, encrypted, embedded in firmware, invoked only under a rare workflow, or owned by a supplier.
Inventory systems should preserve those possibilities. Coverage should be expressed by asset population, environment, discovery method, and time window. Unknowns need owners and follow-up actions rather than being silently converted into clean status.
For post-quantum migration, the distinction affects planning. A roadmap built on incomplete coverage underestimates cost and sequencing. Hidden authentication, signing, hardware, and supplier dependencies often appear late—when change windows are smaller and design choices are already committed.
A CBOM is an evidence product, not a completion certificate
A structured CBOM helps move information between engineering, security, procurement, auditors, customers, and tools. Its value depends on what the fields mean and how the data was obtained. A valid file can accurately represent an incomplete observation set.
Organizations should attach a coverage statement to each CBOM: systems included, methods used, exclusions, freshness, unresolved conflicts, and confidence. They should distinguish supplier-provided data from independently observed evidence and retain both when they disagree.
Completeness should also be evaluated against a defined population. “We scanned 95 percent of registered servers” is measurable. “We found all cryptography” is usually not. The remaining five percent, unmanaged assets, embedded systems, SaaS dependencies, and unregistered workloads still need treatment.
Reconciliation creates the canonical inventory
Multiple discovery methods will produce duplicates and conflicts. One certificate may appear from an endpoint scan, a cloud API, and a certificate manager. A library version may be reported differently by a package manifest and a running process. Reconciliation should preserve the observations while connecting them to one canonical asset.
The canonical record contains identity, relationships, ownership, business context, policy evaluation, lifecycle state, and evidence history. It is not merely the latest scanner result. This separation allows tools to be added or replaced without losing governance continuity.
What organizations should do next
- Define the population. Identify business services, environments, devices, software, certificates, suppliers, and data stores expected in scope.
- Use complementary methods. Combine source, package, configuration, endpoint, network, cloud, documentation, and supplier evidence as appropriate.
- Record provenance. Preserve method, scope, timestamp, confidence, and raw evidence for material observations.
- Measure coverage. Report assessed, excluded, inaccessible, stale, and unknown populations rather than a single completeness claim.
- Reconcile continuously. Convert observations into canonical assets, resolve conflicts, assign gaps, and refresh evidence.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
Vista helps teams bring multiple cryptographic signals into governed inventory, evaluate exposure, assign work, and preserve evidence. CBOM generation supports exchange, while canonical records preserve operational context. Vista is not a vulnerability scanner. Selected-asset Active Scan is not indiscriminate network scanning, and discovery gaps are not proof of absence. It tracks and governs PQC migration but does not generate PQC keys or perform every migration step. Learn more on Vista’s post-quantum page.
Where uncertainty remains
No discovery program can guarantee universal visibility across arbitrary systems and suppliers. The appropriate methods and coverage thresholds depend on architecture, risk, access, and purpose. The defensible goal is not an unsupported claim of completeness; it is transparent coverage, traceable evidence, managed gaps, and repeated improvement.
Sources
- The Challenges of Cryptographic Bill of Materials Automation, BankInfoSecurity, September 1, 2026.
- Cryptography Bill of Materials capability, OWASP CycloneDX, current reference.