CBOM Scanning: From Source Code to Cloud Infrastructure

Nine Scanning Targets for Complete Coverage

A Cryptographic Bill of Materials is only as useful as the scanning that populates it. Incomplete scanning produces an incomplete inventory, which leads to blind spots in compliance reporting and migration planning. Comprehensive CBOM scanning must cover nine distinct infrastructure categories, each requiring different scanning techniques and yielding different cryptographic asset types.

Source Code Scanning

Source code is where cryptographic decisions are made. Developers choose algorithms, configure key lengths, select cipher suites, and call cryptographic library APIs. Source code scanning uses static analysis to identify these decisions before they reach production.

The scanner parses code across languages (Java, Python, Go, C/C++, JavaScript, Rust, C#) and identifies:

• Cryptographic library imports — OpenSSL, BouncyCastle, libsodium, Go’s crypto package, .NET’s System.Security.Cryptography
• Algorithm selections — explicit algorithm names passed to encryption, signing, and hashing functions
• Key generation parameters — key lengths, curve selections, random number generator usage
• Deprecated patterns — MD5 for integrity, SHA-1 for signatures, DES/3DES for encryption, RC4 for stream encryption
• Insecure configurations — ECB mode, static IVs, PKCS#1 v1.5 padding, null cipher suites

Source code scanning catches cryptographic risks at the earliest possible stage. A developer selecting RSA-1024 in application code is flagged before the code is merged, not after it has been deployed to production and discovered during a compliance audit.

LDAP and Directory Services

Active Directory and LDAP environments contain cryptographic configurations that are invisible to network-only scanning tools. CBOM scanning of directory services discovers:

• Kerberos encryption types — which encryption algorithms are configured for Kerberos authentication (AES-256, AES-128, RC4-HMAC, DES-CBC)
• LDAP channel binding and signing — whether LDAP connections require signing and channel binding tokens
• Certificate-based authentication — smart card logon certificates, certificate mapping configurations
• Group policy cryptographic settings — minimum key lengths, approved algorithms, and protocol restrictions enforced through GPO

Many organizations still have RC4-HMAC enabled for Kerberos backward compatibility. CBOM scanning identifies these legacy configurations and quantifies the scope of remediation required.

PKI and Certificate Authority Systems

PKI scanning goes beyond network-level certificate discovery by integrating directly with certificate authority infrastructure. This provides metadata that TLS endpoint scanning cannot capture:

• Issued certificate inventory — every certificate issued by internal and external CAs, including those not currently deployed
• Certificate templates — which templates are available, their key usage constraints, and algorithm requirements
• Chain-of-trust relationships — root CA, intermediate CA, and end-entity certificate hierarchies
• Revocation status — CRL and OCSP responder configurations, revoked certificate lists
• Issuance policies — approval workflows, validity periods, and renewal automation status

This layer is critical for identifying orphaned certificates (issued but not deployed), shadow CAs (unauthorized certificate issuance), and certificates approaching expiration without automated renewal.

Web Servers and Network Services

Network scanning probes every TLS-enabled endpoint to catalog its cryptographic configuration. For each endpoint, the scanner records:

• Protocol versions — TLS 1.0, 1.1, 1.2, 1.3 support
• Cipher suites — the ordered list of supported cipher suites, including key exchange, bulk encryption, and MAC algorithms
• Certificate details — subject, issuer, signature algorithm, key type and length, validity period, SANs
• Key exchange mechanisms — RSA, DHE, ECDHE, and their parameter sizes
• HSTS and certificate pinning — HTTP Strict Transport Security headers and public key pinning configurations

Network scanning covers web servers, API gateways, load balancers, database listeners, message broker endpoints, SMTP/IMAP servers, and any service that negotiates TLS or SSH.

Cloud Provider Environments

Cloud scanning uses provider-native APIs to discover cryptographic configurations that are not visible through network probing:

AWS: KMS key inventories (CMKs, data keys, key policies), ACM certificate deployments, S3 bucket encryption (SSE-S3, SSE-KMS, SSE-C), RDS encryption at rest, EBS volume encryption, CloudHSM cluster configurations, Secrets Manager encryption settings.

Azure: Key Vault keys and certificates, App Service TLS configurations, Storage Account encryption, Azure SQL TDE settings, Managed HSM inventories, Azure Disk Encryption configurations.

GCP: Cloud KMS key rings and crypto keys, Certificate Manager deployments, Cloud Storage default encryption, Cloud SQL encryption, Confidential Computing configurations.

Cloud environments change rapidly. Resources are provisioned and decommissioned by automation pipelines, often without security team visibility. API-based scanning runs continuously to keep the CBOM current with the actual cloud state.

Hardware Security Modules

HSM scanning captures the highest-value cryptographic assets in the organization. Integration with HSM management interfaces discovers:

• Key inventories — all keys stored in the HSM, their types, lengths, and usage attributes
• FIPS validation levels — the HSM’s FIPS 140-2/140-3 certification level and operational mode
• Firmware versions — current firmware and whether updates are available
• Access policies — which applications and users can access which keys
• Key ceremony records — root key generation and backup procedures

HSM-protected keys typically include root CA private keys, code signing keys, payment processing keys, and database encryption master keys. These are the assets where compromise has the highest impact, making accurate inventory essential.

Container and Kubernetes Environments

Container scanning operates at two levels: image analysis and runtime discovery.

Image analysis examines Docker images in registries to identify bundled cryptographic libraries, their versions, and known vulnerabilities. A single base image update can change the cryptographic library version across hundreds of deployed containers.

Kubernetes runtime discovery catalogs TLS certificates mounted as Kubernetes secrets, service mesh mTLS configurations (Istio, Linkerd), ingress controller cipher suites, and pod-to-pod encryption settings. It also identifies certificate rotation configurations and whether certificates are managed by cert-manager or manually provisioned.

Email Gateway Scanning

Email infrastructure uses cryptography extensively, and it is frequently overlooked in security assessments. CBOM email scanning discovers:

• S/MIME certificates — user and organizational certificates for email signing and encryption
• TLS configurations — SMTP STARTTLS settings, cipher suites, and certificate deployments on mail servers
• DKIM signing keys — domain key lengths and algorithm selections
• Email encryption gateway settings — policy-based encryption configurations and key management

Building the Complete Picture

No single scanning technique provides complete cryptographic visibility. Source code scanning misses runtime configurations. Network scanning misses embedded cryptography. Cloud API scanning misses on-premises infrastructure. The value of CBOM comes from combining all nine scanning categories into a unified, CycloneDX-compliant inventory.

QCecuring is developing comprehensive CBOM scanning as its next planned offering, building on the certificate and SSH key discovery capabilities already available in the existing platform. The planned approach will integrate scanning results from all infrastructure categories into a single CBOM report, with each asset classified by quantum risk level and mapped to compliance framework requirements.