How to Audit Your Codebase for Cryptographic Dependencies

Building a CBOM is a critical first step toward crypto-agility. The CBOM is a comprehensive inventory of cryptographic code usage within the organization, making it easier to identify applications that are in scope for quantum migration or impacted by a deprecated algorithm or vulnerable library.

Building the CBOM can be tricky because applications can access cryptography in several ways. Organizations should use a variety of tools to gain full visibility into their cryptographic footprint.

What to Look For

Cryptography can hide in various places within an organization's environment. Some places to look and things to look for include:

Function Calls: Some applications will directly call cryptographic functions, such as AES encryption or a digital signature function. Note down the algorithm used and any parameters provided to it.
Library Imports: It's best practice to use trusted cryptographic libraries like Bouncy Castle to implement cryptography. These third-party dependencies can be direct or transitive (imported by other dependencies).
Configuration Settings: Cryptographic algorithms may be specified as part of software configurations. Examples include TLS ciphersuites, JWT settings, or the default cryptographic algorithms of a particular framework or tool.
Size Assumptions: Application code may make assumptions about the size of various cryptographic parameters, such as the length of the encryption key. Fixed buffer sizes, key lengths defined as constants, and fixed byte counts can break when transitioning to a new algorithm.
Insecure Algorithms: Some cryptographic algorithms have been deprecated or are considered weak and on the way out. Examples include MD5, RSA-1024, SHA-1, and 3DES.
Custom Cryptography: Homegrown cryptography is almost always insecure and should never be used. NIST runs multi-year contests to define its standards, and algorithms that survived multiple years of review by top cryptanalysts are sometimes still practically breakable.

A CBOM entry for a cryptographic algorithm should include everything needed to make decisions about security and migration. This includes location, algorithm, parameters, library and version, use case, and whether the function is called directly or via a crypto API.

Audit Techniques and Their Limitations

Most tools and techniques for a cryptography audit won't catch every use of crypto within an organization's codebase. For a comprehensive inventory, it's important to use a variety of techniques, including:

String and Pattern Matching: Text-based searches can be used to identify mentions of specific algorithms, like AES or RSA. However, they are prone to false positives (comments, etc.) and miss algorithms selected at runtime.
Static Analysis: Static analysis tools that understand ASTs can follow API calls and parameters, making them a solid tool for seeing where an algorithm is called. However, they're language specific and miss runtime selections as well.
Software Composition Analysis (SCA): SCA is designed to map out an application's dependency tree, which can identify cryptographic libraries and the versions in use. It doesn't specify which algorithms are used and can miss vendored, statically linked, and shaded copies.
Binary and Container Scanning: Analysis of software binaries and containers can be used to identify cryptographic algorithms in vendored software and third-party artifacts where source code is unavailable.
Network Traffic Analysis: Cryptography is commonly used to encrypt or sign data traveling over the network. Analysis of network traffic can uncover TLS ciphersuites.
Dynamic Analysis: Runtime analysis can be used to identify what algorithms are actually selected and used at runtime. However, it can only see those code paths that are executed.
Config and IaC Review: Cryptographic algorithms may be defined within configurations. Reviewing config files and infrastructure as code (IaC) files can help to uncover these.

Best Practices for a Cryptography Audit

When performing a cryptography audit to build a CBOM, best practices include:

Select Complementary Tools: CBOMkit is a well-known tool for identifying crypto usage and building a CBOM, but its language support is limited. It should be paired with static analysis and SCA tools to provide broader visibility into an organization's cryptographic footprint. Tools should be selected to ensure comprehensive coverage across audit techniques and languages in use.
Perform a Controlled Test: Most organizations won't be able to use a single crypto discovery tool that covers all techniques and supports every language that they use. Run a controlled test over a small repo and compare tool outputs to known crypto usage within that repo.
Normalize Output: The various tools needed to perform a comprehensive crypto audit will likely produce a diverse set of outputs. These should be normalized to a common format for inclusion in the CBOM. Many tools designed for this purpose will automatically support CycloneDX to make this easier.
Deduplicate Findings: Using multiple audit techniques is vital to achieve comprehensive coverage, but it can create duplicate entries. For example, TLS ciphersuites may show up due to network analysis, config review, and runtime analysis. Deduplicate identical or overlapping entries.
Classify and Tag Results: CBOM entries should be tagged with information designed to make it easier to answer various questions. Example tags can include use cases (at rest encryption, signing, etc.), risk type (classic asymmetric, weak symmetric, etc.), and access method (direct call or API abstraction).

Keeping the Inventory Up-To-Date

A one-time audit is a snapshot of an organization's cryptographic usage and can quickly grow stale as applications are introduced or updated. Best practices for ensuring that the inventory remains useful include:

CI/CD Integration: Integrate tools like static and dynamic analysis and SCA into CI/CD pipelines. This ensures that CBOM entries are added or updated when the code changes.
Block Violations: Direct library calls and deprecated algorithms weaken crypto-agility and place data at risk. These violations should be blocked from future code by lint rules.
Track Metrics: An up-to-date CBOM should simplify and streamline quantum migration and incident response to vulnerable libraries. Tracking metrics can help to demonstrate the value of the inventory and the wider crypto-agility program.

FAQs

Can't we just grep for algorithm names?

grep can be useful for identifying cryptographic algorithms whose names are included in an application's source code. However, it misses a lot, such as third-party dependencies, runtime algorithm selection, and algorithms accessed via an API (or functions not including the algorithm name).

How is a cryptographic audit different from a normal SAST or SCA scan?

Traditional SAST and SCA scans are designed to identify exploitable vulnerabilities or out-of-date libraries within an organization's codebase. A cryptographic audit uses similar tools to identify the cryptographic algorithms that the organization uses.

How often should we re-audit?

After the first, manual audit, cryptographic audits should be performed continuously and automatically. CI/CD integrations and lint rules can be used to identify changes to the inventory when updated code is pushed to the repo.

What do we do about cryptography in third-party code we can't change?

Ideally, issues with third-party cryptography (such as deprecated or quantum-vulnerable algorithms) can be managed by switching to an alternative solution or working with the vendor. If this isn't the case, the issue should be documented, and the organization can take steps to mitigate or monitor the risk.