Hunting Cryptographic Weaknesses at Scale with CBOM and CodeQL

TLDR: Most enterprise applications are built on a massive, opaque supply chain of open-source libraries, many of which use deprecated or insecure cryptographic primitives. This research introduces the Cryptographic Bill of Materials (CBOM) and a scalable CodeQL-based methodology to map and audit these dependencies across thousands of repositories. By automating the identification of weak algorithms like MD5 and SHA-1, security teams can finally move from reactive patching to proactive cryptographic agility.

Modern software development is a game of Jenga played with thousands of third-party blocks. When you pull a dependency into your project, you are not just importing functionality. You are importing the entire cryptographic history of that library, including every legacy algorithm, hardcoded configuration, and insecure default that the original author decided to include. Most organizations have no visibility into this. They know their own code, but they are blind to the cryptographic primitives hiding deep within their dependency tree.

The Problem with Cryptographic Opacity

Security researchers often focus on the "what" of a vulnerability, but the "where" is usually the harder problem. If you want to find every instance of an insecure RSA key generation or a weak hashing algorithm across an entire organization, you cannot rely on manual code reviews or simple grep commands. You need a way to map the cryptographic landscape of your entire software portfolio.

The research presented at Black Hat 2023 shifts the focus toward Cryptographic Bill of Materials (CBOM). Unlike a standard Software Bill of Materials (SBOM) that lists components, a CBOM specifically inventories the cryptographic algorithms, key sizes, and configurations used by those components. It turns the "space of possibilities" into a queryable dataset.

Automating the Hunt with CodeQL

Manually tracing data flow to find how a cryptographic key is configured is tedious and error-prone. The researchers demonstrated that CodeQL is the ideal engine for this task because it treats code as data. By writing declarative queries, you can perform interprocedural data flow analysis to track a variable from its source to a cryptographic sink.

Consider a scenario where you want to find insecure RSA key generation in C++ using OpenSSL. You are not just looking for a function call. You are looking for the configuration of that function. A simple query can identify where EVP_PKEY_CTX_set_rsa_keygen_bits is called and, more importantly, what value is passed to it.

import cpp
import semmle.code.cpp.dataflow.DataFlow

from FunctionCall fc, DataFlow::Node source, DataFlow::Node sink
where fc.getTarget().getName() = "EVP_PKEY_CTX_set_rsa_keygen_bits"
and DataFlow::localFlow(source, sink)
select fc, "Insecure RSA key size detected"

This approach scales. By running these queries across thousands of repositories using Multi-Repository Variant Analysis (MRVA), you can identify patterns of misuse that would otherwise remain invisible. If a specific library is consistently misconfigured, you can flag it, remediate it, and verify the fix across the entire organization in minutes.

From Detection to Remediation

Finding the bug is only half the battle. The real challenge is coaching developers to fix it without slowing down the release cycle. The researchers integrated this analysis into a CI/CD pipeline using the CBOM Reporter, which generates machine-readable reports in the CycloneDX standard.

When a developer introduces a weak primitive, the pipeline doesn't just break the build. It provides context. By leveraging GitHub Copilot with Retrieval Augmented Generation (RAG), the system can offer tailored remediation advice based on the organization's specific security standards. Instead of a generic "don't use MD5" warning, the developer receives a suggestion that aligns with the company's internal cryptographic policy, complete with the correct library calls to use instead.

Why This Matters for Pentesters

For those of us on the offensive side, this methodology changes how we approach target reconnaissance. During an engagement, we often spend hours manually auditing dependencies to find a foothold. If you can generate a CBOM for your target, you can instantly identify the "low-hanging fruit" of cryptographic failures.

If you see an application using SHA-1 for digital signatures or a hardcoded 1024-bit RSA key, you have a clear path for exploitation. This is a direct application of OWASP A02:2021 – Cryptographic Failures. By automating the discovery of these failures, you spend less time grepping for strings and more time developing the exploit chain.

Building Cryptographic Agility

Defenders must stop treating cryptography as a "set it and forget it" component. The threat of quantum computing, often referred to as "Q-Day," is the ultimate driver for this work. If an attacker captures encrypted traffic today, they can store it and decrypt it once a sufficiently powerful quantum computer becomes available. This "harvest now, decrypt later" strategy makes the use of weak primitives a permanent liability.

The path forward is cryptographic agility. You need the ability to swap out algorithms and configurations without rewriting your entire application. This requires a deep understanding of your dependencies and a robust, automated way to monitor them. Start by auditing your own projects. Use the tools provided by the researchers to generate your first CBOM. Once you see the reality of what is running in your production environment, you will understand why this is the most critical research area in modern application security. The hunt is on, and the first step is knowing exactly what you are hunting.