CBOM

What Is a CBOM (Cryptographic Bill of Materials)?

A CBOM, or Cryptographic Bill of Materials, is a complete inventory of the cryptography that runs inside a piece of software, a system, or a product.

Its entries cover encryption algorithms, key lengths, digital certificates, and security protocols, plus the cryptographic libraries an application calls on.

Anything that performs or supports encryption is a cryptographic asset. That includes an algorithm, a key, a certificate, and a protocol, and the record notes each one's version, its configuration, and the components that rely on it.

Consider a web application. Its CBOM might record RSA handling key exchange, TLS 1.3 protecting transport, and OpenSSL powering both.

A CBOM builds on the Software Bill of Materials, or SBOM, which lists every software component in an application. A CBOM narrows that view down to the cryptography alone.

Written in a machine-readable format, a CBOM lets tools parse and check the file on their own, sparing anyone the job of reviewing every entry by hand.

Cryptography guards passwords, payments, and private messages. Pointing a security team to where that protection sits, a CBOM helps them catch weak or outdated cryptography before an attacker does.

What Does a CBOM Include?

Within a CBOM, cryptographic assets fall into a handful of main categories, and every entry carries the properties that describe it.

1. Cryptographic algorithms

Algorithms handle the math of encrypting data, signing it, or hashing it. AES, RSA, and SHA-256 come up constantly. For each, the record notes the algorithm, its mode, and its key length.

2. Keys and secrets

Keys unlock encrypted data, and secrets include tokens or passwords stored inside code. The CBOM records details such as key length and rotation policy. Only information about a key goes into the record, never the raw key itself.

3. Digital certificates

A certificate proves the identity of a website or a service. Listed with its issuer and expiry date, each certificate gives a team the lead time to replace it before it lapses.

4. Protocols

Protocols are the rules two systems follow to talk securely, TLS, SSH, and IPsec among them. Since older versions carry known weaknesses, the record captures exactly which protocol versions are running.

5. Cryptographic libraries

Prewritten code that hands cryptographic functions to an application is called a library, with OpenSSL and Bouncy Castle two common examples. The CBOM maps which software components depend on which library.

How Does a CBOM Work?

A CBOM works by scanning software to find where cryptography is present, then listing what it finds in a standard file. Scanning tools inspect three sources where cryptography tends to hide:

• Source code, where algorithms and key handling are written directly

• Compiled binaries, where cryptography is built into the shipped software

• Configuration files, where protocols and certificate settings are defined

The results are written using an open standard called CycloneDX, which many teams already use to produce a SBOM. A CBOM extends that same standard to describe cryptography.

Because the output follows a shared format, one tool can generate the CBOM and another can read it without custom translation.

Teams often generate a CBOM inside their build pipeline. The inventory then refreshes each time the software changes, so the record stays current.

Why Is a CBOM Important?

A CBOM is important because most organizations cannot see the cryptography spread across their systems, which leaves security gaps unnoticed. Cryptography usually lives inside libraries and dependencies, so no single team holds a full picture of it. A CBOM brings that scattered detail into one place, and that visibility supports four things:

• Quantum readiness. Within the next decade or so, quantum computers are expected to break several of the algorithms that protect data today. A move to quantum-safe cryptography starts with knowing what needs to change, and a CBOM supplies that starting list. NIST, the US standards body, has recommended extending the software bill of materials with a CBOM as part of its guidance for post-quantum cryptography.

• Regulatory compliance. Rules such as PCI DSS and HIPAA require strong encryption that an organization must be able to prove, and a CBOM provides that evidence. This supports wider regulatory compliance efforts.

• Risk management. A CBOM strengthens IT risk management by exposing algorithms that have expired or fallen out of date.

• Gaps that scanners miss. A routine vulnerability assessment hunts for software flaws rather than checking cryptographic hygiene, so deprecated algorithms can slip past it entirely.

What Are the Use Cases of a CBOM?

A CBOM has use cases across security planning, audits, and day-to-day operations. Each use case turns the inventory into a practical action.

1. Post-quantum migration planning

A CBOM shows which algorithms and key lengths are open to quantum attack. Teams use that list to decide what to replace first when they move to quantum-safe cryptography.

2. Supply chain software reviews

Third-party software can hide weak or outdated cryptography. A CBOM lets a buyer check the cryptographic quality of a vendor's product before bringing it into the environment.

3. Certificate and crypto lifecycle management

Certificates and keys expire, and old ones create risk. With a live record of each item, a team can rotate or renew them on schedule.

4. Compliance and certification readiness

Standards like FIPS and Common Criteria ask for proof of how cryptography is used. Rather than chasing scattered evidence, auditors get that proof in one record.

5. Faster incident response

When a new cryptographic weakness is disclosed, a CBOM shows within minutes which systems use the affected algorithm or library. Quick answers shorten the window of exposure during a crypto incident.

What Are the Best Practices for a CBOM?

A CBOM stays accurate, safe to share, and easy to act on only with the right habits behind it. A few of them make the difference.

1. Automate generation

Produce the CBOM automatically inside the build pipeline. A manual inventory falls out of date the moment the software changes.

2. Use a standard format

Keep the CBOM in an open, machine-readable format such as CycloneDX. A shared format means one tool can create the file and another can read it, with no extra work in between.

3. Protect key material

List details about keys, never the keys themselves. Access to the record should stay restricted, which fits a zero trust approach and keeps sensitive material out of any export.

4. Cover every environment

Sweep on-premise, cloud, and remote systems into one inventory. Any cryptography left off the record turns into a blind spot.

5. Share ownership across teams

Cryptographic hygiene is shared work across developers, operations, and security staff. Name a clear owner, and the CBOM stays current with someone accountable for acting on what it reveals.