Cryptographic Bill of Materials (CBOM) Deep-Dive

Introduction

In the context of quantum readiness, understanding what cryptography your software uses is as critical as knowing the software components themselves. A Cryptographic Bill of Materials (CBOM) is an emerging concept that provides a detailed inventory of all cryptographic assets in a system – from algorithms and key lengths to certificates and crypto libraries. Just as a Software Bill of Materials (SBOM) lists the components of software, a CBOM enumerates the cryptographic primitives and materials, giving security teams granular visibility into the “crypto” under the hood.

Modern drivers like post-quantum threats, regulatory mandates, and the need for crypto-agility are fueling CBOM adoption. Governments and standards bodies now urge organizations to inventory their cryptography as a first step toward stronger cryptographic hygiene and transition to quantum-safe algorithms. For security architects and CISOs, CBOMs offer deep technical insight paired with actionable guidance: they shine a light on potential weaknesses (e.g. use of deprecated algorithms or short keys), ensure compliance with cryptographic policies, and enable proactive planning (such as migrating vulnerable algorithms before quantum computers break them). So I will attempt to provide a guide to CBOMs – their definition, composition, creation, standards, tooling, and how they integrate into broader security and governance practices.

What is a Cryptographic Bill of Materials (CBOM)?

A Cryptographic Bill of Materials (CBOM) is a structured inventory that describes all cryptographic assets in a software system and their relationships. In essence, it is to cryptography what an SBOM is to software components. The CBOM concept has been spearheaded by the OWASP CycloneDX project as an extension to the SBOM standard. According to CycloneDX, a CBOM includes detailed information on algorithms, cryptographic keys, certificates, protocols, and how these relate to the software’s components. This level of detail allows organizations to assess the robustness of their cryptographic implementations and identify weaknesses such as the use of outdated cipher suites or expiring certificates.

Notably, CBOM builds upon SBOM. A CBOM can be thought of as a “crypto-focused SBOM.” In fact, NIST defines a CBOM as extending an SBOM by defining an object model for cryptographic assets and their dependencies. While an SBOM is a record of software components (packages, libraries, modules, etc.), a CBOM is a record of cryptographic components (crypto algorithms, keys, certs, etc.) used within that software. The CBOM can either be integrated into an SBOM or maintained as a separate but linked artifact. The key purpose of a CBOM is to make cryptography transparent: it provides visibility into what cryptography is present, where it’s used, and in what way, thereby enabling better risk management of cryptographic systems.

Why CBOM is Increasingly Important

Several trends have made CBOMs critical in modern cybersecurity:

• Quantum Computing Threats: Advances in quantum computing threaten to break many widely used cryptographic algorithms (especially RSA, ECC, and other public-key algorithms). Organizations are racing to become quantum-safe. A first step in any post-quantum migration is to perform a comprehensive cryptographic inventory. Both government and industry recognize this – for example, a U.S. White House memorandum (OMB M-23-02) in late 2022 mandated federal agencies to inventory their cryptographic systems as part of a transition to post-quantum cryptography. CycloneDX explicitly positions CBOM as a tool to help catalog crypto assets and identify those that are not quantum-safe, supporting compliance with standards like the National Security Memorandum on PQC. In short, you cannot transition to quantum-safe algorithms if you don’t know what algorithms you’re using today, and CBOM is designed to provide that knowledge.
• Weak/Deprecated Crypto Management: Beyond quantum concerns, many organizations struggle with shadow or legacy cryptography – for instance, hardcoded uses of MD5, SHA-1, old TLS protocols, or expired X.509 certificates lurking in systems. CBOMs offer a way to continuously identify such weak cryptography. By listing algorithm variants and key details, a CBOM makes it easy to spot if an application still uses deprecated algorithms (e.g. SHA-1 vs a secure hash). It helps answer questions like: Are any 1024-bit RSA keys still in use?, Where do we rely on SHA-1 or 3DES?, Do we have certificates or keys nearing expiration? – and do so in an automated fashion. This directly reduces risk by enabling crypto updates before they become incidents (for example, replacing an approaching certificate before it causes downtime).
• Cryptographic Agility & Incident Response: Crypto-agility is the ability to swap out cryptographic algorithms or implementations quickly in response to new vulnerabilities or policy changes. To be agile, you need to know exactly which applications use which cryptography. CBOMs empower more effective incident response: if a new vulnerability is announced in an algorithm or library (say a flaw in an encryption mode or in OpenSSL), a CBOM repository lets you rapidly identify all software using that vulnerable crypto and prioritize fixes. Conversely, CBOMs also aid in verifying claims that a given vulnerability does not affect you – for example, if a CVE impacts RSA usage but your CBOM shows you only use ECC, you can confidently assert non-impact (often via a VEX, discussed later).
• Regulatory and Compliance Requirements: There is growing regulatory pressure around cryptography governance. Standards like NSA’s CNSA 2.0 Suite (for national security systems) or industry regulations (e.g. Payment Card Industry (PCI) requirements, FedRAMP, Common Criteria) demand use of approved algorithms and modules. An authoritative inventory of crypto usage helps demonstrate compliance with such standards. For example, NSA’s CNSA 2.0 requires agencies to prefer certain quantum-resistant algorithms by specific deadlines. With a CBOM documenting what algorithms (and key lengths) are used where, an organization can check compliance (are all algorithms CNSA-approved?) and plan upgrades where gaps exist. Similarly, frameworks like NIST’s Secure Software Development Framework (SSDF) call for maintaining provenance data (SBOMs) and by extension cryptography inventories for each release. CBOMs make fulfilling these governance controls much more straightforward by providing machine-readable evidence of cryptographic implementations.

In summary, CBOMs are becoming as important as SBOMs because cryptography is everywhere and carries unique risks. As CISA noted in its Post-Quantum Cryptography Initiative, organizations should “conduct an inventory to identify and understand cryptographic systems and assets” as a foundation for secure migration. A CBOM provides exactly that capability in a standardized way.

CBOM vs SBOM (and Other Related Artifacts)

It’s useful to clarify how a CBOM differs from – and complements – a traditional SBOM. The table below compares key aspects of SBOMs and CBOMs:

Other related artifacts:

