How to find weak cryptography with a CBOM
Algorithms, keys, protocols and certificates, where weak cryptography hides, which public baselines define 'weak', and how to query a CBOM to find it.
- CERT-In defines CBOM asset types as algorithms, keys, protocols and certificates; weak cryptography can hide in each.
- TLS 1.0 and 1.1 are deprecated by RFC 8996; NIST SP 800-131A Rev. 2 sets a 112-bit minimum security strength and disallows two-key TDEA and, after 2023, three-key TDEA encryption.
- Express each rule as a query on CBOM fields, protocol version, key size, primitive, mode, notValidAfter, so it can run on every new CBOM version.
- Start with internet-facing TLS and certificate expiry, then code libraries, keys and internal traffic.
- Flag quantum-vulnerable algorithms separately: they are not weak today, but NIST's draft transition plan sets 2030 and 2035 milestones.
Why cryptography needs its own inventory
Cryptography is everywhere and owned by no one. It is configured in load balancers, compiled into applications, stored in HSMs, embedded in firmware and negotiated with partners. Weaknesses, legacy protocols, short keys, deprecated hashes, expiring certificates, rarely show up in an SBOM or a vulnerability scan, because the software version may be current while its configuration is not.
A Cryptographic Bill of Materials closes that gap. CERT-In's Version 2.0 guidelines define four CBOM asset types, algorithms, keys, protocols and certificates [1]and list "early detection of cryptographic weaknesses" among the benefits of a CBOM. CycloneDX provides the fields that make each weakness queryable [2].
What "weak" means: public baselines
| Area | Weak or deprecated usage | Reference |
|---|---|---|
| Protocols | TLS 1.0, TLS 1.1 and DTLS 1.0; RFC 8996 says TLS 1.0 and 1.1 "MUST NOT be used" | RFC 8996 [3] |
| Security strength | Anything below 112 bits for applying cryptographic protection | NIST SP 800-131A Rev. 2 [4] |
| Key sizes | RSA and finite-field DH/DSA below 2048 bits; elliptic-curve keys below 224 bits | NIST SP 800-131A Rev. 2 [4] |
| Hashes | SHA-1 for digital signature generation, except where specific NIST protocol guidance allows it | NIST SP 800-131A Rev. 2 [4] |
| Block ciphers | Two-key TDEA encryption (disallowed); three-key TDEA encryption (disallowed after 2023) | NIST SP 800-131A Rev. 2 [4] |
| Modes | ECB for data encryption; unauthenticated modes where integrity matters | Internal cryptographic policy |
| Certificates | Expired or near-expiry; self-signed in production; weak signature algorithms; unapproved issuers | Internal PKI policy |
| Quantum exposure | RSA, ECDSA, EdDSA, ECDH and finite-field DH protecting long-lived data | NIST IR 8547 (draft): deprecated after 2030 at 112-bit, disallowed after 2035 [5] |
Turning baselines into CBOM queries
Each rule becomes a test on specific CycloneDX fields [2]:
| Rule | CBOM test |
|---|---|
| No TLS below 1.2 | protocolProperties.type = tls and version in 1.0, 1.1 (and any SSL version) |
| No weak cipher suites | cipherSuites[].algorithms references an algorithm asset that fails another rule |
| Minimum key size | relatedCryptoMaterialProperties.size below threshold for the referenced algorithmRef |
| Minimum strength | algorithmProperties.classicalSecurityLevel < 112 |
| No ECB | algorithmProperties.mode = ecb |
| No SHA-1 signatures | A certificate's signatureAlgorithmRef points to a SHA-1-based signature algorithm |
| Certificate expiry | certificateProperties.notValidAfter within the next 30 days, or already past |
| Compromised keys in use | state = compromised on a key still referenced by an active component |
| Quantum-vulnerable | primitive in signature, pke, key-agree for RSA/ECC/DH families, or nistQuantumSecurityLevel = 0 |
Run these on every new CBOM version so a regression is caught when it appears, not at the next audit.
Where to look first
- Internet-facing TLS endpointsprotocol versions, cipher suites, certificate chains. Fast to scan with tools such as testssl.sh [6] and highly exposed.
- Certificates across the estateowners, expiry dates and issuers. Expiry is a common cause of cryptography-related outages.
- Internal service-to-service trafficmTLS, message queues and databases, often left on older defaults.
- Cryptographic libraries in codeversions of OpenSSL, BoringSSL, Bouncy Castle and others, plus hard-coded algorithm choices.
- Keys in HSMs and KMSalgorithm, size, state, creation and rotation dates.
- SSH, VPN and remote accesshost keys and negotiated algorithms; ssh-audit reports key exchange, host-key, cipher and MAC algorithms [7].
- Code and firmware signinglong-lived keys that anchor trust and are hard to rotate.
Avoiding false confidence
- A clean result may mean incomplete discovery. Check coverage before reporting; see CBOM validation.
- "Supported" is not "used". A server that offers TLS 1.0 is a finding even if most clients negotiate TLS 1.3.
- A library that implements a weak algorithm is not proof the application uses it; confirm with code-level evidence before raising a ticket.
From findings to a programme
- Record every asset with its owner and the application it serves.
- Write the cryptographic policy as rules the CBOM can be tested against, with time-limited exceptions.
- Prioritise by exposure and business criticality.
- Forecast certificate expiry and route renewals to owners.
- Build a quantum view on top of the CBOM, see preparing for post-quantum cryptography and crypto-agility.
How IntelliXBOM helps
IntelliXBOM ingests and validates CBOMs, keeps version history so new weak cryptography is visible in diffs, and correlates algorithms, keys, protocols and certificates with vulnerabilities, end-of-life data and the business services they support. Findings and decisions are recorded as timestamped evidence mapped to framework controls.
Frequently asked questions
What counts as weak cryptography?
Common baselines include TLS 1.0 and 1.1, which RFC 8996 deprecates, and anything below NIST's 112-bit minimum security strength, such as RSA keys under 2048 bits. SHA-1 for signature generation, TDEA encryption and ECB mode are also typically treated as weak.
How does a CBOM help find weak cryptography?
A CBOM records protocol versions, key sizes, algorithm primitives and modes, and certificate dates in structured fields. Each policy rule becomes a query on those fields that can run automatically against every new CBOM version.
Is RSA-2048 weak?
RSA-2048 meets NIST's current 112-bit minimum, so it is not weak by today's classical baseline. It is quantum-vulnerable, however, and NIST's draft IR 8547 proposes deprecating 112-bit quantum-vulnerable algorithms after 2030 and disallowing them after 2035.
Sources
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- CycloneDX v1.6 JSON Reference (bom-1.6 schema)OWASP CycloneDXcyclonedx.org/docs/1.6/json/
- RFC 8996, Deprecating TLS 1.0 and TLS 1.1 (March 2021)IETFwww.rfc-editor.org/rfc/rfc8996
- SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019)NISTcsrc.nist.gov/pubs/sp/800/131/a/r2/final
- NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards (November 2024)NISTnvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
- testssl.shtestssl.sh project (GitHub)github.com/testssl/testssl.sh
- ssh-auditssh-audit project (GitHub)github.com/jtesta/ssh-audit
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.