Enterprise Cryptographic Asset Discovery with CBOM

The Cryptographic Visibility Problem

Most enterprises cannot answer a basic question: what cryptographic algorithms, keys, and certificates are deployed across their infrastructure? The answer matters because you cannot secure, migrate, or audit cryptography you have not inventoried.

The problem is scale. A mid-size enterprise typically operates hundreds of TLS endpoints, thousands of certificates, dozens of key management systems, and millions of lines of application code that make cryptographic API calls. Cryptographic assets are embedded in web servers, load balancers, databases, message queues, container images, serverless functions, IoT firmware, and email gateways.

Manual audits cannot keep pace. They rely on questionnaires, documentation reviews, and targeted scans of known systems. They miss the cryptography that teams deployed without central oversight — the self-signed certificates in development environments, the hardcoded algorithm selections in legacy code, the SSH keys that predate the current key management policy.

Automated cryptographic discovery through CBOM changes this equation. It scans infrastructure systematically, catalogs every cryptographic asset it finds, and produces a structured inventory that compliance teams, security architects, and migration planners can act on.

Discovery Across Infrastructure Layers

Effective cryptographic discovery must cover every layer where cryptographic assets exist. Each layer presents different scanning challenges and yields different asset types.

Source Code Repositories

Source code scanning identifies cryptographic API calls, algorithm selections, and key generation patterns in application code. Static analysis detects calls to cryptographic libraries (OpenSSL, BouncyCastle, libsodium, platform-native APIs) and extracts the algorithm parameters.

This layer catches problems that network scanning cannot see: hardcoded algorithm choices buried in business logic, deprecated hash functions used for data integrity checks, and weak random number generation in key derivation. It also identifies cryptographic library versions, which map to known vulnerabilities.

Network Services and Protocol Configurations

Network discovery probes TLS endpoints, SSH servers, and other protocol-based services to catalog their cryptographic configurations. For each endpoint, it records the supported protocol versions, cipher suites, key exchange mechanisms, and certificate chains.

This scanning covers web servers, API gateways, load balancers, database connections, message broker endpoints, and any service that negotiates a cryptographic protocol. The results reveal which endpoints still support TLS 1.0/1.1, which use RSA key exchange (vulnerable to quantum attack), and which have certificates approaching expiration.

PKI and Certificate Authority Systems

Integration with PKI infrastructure provides a complete view of the certificate landscape. This includes certificates issued by internal CAs, certificates from public CAs, and certificates managed through ACME or other automated issuance protocols.

Discovery at this layer captures certificate metadata that network scanning alone cannot provide: issuance policies, chain-of-trust relationships, revocation status, and renewal history. It also identifies orphaned certificates — those issued but no longer deployed on any known endpoint.

LDAP and Directory Services

Active Directory and LDAP scanning reveals certificate-based authentication configurations, Kerberos encryption types, and LDAP signing/sealing settings. These are critical cryptographic assets that often fall outside the scope of network-focused security tools.

Enterprise directory services frequently use legacy encryption types (RC4 for Kerberos, for example) that represent both security and compliance risks. Discovery flags these configurations for remediation.

Cloud Provider Environments

Cloud discovery uses provider APIs to catalog cryptographic configurations across AWS, Azure, and GCP. This includes KMS key inventories, managed certificate deployments (ACM, Azure Key Vault, GCP Certificate Manager), encryption-at-rest configurations, and cloud HSM settings.

Cloud environments are particularly challenging for manual audits because resources are provisioned dynamically, often by automated pipelines. A single Terraform apply can create dozens of resources with cryptographic configurations. Continuous API-based discovery keeps the inventory current.

Hardware Security Modules

HSM integration captures the inventory of hardware-protected keys, their FIPS validation levels, firmware versions, and access policies. HSMs represent the highest-value cryptographic assets in most organizations — the root CA keys, code signing keys, and payment processing keys that underpin trust.

Discovery at this layer verifies that HSM-protected keys meet the required FIPS 140-2/140-3 validation levels and that firmware is current. It also identifies keys that should be HSM-protected but are stored in software keystores instead.

Container and Kubernetes Environments

Container image scanning identifies cryptographic libraries bundled in Docker images, their versions, and their configurations. Kubernetes scanning discovers TLS certificates mounted as secrets, service mesh mTLS configurations, and ingress controller cipher suites.

Container environments are ephemeral by nature. Images are rebuilt, pods are rescheduled, and configurations change with each deployment. Discovery must integrate with the container lifecycle to maintain an accurate inventory.

From Discovery to CBOM

Raw discovery data becomes actionable when structured as a CycloneDX CBOM. The CBOM format standardizes how each discovered asset is represented — its type, properties, deployment context, and relationships to other assets.

The transformation from scan results to CBOM involves:

1. Asset classification — each discovered item is typed as an algorithm, certificate, key, protocol, or cryptographic library
2. Property extraction — algorithm names, key lengths, protocol versions, and configuration details are normalized to CycloneDX schema fields
3. Risk annotation — each asset is classified by quantum vulnerability (quantum-vulnerable, quantum-safe, unknown)
4. Relationship mapping — dependencies between assets are recorded (which services use which certificates, which applications call which libraries)

The resulting CBOM document is machine-readable, diffable, and integrable with security tooling. It serves as the single source of truth for an organization’s cryptographic posture.

Continuous Discovery as an Operational Practice

Point-in-time discovery produces a snapshot that begins aging immediately. Cryptographic assets change with every code deployment, certificate renewal, infrastructure provisioning event, and configuration update.

Continuous discovery treats cryptographic inventory as a living dataset. Scans run on schedules aligned with deployment cycles. New assets are automatically classified and added to the CBOM. Removed assets are flagged for decommission verification. Changes to existing assets trigger alerts when they introduce risk — a downgrade from TLS 1.3 to TLS 1.2, for example, or a new service using RSA-2048 key exchange.

QCecuring is developing CBOM as its next planned offering, building on the certificate and key discovery capabilities already available in the CLM and SSH KLM platforms. The planned CBOM capability will extend automated discovery across the full infrastructure stack described above, producing CycloneDX-compliant reports that feed directly into compliance workflows and PQC migration planning.