• VEX (Vulnerability Exploitability eXchange): A VEX is a machine-readable advisory that states whether specific software components are affected by known vulnerabilities. While not a “Bill of Materials,” VEX documents are complementary to SBOM/CBOM. A CBOM can enhance VEX analysis by providing context on cryptography-related vulnerabilities. For instance, if a vulnerability exists in an encryption algorithm or TLS library, the CBOM lets you quickly see if that algorithm/library is used in the product, informing the VEX assessment. Just as SBOM and VEX work together to manage component risk, CBOM plus VEX can together address crypto vulnerabilities – e.g., a VEX might note “Product not impacted by CVE-XXXX (weak RSA key generation) because it uses only ECDSA as per CBOM”. In essence, CBOMs supply the cryptographic inventory data that can feed into VEX statements about cryptography-related exposures.
• Other BOMs (HBOM, SaaSBOM, etc.): The concept of BOMs is expanding. Hardware BOMs (HBOM) list hardware components, SaaS BOMs list cloud services dependencies, ML-BOMs list machine learning models, etc. CBOM is one of these specialized BOM types addressing a specific domain (cryptography). All these BOMs aim to increase transparency of different facets of an overall system. They are not competitors but complementary. For example, a comprehensive software supply chain report might include an SBOM (software components), an HBOM (hardware/firmware components), and a CBOM (crypto details) for the product. Industry initiatives sometimes refer to this combined approach as xBOM (eXtended BOM) support. The CycloneDX framework explicitly supports multiple BOM types under one ecosystem, enabling rich links between them. For instance, a CBOM could reference a cryptographic module listed in an HBOM, or an SBOM library entry could have an associated CBOM section detailing its cryptographic algorithms.

In short, SBOM and CBOM serve different but synergistic purposes. SBOM maps “what software we have”; CBOM maps “what cryptography that software uses”. When used together, they give a 360° view of software risk. SBOM addresses supply chain/component risk, and CBOM addresses cryptographic risk. And when paired with VEX and other attestations, organizations gain powerful insight into both the ingredients of their software and the security posture of those ingredients from both vulnerability and cryptography standpoints.

Core Elements That Make Up a CBOM

What information does a Cryptography BOM actually contain? A well-constructed CBOM will enumerate all the relevant cryptographic elements in a system along with important properties of each. Below are the core elements typically included:

