Inside a CBOM: Designing a Cryptographic Software Bill of Materials

As explored in our initial post What is a CBOM, understanding what cryptographic technologies are embedded in software has become a critical security and compliance need. The Cryptographic Bill of Materials (CBOM) was designed with this reality in mind. “A Cryptography Bill of Materials (CBOM) is an object model to describe cryptographic assets and their dependencies.” (CycloneDX CBOM Guide). This means not just identifying which cryptographic algorithms or protocols are present in a codebase, but understanding how they are used, which components they depend on, and how these relationships impact risk posture and compliance obligations.

One of the most critical starting points for a CBOM is the way it models crypto assets. These include algorithms and protocols such as RSA, AES, or TLS, typically implemented within cryptographic libraries. But a CBOM also includes hardcoded algorithms in application code, as well as embedded assets, aligning with the CBOM specification’s emphasis that “cryptographic assets include algorithms, protocols, keys, certificates, and other related material that participate in cryptographic operations, all of which should be represented”. (CycloneDX CBOM Guide)

However, it is not enough to know that AES is in use. One must also know whether it is AES-128-GCM or another variant, as this affects the cryptographic primitive in use, such as authenticated encryption, and ultimately the security guarantees provided. Similarly, distinguishing between related constructs such as SHA1 and HMAC-SHA1 is critical due to their different security implications. This granularity enables automated analysis and policy enforcement by tools ingesting CBOM data. This level of precision is something we are actively advancing through our ongoing collaboration with IBM, aimed at extracting exact cryptographic parameters, usage contexts, and implementation configurations.

Crucially, a CBOM is part of a broader industry effort to improve cryptographic transparency within software supply chains. It extends the CycloneDX SBOM standard by introducing crypto assets as distinct components and adding the dependencyType field to distinguish usage from implementation dependencies, enabling seamless adoption within the CycloneDX ecosystem. At the same time, the SPDX project is advancing complementary standards to represent cryptographic materials such as keys, certificates, and algorithms within SBOMs. Together, these initiatives reflect a growing consensus to provide standardised, actionable cryptographic data that strengthens supply chain security.

As part of this landscape, SCANOSS contributes by identifying which components use cryptographic algorithms, a key part of building a CBOM. This capability helps generate accurate inventories of cryptographic usage across software components, supporting organisations in achieving greater OSS risk intelligence.

A key resource is SCANOSS’s open Crypto_algorithms_open_dataset, a curated collection of cryptographic algorithm implementations and patterns. This dataset enhances the identification and analysis of cryptographic assets within software components by providing concrete reference points for tooling to detect cryptographic usage accurately. Integrating this dataset with CBOM-aligned tooling empowers organisations to achieve deeper cryptographic transparency.

The urgent transition to post-quantum cryptography (PQC), combined with mounting regulatory pressure and the growing need for cryptographic agility, makes a CBOM an essential asset for any organisation seeking long-term security and compliance.