• Cryptographic Algorithms: Every cryptographic algorithm or cipher used by the software should be listed. This includes symmetric ciphers (e.g. AES, ChaCha20), asymmetric algorithms (RSA, ECC curves like secp256r1, etc.), hash functions (SHA-256, SHA-1), MACs, key exchange schemes, random number generators, and so on. For each algorithm, a CBOM captures specific details – for example, not just “AES” but the variant and mode, like AES-128-GCM or AES-256-CBC. Knowing the variant is crucial, since security properties differ (AES-128-GCM is an authenticated cipher with 128-bit key, whereas AES-256-CBC with PKCS7 padding has different security considerations). A CBOM entry for an algorithm can include fields such as the cryptographic primitive (e.g. block cipher, hash, stream cipher), the mode of operation (CBC, GCM, etc.), any padding scheme used, and the key length or parameters (e.g. 2048-bit for RSA, curve name for ECC). It may also record crypto functions associated (e.g. whether the algorithm is used for encryption, decryption, signature, key generation, etc.) Crucially, CBOMs often tag algorithms with security strength levels – both classical security (bits of security against conventional attacks) and quantum security categories as defined by NIST (e.g. category 1–5, or 0 if not quantum-safe). For instance, RSA-2048 might be noted as ~112-bit classical security and “quantum security level 0” (since Shor’s algorithm can break it). This helps assess at a glance which algorithms are considered weak or strong against various threat models.
• Cryptographic Keys and Key Material: Any cryptographic keys or related secret material should be captured. CycloneDX CBOM defines a category for related cryptographic material, which covers things like private keys, public keys, key pairs, passwords, shared secrets, tokens, etc. For keys, important attributes include the type (e.g. RSA private key, ECC public key, AES symmetric key), the size/length (e.g. 2048 bits, 256 bits), and the format or encoding (PEM, DER, PKCS#8, etc.) A CBOM can also indicate whether a key is stored in a secured manner (for example, in an HSM or encrypted form). Another critical aspect is the lifecycle status of keys – if known, the CBOM might include metadata like creation date, activation date, last rotation date, and expiration or deactivation date for keys. For example, a CBOM entry for an TLS server certificate’s private key could note it’s a 3072-bit RSA key created in 2021, expiring in 2024. Tracking key lifecycle dates is extremely useful for operational risk management (e.g. ensuring keys/certs are rotated before expiry). As one industry guide notes, capturing the life cycle of cryptographic material in the inventory provides context that is instrumental for managing cryptographic risk. Keys that are due to expire or long-lived keys that pose higher risk (e.g. a root certificate valid for 20 years) stand out in a CBOM.
• Digital Certificates and PKI Artifacts: Certificates (and related trust store items) are first-class cryptographic assets. A CBOM will list any X.509 certificates or similar credentials present in the system, whether they are used for TLS, code signing, S/MIME, etc. For each certificate, key properties include the subject name (whose identity the cert represents) and issuer name (the CA), the validity period (not valid before/after dates), and the public key algorithm and parameters (e.g. “RSA 2048-bit” or “ECC secp384r1”). It can also note the certificate format (PEM, DER, JWK, etc.) and any pertinent extensions (for instance, if it has certain key usage or policy extensions). Including certificates in the CBOM is important for detecting issues like impending expiration, use of untrusted/self-signed certs, or weak signature algorithms (e.g. an otherwise strong key but signed with SHA-1 would be flagged). Also, certificates tie into compliance – e.g. a CBOM can help ensure all certificates meet organizational or regulatory standards (such as using SHA-256+ signatures, ECC keys of required size, etc.)
• Cryptographic Libraries and Modules: While an SBOM lists software libraries in general, a CBOM highlights the cryptography-specific libraries or modules. This covers libraries like OpenSSL, BoringSSL, WolfSSL, Bcrypt, JCE providers, Crypto++ or any custom cryptographic module the software includes. For each such library, the CBOM can list which algorithms/protocols it implements and which of those the application actually uses (the distinction between providing and using is modeled via dependency types, explained below). Knowing the library and version is vital because it ties into known vulnerabilities (e.g. OpenSSL 1.1.1 vs 3.x, or a particular version with a known bug) and into certifications (e.g. whether the library is FIPS 140-3 validated at some level). Some CBOM schemas include a field for certification level on algorithm implementations, where for example an algorithm can be tagged with a FIPS 140-3 Level 2 if it’s implemented in a validated module. Crypto libraries often come with their own set of compliance considerations, and listing them helps in auditing those. Additionally, referencing the library in CBOM allows correlating with SBOM data – for instance, your SBOM might show OpenSSL 3.0.2 is included, and CBOM then details which algorithms from OpenSSL are in use (maybe you use its TLS and RSA functionality but not its legacy algos).
• Protocols and Usage Context: Cryptography is often employed within higher-level protocols or frameworks (like TLS, SSH, IPsec, JWT tokens, etc.) A CBOM captures the usage context by documenting cryptographic protocols and their settings. For example, if the software uses TLS, the CBOM can list the TLS protocol versions supported and the cipher suites enabled. If the software uses IPsec, it can list the IKEv2 transform types and parameters in use. Essentially, this part of CBOM answers: How is cryptography being used in practice? – Is it for network encryption (TLS 1.3 with AES-GCM), for data at rest (AES-CBC in a database), for authentication (HMAC-SHA256 in tokens), etc. By enumerating protocols and configurations, CBOM helps ensure the usage is aligned with best practices. For instance, if a CBOM shows that only TLS 1.2+ is allowed and only strong cipher suites (e.g. ECDHE-ECDSA-AES256-GCM-SHA384) are configured, a CISO can be more confident about transport security. Conversely, if outdated protocol versions or weak cipher suites appear, they can be flagged for remediation. In CycloneDX CBOM, protocolProperties allow specifying protocol type and details like cipher suites for TLS, as shown in the spec.
• Relationships and Dependencies: One powerful aspect of a CBOM is that it not only lists crypto items in isolation but also describes the relationships between software components and cryptographic assets. Two key relationship types are often modeled: “implements” and “uses.” An “implements” relationship links a software component (like a crypto library) to the algorithms it provides. A “uses” relationship links a component (e.g. an application) to the crypto assets it actually invokes or consumes. For example, OpenSSL might implement AES-256-GCM, and your web server application uses AES-256-GCM via OpenSSL. Capturing this allows impact analysis: just because a library implements an algorithm doesn’t mean the application uses it – CBOM differentiates these cases. If a vulnerability is announced in an algorithm implementation, you can check if the application actually uses that part. CycloneDX’s CBOM model explicitly introduced a dependencyType to mark dependencies as implements vs uses. Additionally, dependencies can show how crypto assets relate to each other – e.g., a certificate uses a particular public key algorithm, a protocol uses certain algorithms (TLS uses ECDH, etc.) These relationships mirror real-world crypto architecture and help maintain a clear picture of crypto flow in the system.
• Metadata and Flags: Beyond the core items above, CBOMs may include various metadata to support analysis and automation:
  • Object Identifiers (OIDs): Standard OIDs can be recorded for algorithms or parameters, which is useful for precise identification of crypto (e.g. the OID for AES-128-GCM or for a specific ECC curve). This removes ambiguity when multiple naming schemes exist.
  • Detection Details: If the CBOM is generated by automated tools, it can carry metadata about how and where each item was detected. For instance, CycloneDX CBOM allows including a detectionContext array with file paths, line numbers, or code snippets where a cryptographic asset was found. This is more relevant for developers or auditors who need to trace back the inventory to source locations. It can greatly aid remediation by pointing exactly to, say, the file where an MD5 constant or cryptographic API call was present.
  • Confidence Levels: When static analysis or heuristics are used, some detections might be uncertain. A CBOM can assign a confidence score to each identified crypto asset. For example, if a string “AES” in code was flagged, the tool might mark algorithm detection with 0.8 confidence. This helps users of the CBOM gauge how much they need to verify manually.
  • Compliance Indicators: Some CBOM frameworks include fields or could utilize custom extensions to mark compliance or policy status. While not a standardized part of CBOM yet, one could imagine tags like “FIPS-approved” or “deprecated” on algorithms. Currently, compliance is usually inferred (e.g. if certificationLevel is set to a FIPS 140-3 level, that implies FIPS compliance of that implementation). As CBOM matures, we may see more direct flags (for instance, a boolean if an algorithm is disallowed by policy, etc., which could be added as an extension or via an accompanying attestation – note that CycloneDX 1.6 also added a concept of security attestations, which could be used to declare compliance status).

In summary, a CBOM is rich with details: it’s not just a list of algorithm names. It captures the who-what-where-how of cryptography in the system – what algorithms and keys, in which components, used for what purpose, at what strength, and with what relationships. The end result is a machine-readable map of the cryptographic posture of the software. This granularity is precisely why CBOMs are useful: they turn nebulous cryptographic usage into concrete data points that can be reasoned about (automatically where possible). As the CBOM spec states, the goal is to make crypto assets “actionable for further reasoning” – meaning once you have this data, you can programmatically check for policy compliance, find vulnerabilities, assess quantum risk, etc.

How to Generate a CBOM

Creating a Cryptography BOM might sound daunting given the detail involved. However, much of it can be automated by leveraging existing data sources and analysis tools. Generation of a CBOM typically involves gathering information from various parts of the software lifecycle and then compiling that into the standardized CBOM format. Here we break down the process and how to integrate it into CI/CD pipelines for continuous coverage.

Data Sources for Building a CBOM

To generate a CBOM, you need to discover all cryptographic elements in the target software. Key data sources and methods include:

• Source Code Analysis: Static analysis of source code (or binaries) is a primary method. By scanning the codebase for known cryptographic API calls, constants, or patterns, tools can identify algorithms and keys. For example, scanning for usages of libraries like OpenSSL, CryptoAPI, java.security, or even literal strings (like “AES”, “SHA256”) and constants (like OIDs for algorithms) can surface what cryptography the code is invoking. Modern static analysis tools and plugins are being developed to output findings directly as CBOM data. For instance, IBM Research created a SonarQube plugin (“CBOMkit-hyperion”) that detects crypto assets in source and automatically generates a CBOM. Code scanning platforms like GitHub Advanced Security (CodeQL) can also be scripted to find crypto usage and feed results into a CBOM generation tool – one community project demonstrates generating a CBOM from CodeQL scan output. The static analysis approach ensures you catch even those crypto uses hidden in the code (e.g., a developer hardcoded an AES key or implemented a custom crypto routine).
• Binary/Bytecode Analysis: In cases where source is not available or to double-check runtime dependencies, analyzing the compiled artifact can help. This might involve scanning binaries for signatures of cryptographic algorithms (common in reverse engineering – certain sequences of bytes or mathematical constants indicate an implementation of AES, etc.) or using tools that introspect bytecode (for Java, .NET). While more complex, this can reveal crypto usage that static source analysis might miss (for example, if a library is loaded at runtime or via reflection). Organizations like ReversingLabs provide tooling that can analyze compiled software and produce a SBOM and CBOM, even for commercial third-party applications. Their platform can deconstruct an application and identify cryptographic algorithms and keys embedded within, showing that binary analysis is a viable data source when needed.
• Dependency & Package Metadata: A lot of cryptography comes through third-party libraries. By examining your SBOM or dependency list, you can determine which known crypto libraries are present (e.g. OpenSSL, mbed TLS, BouncyCastle, libsodium). This gives a hint at which algorithms could be in use. The SBOM can be a starting input to CBOM generation – for each component in SBOM, you might query a knowledge base of what crypto that component provides. Some SBOM tools or extensions might integrate this. In CycloneDX’s approach, because CBOM is an extension of SBOM, one could augment the SBOM components with crypto detail. For example, if SBOM lists OpenSSL 1.1.1, a CBOM process might automatically add entries for the algorithms OpenSSL implements (or those actually used by your app through OpenSSL). NIST’s guidelines envision such integration: cryptography discovery tools might correlate SBOM component data with crypto findings to build a fuller inventory.
• Configuration Files and Settings: Don’t forget that cryptography is often configured via files or environment, not solely through code. Look at TLS configuration files (to see allowed protocols/cipher suites), keystore files (JKS, PKCS#12 containing keys and certs), properties files specifying algorithm choices, etc. These can be parsed to extract cryptographic parameters and assets. For instance, if an application loads keystores or certificate files, those files are a source of certificate and key info for the CBOM. Automated tools should scan typical locations for such artifacts (like .pem or .crt files for certificates, .key files, .p12 keystores, etc., as well as application configs for any crypto-related settings). This falls under “non-executable file objects” in NIST’s cryptographic discovery terminology – it includes certificates, keys, and similar data on disk.
• Running Environment (Dynamic Discovery): In some cases, dynamic analysis can complement static methods. Tools can observe a running program to see what crypto it uses at runtime – for example, hooking into cryptographic library calls or analyzing TLS handshakes outgoing from the app. Network traffic analysis can identify protocols and cipher suites actually negotiated. While dynamic methods may be harder to automate in CI, they can be part of a broader inventory effort. NIST’s NCCoE project on cryptographic discovery considered sensor-based approaches where network sensors and host sensors gather crypto usage data in real time. For most software development scenarios, though, static analysis and build-time inspection suffice, with dynamic methods used for special cases or validation.

Once these data sources are mined, the gathered information (list of found algorithms, keys, certs, etc., with their attributes) is then normalized into the CBOM format. Tools or scripts perform this translation, mapping discovered items to the CBOM schema fields (asset types, properties, dependency linkages). The goal is to automate as much as possible because manual creation of a CBOM for any non-trivial codebase would be very time-consuming and error-prone.

Integrating CBOM Generation into CI/CD Pipelines

To keep CBOMs up-to-date, it’s best to generate them as part of your continuous integration/continuous delivery (CI/CD) pipeline, much like many teams do for SBOMs today. Here are some actionable ways to do that:

• Leverage Existing SBOM Tools with CBOM Support: If you are already generating SBOMs during builds (using tools like CycloneDX’s Maven/Gradle plugins, Syft, etc.), check if they support CBOM data. The CycloneDX project has updated its toolchain to support the new cryptography fields introduced in version 1.6 of the spec. For example, the CycloneDX Maven Plugin can now include cryptographic information in the BOM it generates. A sample CI job might simply run the CycloneDX plugin and produce a BOM in CycloneDX 1.6 format, which inherently includes any CBOM entries (commonly, the output file cyclonedx-bom.xml or .json will contain <component type=”cryptographic-asset”> entries if crypto was detected). Integrating this is as easy as adding a build step (similar to how you would “Generate SBOM” – now “Generate CBOM”) and storing the artifact. An example GitHub Actions pipeline is shown below, where after building a Java project, the CycloneDX plugin is invoked to create a CBOM and then that file is archived as a build artifact :

- name: Build Project
  run: ./gradlew build

- name: Generate CBOM
  run: cyclonedx-maven-plugin:generate

- name: Upload CBOM Artifact
  uses: actions/upload-artifact@v2
  with:
    name: cbom
    path: target/cyclonedx-bom.xml

• The above would yield an SBOM file in CycloneDX format that includes cryptographic components. As tooling matures, expect more off-the-shelf SBOM generators to automatically populate crypto fields, especially if the languages/frameworks are known (for example, it could automatically list all Java’s security providers and their algorithms, etc.)
• Use Specialized CBOM Tooling: There are purpose-built tools emerging for CBOM creation. IBM’s CBOM Toolkit (CBOMkit) is one such suite. It includes multiple components:
  • cbomkit-hyperion: a static analysis plugin to detect crypto assets in code (as mentioned earlier).cbomkit-theia: a tool for scanning container images or filesystems for cryptographic material (useful for post-build scanning of Docker images or deployment packages) .cbomkit-action: a GitHub Action that wraps these tools to easily drop into CI pipelines to generate CBOMs .cbom-viewer (coeus): a web UI to visualize CBOM results (for post-generation analysis).
  To integrate such tooling, you can add a step in the pipeline to run the scanner. For example, using cbomkit-action in GitHub Actions would allow an out-of-the-box CBOM generation step. Or using cbomkit as a CLI in Jenkins/others: run a command to analyze the repository and produce a cbom.json. These tools often output CycloneDX JSON conforming to the CBOM schema, ready to use. Always ensure the tool’s configuration (e.g., providing path to source, or image name for container) matches your build context.
• Combine SCA and CBOM tasks: If you already perform Software Composition Analysis (SCA) or other security scans in CI (dependency scanning, container scanning, static code analysis), consider including cryptography discovery as part of that stage. For instance, after running SAST (Static Application Security Testing), run a cryptography scan. Some SAST tools might eventually include cryptography rules. Also, an SBOM generator like Syft can be extended with custom detectors – one might add patterns for crypto (though currently Syft mainly targets packages). You could script a combination: run a CodeQL query pack that finds crypto usage, then post-process results into CBOM format. This requires some engineering but leverages existing CI infrastructure.
• Automate CBOM Validation: When integrating generation, also include a validation step to catch issues early. CycloneDX provides JSON schemas for BOMs; you can use their CLI or tools like ajv (JavaScript JSON schema validator) to validate that the generated CBOM file is well-formed. For example, after generating cbom.json, run a schema validate in CI; this ensures the CBOM adheres to the standard and can be consumed by other tools.
• Storage and Access: Plan where the CBOM artifacts will live. Often teams store SBOMs as build artifacts or publish them alongside releases. CBOMs should be handled similarly. You may version-control them (some store SBOM/CBOM in the repo for each release tag), or push them to an artifact repository or SBOM management system. The key is to make sure the CBOM for each build/release is retrievable by those who need it (security, compliance teams, etc.). OWASP’s Dependency-Track platform (which ingests SBOMs for continuous monitoring) is likely to support CBOM data as well, given it already aligns with CycloneDX – consider leveraging such platforms to import CBOMs for ongoing monitoring of crypto posture.

One important point: Automate continuous generation. Cryptography in a project can change over time (e.g., a developer may introduce a new cipher usage in a feature update). By integrating CBOM generation into CI, you ensure that any change that impacts cryptography is immediately reflected in an updated CBOM. This continuous approach aligns with the idea that CBOMs (like SBOMs) are snapshots in time – each build’s snapshot can be compared to the last to see what changed. For example, you might set a rule that any introduction of a disallowed algorithm (detected in the new CBOM) breaks the build or at least alerts security.

Example: Generating a CBOM in Practice

As a concrete illustration, suppose we have a Java web application using Maven. We want to produce a CBOM on each build. We do the following:

1. Add CycloneDX Plugin: Configure the CycloneDX Maven plugin in pom.xml with version supporting 1.6 spec.
2. Install IBM’s CBOM SonarQube Plugin: (Optionally) If we have a SonarQube analysis in CI, add the CBOM plugin to it. After running sonar, it will output crypto findings.
3. CI Pipeline Steps: In Jenkins or GitHub Actions:
   • Build the application (e.g., mvn package).
   • Run CycloneDX: mvn cyclonedx:build -DschemaVersion=1.6 (hypothetical usage) to generate bom.xml. This SBOM will include CBOM info because of schema 1.6. If the plugin doesn’t auto-detect crypto yet, we might use the Sonar output or a script to enrich it.
   • Alternatively, run cbomkit-theia on the output JAR/WAR or container image of the app to detect any embedded keys or certs.
   • Validate the output and archive it.
4. Review and Use: The security team can then review the CBOM (manually or via a tool). For example, the CBOM might show that this build is using TLS 1.3 and AES-256-GCM, which is good, and maybe a certificate that expires in 6 months, prompting proactive renewal.

By embedding these steps, generating a CBOM becomes a routine DevSecOps practice, much like running unit tests or security scans. The overhead is relatively low (the tools run quickly) and the payoff is a living cryptographic inventory that’s updated with every code change.

Standards and Tools Supporting CBOM

The concept of CBOM is new but rapidly gaining traction, with standards bodies and vendors beginning to support it. Here we outline the primary standard (CycloneDX) and some tools/platforms that can be used to create, validate, and utilize CBOMs.

• CycloneDX 1.6 (and above): CycloneDX, an OWASP Foundation project, is the leading standard for CBOM. Version 1.6 of CycloneDX, released in early 2024, formally introduced native support for Cryptographic BOM content. It incorporates the research done by IBM and others into an official spec. CycloneDX defines the “cryptographic-asset” component type and the cryptoProperties schema we discussed, covering algorithms, certificates, protocols, related material, etc. It also extends the dependency model to handle provides/uses relationships for crypto. This means that CycloneDX’s JSON and XML formats (which are already widely used for SBOM) can now fully represent CBOM information in a standardized way. The importance of this standardization is that it enables interoperability – tools can produce a CBOM and any CycloneDX-compatible tool can parse it. CycloneDX 1.6 is backward-compatible in the sense that BOM files simply have additional fields for crypto; if a tool doesn’t know them, it can ignore, but new tools will leverage them. The CycloneDX project has also published an Authoritative Guide to CBOM to help practitioners implement it. This guide, along with examples, is a valuable resource for understanding how to model various real-world cryptographic assets in a CBOM format.
• SPDX and Others: SPDX is another SBOM format (governed by the Linux Foundation). As of now, SPDX doesn’t have a dedicated cryptography extension akin to CycloneDX’s CBOM. There is ongoing discussion in the community about extending SBOM standards to include security metadata. However, CycloneDX is currently ahead on this front. It’s worth noting that CycloneDX has become an international standard (ISO/IEC via ECMA), which could pave the way for its cryptography model to be broadly adopted. We might see other standards catch up or provide mappings (e.g., a future SPDX version might allow listing crypto details in annotations). For the moment, organizations implementing CBOM are overwhelmingly using CycloneDX.
• NIST and Regulatory Guidance: While not a format standard, NIST’s National Cybersecurity Center of Excellence (NCCoE) is actively promoting cryptographic inventories. In their drafts on PQC migration, they describe using CBOMs as part of an asset inventory effort. NIST SP 1800-38B (Preliminary Draft) mentions experimenting with creation of CBOMs and notes that CBOMs “have the potential to enable organizations to manage and report usage of cryptography” in a standardized way. This kind of acknowledgment lends credibility and likely means future NIST guidance will reference CBOM practices. CISA (Cybersecurity & Infrastructure Security Agency) in the U.S. is also pushing automated cryptography discovery tools and presumably common formats for reporting. A CISA strategy document from 2025 supports agencies using tools that “automate the collection of cryptographic characteristics required for the inventory” and annually report their crypto inventory. Although it doesn’t name CBOM explicitly, the alignment is clear – CBOM would be an ideal format to share such an inventory. Similarly, standards bodies like ETSI have flagged CBOM as useful; an ETSI report on a framework for quantum-safe migration notes that if an enterprise maintains SBOMs or CBOMs, these can aid in the asset inventorying process for crypto agility. The involvement of groups like ETSI and government agencies indicates CBOM concepts are being woven into best practices and maybe future compliance requirements.
• Open Source Tools for CBOM:
  • CycloneDX CLI: The CycloneDX project provides a command-line tool that can perform various SBOM operations (merging, converting formats, validating, etc.). As CycloneDX 1.6 is out, the CLI is expected to handle CBOM data too. For example, you could use it to validate a BOM file that contains CBOM info or to merge an SBOM and CBOM if generated separately. It ensures that the format is correct and can produce human-readable summaries.
  • IBM CBOM Toolkit: As discussed, IBM has open-sourced a suite of tools (available on GitHub). These include scanning tools (for source code and container images), a GitHub Action, and a visualization tool. The IBM toolkit aligns with CycloneDX and was actually the basis for CycloneDX’s official spec update. By using these tools, practitioners can kickstart CBOM generation without building their own scanners from scratch.
  • Cybeats SBOM Studio: Some SBOM management companies (like Cybeats) have shown interest in CBOM. The snippet from a Cybeats tutorial repository suggests they are exploring CBOM generation via CodeQL and CycloneDX plugin. Their commercial SBOM tools might incorporate crypto inventory features. Likewise, OWASP Dependency-Track (an SBOM consumption and monitoring platform) will likely incorporate CBOM components into its analysis, given it already supports CycloneDX BOMs. This means organizations could use Dependency-Track to continuously watch for issues in the crypto assets listed in CBOM (for example, flagging if any algorithm in your CBOM is found to be non-compliant or newly broken).
  • ReversingLabs xBOM integration: On the commercial side, ReversingLabs announced support for CBOM in their Spectra platform. This allows scanning of software (including third-party) to generate a cryptographic inventory and assess risk. They highlight that CBOM provides insight into cryptographic assets that could be exploited by quantum threats. Such tools can be useful to audit software from suppliers or perform due diligence on applications where you don’t have source code – by generating a CBOM from the binary and then checking for weak crypto.
• Validation and Policy Tools: Another class of tools will validate a CBOM against policies. For instance, given a CBOM, a simple script or future open-source tool could parse it and check: “Are any algorithm entries in a banned list? Are all keys at least X bits? Are any certs expired or using disallowed CA?” etc. This is an area where custom automation can be written today using the JSON output, and we expect products to add such features. For example, an attestation in CycloneDX format (CDXA, CycloneDX Attestations) could be used to encode policy requirements and then verify the CBOM against it – effectively compliance-as-code, where CBOM provides the facts and an attestation provides the expected rules.
• Standards on the Horizon: Besides CycloneDX, it’s worth noting if any other standards bodies like IETF are addressing cryptographic inventories. While the IETF primarily focuses on protocol-specific standards, they have recognized cryptographic agility in protocols (e.g., making algorithms replaceable in TLS, IPsec, etc.). The concept of a machine-readable crypto inventory is more likely to remain in domain of SBOM standards and not become its own IETF RFC, but IETF participants are certainly aware (some of the authors of NIST’s draft and CycloneDX are from companies active in IETF). Additionally, ISO/IEC might eventually create guidelines for managing cryptographic inventories as part of cybersecurity frameworks. Already ISO 27002:2022 includes control suggestions for cryptographic key management and inventories (though not in such structured format). In practice, CycloneDX’s adoption by ECMA and usage by NIST means it effectively is the de facto standard for CBOM going forward, with potential to become formally recognized via those channels.

In summary, the ecosystem around CBOM is rapidly evolving. CycloneDX CBOM is the cornerstone – it provides the language and structure. Around it, we have early but growing tool support from open source projects (IBM’s contributions, OWASP tools) and commercial solutions (ReversingLabs, etc.). The direction is clear: in the near future, generating and consuming CBOMs will likely be as commonplace as SBOMs are becoming today, especially as regulatory and supply-chain security demands increase. Security leaders should keep an eye on these tools and standards, and possibly participate in their development to ensure they meet organizational needs.

CBOM in Context: SBOM, VEX, and PQC Transition

Let’s zoom out and see how CBOMs fit into the broader picture of cybersecurity artifacts and initiatives.

• CBOM and SBOM Together: Rather than thinking of CBOM vs SBOM as an either/or, it’s best to view them as complementary pieces of a comprehensive security BOM (or xBOM) strategy. An SBOM gives you insight into what components are in your software. A CBOM gives you insight into what cryptography those components (and the overall system) rely on. Using both provides a layered understanding. For example, from SBOM you might know you have OpenSSL 1.1.1k in your product. From CBOM, you learn that you are using OpenSSL’s TLS with ECDHE and AES-256-GCM cipher suites, and not using any deprecated ciphers. If tomorrow OpenSSL 1.1.1k has a vulnerability in, say, the RSA implementation, your CBOM could show whether you actually use RSA in that product or not. If you don’t (perhaps you only use ECDSA certificates), you could issue a VEX stating the product is not affected – and you have the evidence to back it up via CBOM data. Thus, CBOM augments SBOM data with security context. Organizations should include CBOMs in their software transparency reporting alongside SBOMs to get a full risk profile. Indeed, the OWASP CycloneDX project envisions a scenario where a single BOM can carry multiple facets of data (software components, crypto details, vulnerabilities, etc.), or multiple linked BOMs can be used. This could streamline processes like risk reviews, supplier security evaluations, and customer assurances – instead of just providing an SBOM to a customer, a supplier might also provide a CBOM to prove that, for example, no legacy crypto is used in their product (which is increasingly a concern for buyers preparing for quantum threats).
• CBOM and VEX: The Vulnerability Exploitability eXchange (VEX) is a format (often in JSON, sometimes using CSAF or CycloneDX) for communicating the status of vulnerabilities in products. VEX answers “is product X affected by vulnerability Y?” with details. How does CBOM come into play? Many vulnerabilities are cryptography-related: think of vulnerabilities like the ROBOT attack on RSA, the SHA-1 collision attacks, CVE-2019-1559 (TLS 1.3 bug in OpenSSL), or even side-channel weaknesses in certain algorithms. A CBOM gives you a quick way to check if the vulnerable crypto component is present. If your CBOM shows no RSA, and a new RSA-specific vuln comes out, you can confidently create a VEX stating “Not affected – RSA not in use per cryptography inventory.” Conversely, if a vulnerability is discovered in (say) how a library implements ECDSA, your CBOM would show which of your products use ECDSA and at what key sizes, allowing you to prioritize patches and craft precise VEX statements for each (some might be affected, some not, depending on usage context). Essentially, CBOM is a source of truth that can make VEX automation more accurate and fine-grained. In practice, we may see tooling where VEX generators take SBOM + CBOM as input: SBOM to know if the vulnerable component is present, CBOM to know if the vulnerable functionality of that component is actually used. This can reduce false positives and unnecessary alerts. Moreover, CBOM could be used to track cryptography-specific advisories that aren’t traditional CVEs. For example, if NIST declares that RSA-1024 is no longer secure, that’s not a CVE but it’s a security advisory; you could query your CBOMs to find where RSA-1024 is used and then effectively create internal “VEX-like” notifications or remediation tasks for those. As CycloneDX evolves, there may even be a notion of a Bill of Vulnerabilities (BOV) or similar for crypto (CycloneDX has a Vulnerability Disclosure Report (VDR) and a BOV concept). CBOM would feed into those by pinpointing which crypto assets have known issues.
• CBOM and Post-Quantum (PQC) Transition Planning: This is perhaps the area where CBOM has gained the most attention initially. The world is preparing to transition to Post-Quantum Cryptography (PQC) algorithms in the coming years. Governments have timelines for phasing in quantum-resistant algorithms, and standards bodies like NIST have selected new PQC algorithms (e.g., CRYSTALS-Kyber, Dilithium for general use). The foundational step in any transition plan is discovery: identify all places where cryptography is used and especially where quantum-vulnerable algorithms (like RSA, ECC, DH, DSA) are used. CBOM is purpose-built for this task. For example, the National Cybersecurity Strategy and OMB memos require agencies to submit crypto inventories and roadmap their migration. A CBOM would allow an agency to list, for each system, all instances of (for example) RSA-3072 or ECDH, etc., and then overlay that with plans to replace them with PQC alternatives by certain deadlines. CycloneDX explicitly mentions aligning CBOM with the National Security Memorandum on PQC readiness. NIST’s draft SP 1800-38B underscores that automated cryptography discovery (which yields a CBOM) is key to quantum readiness. And ETSI’s quantum-safe migration framework highlights using CBOMs to support steps like dependency analysis and risk assessment in the migration process. In practice, how would this look? An organization might generate CBOMs for all their applications and then filter the data: e.g., “Show me all uses of RSA or ECC in any system classified as a High-Value Asset.” Those become top priority to replace with PQC (like Kyber or a hybrid scheme) as per guidance. Without a CBOM, this task might involve manual code reviews or relying on engineers’ memory – error-prone and slow. With CBOM, it’s a query on structured data. Additionally, CBOM can track progress: if in 2023 you had 50 instances of RSA across your portfolio and by 2025 you’ve eliminated half in favor of PQC, your CBOMs can quantitatively show that improvement. CISA’s strategy expects agencies to annually report cryptographic inventory updates – CBOM can serve as that report format, making it straightforward to diff last year vs this year. In summary, CBOM acts as a roadmap and scorecard for PQC transition, ensuring nothing using vulnerable cryptography slips through the cracks during the upgrade cycle.
• CBOM and Overall Governance: CBOMs also tie into general security governance and risk management beyond PQC. Many organizations have crypto policies (for instance, “No use of less than AES-128 encryption; all certificates must be at least SHA-256 signed; only TLS 1.2+ allowed; private keys must be stored securely” etc.). Enforcing these policies historically has been challenging because there wasn’t an easy way to get a snapshot of all cryptographic usage. CBOM changes that. Governance teams can require a CBOM for each major release and include it in an architecture review. Using the CBOM, they can systematically check compliance with the crypto policy (possibly even automate the checks). It becomes part of the software development life cycle checkpoints: analogous to a security design review, now you have a cryptography design review with concrete data. If a CBOM shows a disallowed algorithm, that issue can be addressed before release. Think of CBOM as enabling a continuous cryptography compliance audit – but one that’s automated and scaled. Industry standards like ISO 27001 emphasize an inventory of cryptographic controls and keys; CBOM could be the evidence that such controls are in place and monitored.

In essence, CBOMs link the world of software supply chain security (traditionally SBOM, vuln management, etc.) with the world of cryptographic agility and compliance. They ensure that as we harden our supply chains, we’re not overlooking the critical security foundation that is cryptography.

Maintaining CBOMs Across the Software Lifecycle

Creating a CBOM is not a one-time task – maintenance is key. Cryptographic Bills of Materials should be treated as living documents (or data sets) that evolve with your software. Here are practices and considerations for CBOM maintenance:

• Version Control and Change Tracking: Just like source code, CBOMs benefit from version control. Storing CBOM files in a repository (or an artifact management system) allows you to track how the cryptography in a project changes over time. Each release or build can have an associated CBOM file. Using diff tools (CycloneDX has BOM diff capabilities) or even simple JSON diffs, you can detect changes: Was a new algorithm introduced? Did a key length change? Was a library upgraded or removed? These changes can be significant. For example, if a diff shows that since last release, a developer added MD5 usage (perhaps via a new dependency), that’s a red flag to be addressed. Conversely, if a diff shows an old SHA-1 usage was replaced with SHA-256, that’s progress to be documented. By keeping CBOMs in version control, you create an audit trail of cryptographic decisions and modifications. This also helps during compliance audits – you can demonstrate not just a snapshot, but your historical diligence (e.g., “We eliminated all DES usage by Q4 last year, see the CBOM diffs confirming it”). Automated pipelines can even fail a build if an unauthorized change is detected in CBOM (for example, a policy could be encoded as “CBOM must not include algorithm X; if present, fail the build”).
• Continuous Vulnerability Correlation: Maintaining CBOMs means you can continuously cross-reference them against vulnerability feeds. For instance, consider integrating CBOM data with your vulnerability management process. When new crypto-related CVEs or weaknesses are announced (or new deprecations by standards bodies), you can search your library of CBOMs to find affected systems. This is analogous to how organizations use SBOMs to find components with Log4j or other issues. In fact, the ReversingLabs Spectra platform indicates they produce risk assessments alongside SBOM/CBOM to highlight malicious or vulnerable components. You could implement an internal script: e.g., input the name of a vulnerable algorithm and output all CBOM files (hence all products) where it appears. The maintained CBOM repository thus becomes a powerful knowledge base. For example, if tomorrow a weakness in RSA-2048 is publicized, a maintained CBOM repo lets you identify every product, version, and possibly subsystem that uses RSA-2048, so you can prioritize each for mitigation or customer notification.
• Periodic Reviews and Updates: Even if your CI pipeline generates CBOMs, it’s wise to periodically review them with a human eye (or a designated Crypto Steward role in the security team). Perhaps once a quarter or at major releases, someone should sanity-check the CBOM for anomalies. Are there any unknown entries (meaning the scanner found something but wasn’t sure what it is)? Are all entries expected? If something unexpected appears (like a cipher you didn’t think was in use), investigate and update documentation or address if it’s undesired. Additionally, if certain crypto uses are meant to be temporary, a review ensures they aren’t forgotten. For example, maybe a product enabled TLS 1.0 for a legacy client – the CBOM will show it; a review can catch that and prompt engineering to remove it once no longer needed. Essentially, CBOMs should be part of the security review checklist at each release, ensuring cryptography changes undergo scrutiny just like code changes do.
• Governance Integration: At a higher level, maintain a process where CBOMs feed into governance dashboards or risk scorecards. Some organizations might quantify cryptographic risk (e.g., scoring systems higher that have any deprecated crypto). With regular CBOM updates, you could have metrics like “Percentage of applications using only NIST-approved crypto” or “Number of systems still using RSA or ECC (quantum-vulnerable)” and track those over time as a governance KPI. One can even assign risk owners to crypto findings – e.g., the presence of an expired certificate in a CBOM is assigned to the ops team for immediate fix. Because CBOMs align with compliance requirements, maintaining them helps with audits: you can prove cryptography is managed. If an auditor asks “how do you ensure no weak crypto?”, you produce the CBOM process and logs.
• Lifecycle of Keys and Certs: Maintenance also means updating the CBOM when cryptographic assets themselves change in the field. For instance, if a certificate gets renewed or a key is rotated, the CBOM for the next version should reflect the new cert or key parameters. But what if the software is already deployed? This is interesting – SBOMs/CBOMs usually describe what’s built into the software, but keys and certs might be deployed or configured in production. It could be beneficial to update CBOMs (or a separate operational CBOM) when such changes occur. Some teams might maintain a separate inventory for deployed instances (especially for things like which certificates are installed on which server). If using infrastructure-as-code or configuration management, it might be possible to generate a CBOM-like report of actual deployed cryptographic material. This ensures that maintenance covers not just the development artifact but the runtime reality. In any case, the ideal state is that any cryptographic change – whether in code or config – triggers an update to the inventory.
• Tool Updates: As CBOM practice is new, maintain awareness of tool and spec updates. CycloneDX may release further enhancements (e.g., CycloneDX 1.7 or beyond might refine the CBOM fields). Tools you use might improve detection (reducing false unknowns, covering more languages). Regularly update these tools to benefit from better accuracy. Also, keep an eye on integration into mainstream security tools (for example, if your SCA tool starts offering cryptography analysis, you’d want to incorporate that). Since CBOM generation is code/dependency heavy, build engineers and DevOps should treat the CBOM tooling like any build dependency – pin versions, update when needed, and ensure it doesn’t break the pipeline on upgrades.
• Security of the CBOM Data: One consideration when maintaining CBOMs is that they contain sensitive information (by nature, since cryptographic details are sensitive). A CBOM could potentially list secret material (though private keys should ideally just be indicated as present, not reveal the key!). Still, even knowing what algorithms or certs you use could aid an attacker (it’s akin to an attacker reading your SSL config). Thus, guard your CBOM files appropriately: limit access to those who need it, and if sharing with external parties, consider redacting or excluding actual secret values. The CycloneDX standard is mostly about metadata (it doesn’t include actual private key bytes or anything), so it is safer, but an operational CBOM might accidentally include things if not careful. Treat CBOMs with a similar sensitivity as SBOMs or architecture docs – useful for defense but also something you wouldn’t want widely exposed. Some data might even be classified (e.g., if it details cryptography in a sensitive government system). Thus, maintenance includes access control and proper handling of these artifacts within your organization’s information security policies.

In summary, maintaining a CBOM is about keeping the crypto inventory current and usable. Think of it as analogous to maintaining source documentation or threat models – it’s not set-and-forget. The value of a CBOM is highest when it reflects the present state of the software; stale CBOMs are of little use. Therefore, integrate CBOM updates into every code change or release process. And use the historical record from those updates to inform future design and risk decisions. Over time, you’ll likely find that maintaining CBOMs becomes a natural part of the development workflow, and the payoff is a far more proactive cryptographic posture with fewer surprises.

Conclusion

Cryptographic Bills of Materials (CBOM) represent the next evolution in software transparency and security risk management. As we have explored, a CBOM provides deep visibility into an application’s cryptographic underpinnings – an area that has often been opaque to security teams. By enumerating algorithms, keys, certificates, and their usage, CBOMs empower organizations to tackle challenges ranging from quantum cryptography transition and legacy crypto cleanup to regulatory compliance and rapid incident response to crypto vulnerabilities.

For security architects and CISOs, adopting CBOM practices offers actionable benefits. It means no longer relying on ad-hoc methods or tribal knowledge to answer “What crypto are we using in our products?” Instead, you have a ready inventory to consult or share with stakeholders. It means being prepared for mandates (like those from OWASP, NIST, CISA, ETSI, etc.) that increasingly require demonstrating control over cryptography. And importantly, it means reducing risk: weaker algorithms are identified and phased out, certificate and key issues are caught early, and a clear roadmap exists for embracing new standards like post-quantum algorithms.

Implementing CBOM will take some effort – tooling needs to be integrated, developers educated, and processes adjusted – but it can be done incrementally. Start by generating a CBOM for one critical application as a pilot. Use it to drive remediation of any findings (you may discover an outdated crypto library or an unnecessarily enabled cipher). Then expand the practice portfolio-wide. Leverage the standards and community tools discussed: CycloneDX’s spec and guides, IBM’s open tools, and others. These will accelerate your adoption.

Finally, keep in mind that a CBOM is not just a technical artifact, but a communication tool. It enables better communication between development, security, and compliance teams (“here is exactly how we implement cryptography”), and between software producers and consumers (as part of transparency efforts). Much like SBOMs have started to foster trust in software supply chains, CBOMs can foster trust in the security of the cryptography that underpins our digital ecosystem. In a future where algorithms can suddenly become obsolete (e.g. under quantum threats) or banned by policy, having this detailed insight readily available will be invaluable.

In conclusion, Cryptographic BOMs help ensure that our security foundations are as robust and well-managed as the software they protect. By adopting CBOMs, organizations put themselves on a strong footing to navigate the evolving cryptographic landscape with agility and confidence – turning what could be hidden liabilities into transparent, manageable assets.