Challenges with SBOMs and current CBOMs
CBOMs inherit the benefits and the limitations of software bills of materials, and introduce further difficulties specific to cryptography. These constraints are the primary motivation for a profile-based, format-independent methodology.
Lessons from SBOM adoption
Three properties have consistently distinguished successful SBOM deployments from difficult ones. Each applies equally to CBOMs in a multi-vendor environment.
| Lesson | Problem observed | Implication for CBOMs |
|---|---|---|
| Harmonization | A proliferation of vendor-specific formats and delivery methods prevented reconciliation at scale. | Agree how attributes are expressed, rather than mandating one format. A profile states what must be disclosed, and a mapping fixes how each attribute is encoded in each format, so several formats can coexist and still be reconciled. |
| Profiling | Exhaustive coverage is not necessarily useful coverage; a large number of entries obscures those relevant to a decision. | Define a minimum, purpose-specific subset of attributes for each objective. This is the function of a profile. |
| Sequencing | The published minimum elements were read as a ceiling rather than a floor. Producers met the minimum and stopped, and consumers had no basis for asking for more, because nothing in the minimum said what came next. | A CBOM profile that asks for part of the picture has to attach an obligation to the part it defers, or the first stage becomes the permanent answer. Stating that a deferred subject is out of scope costs a producer nothing and tells a consumer nothing; requiring a one-word status for it costs almost nothing and tells them where the work stands. |
| Normalization | Different producers represent the same value differently, which prevents automated processing. | Agree identifiers (syntactic normalization) and attribute meanings (semantic normalization) so that CBOMs can be compared. |
Harmonization is worth stating carefully, because it is often read as a requirement to adopt a single format. That is neither achievable nor necessary. Organizations have existing commitments to CycloneDX or SPDX, regulators and customers ask for different things, and the formats themselves continue to change. What has to be consistent is the information: which attributes are disclosed, and where each one sits in a given document. That is the work a profile and its mapping do. The profile is written once, independently of any format, and a mapping is defined for each format it needs to support. A consumer can then reconcile CBOMs from several formats, and a producer is not forced to abandon the format it already uses. Consistency is achieved through agreed encoding rather than through a single target format. See Formats.
This is also the position taken by the 2026 minimum elements guidance, which states that minimum support for automation means supporting all data formats that are widely used, open source, and compatible with existing formats, and that the set of supported formats should be reassessed periodically. Both SPDX and CycloneDX are named. A consumer is therefore expected to handle more than one format, which is the condition a profile and its mappings are designed to serve. See References.
Coverage is a separate question from attribute selection, and the two are sometimes confused. The same guidance requires an SBOM to include all components of the target software, including transitive dependencies, and states that there is no minimum depth. That is a floor for which components appear and which elements each carries. A profile does something different: it states which attributes are mandatory for a stated purpose. It does not license omitting components. The worked example on this site behaves accordingly: it judges the interfaces a product declares and says nothing about the other entries a production CBOM would contain.
Challenges specific to CBOMs
In addition to the properties inherited from SBOMs, cryptography introduces difficulties that current standards address only in part. As noted above, this reflects the position at the time of writing.
1 · No first-class model for relationships (the edge gap)
Current CBOM standards model cryptographic assets (algorithms, keys, certificates, protocols) as nodes, but provide no object that represents the relationship: the point at which cryptography is applied between two parties. A TLS connection is a location at which assets are used rather than an asset in itself. Classifiers that belong to the connection itself, such as the endpoint roles of a specific session, are consequently attached to a protocol asset, which represents the edge as though it were a node.
2 · Cryptographic coverage differs between the formats
SPDX 3.0.1 has no dedicated cryptographic model equivalent to the one in CycloneDX, so organizations that standardize on SPDX today usually pair it with a CycloneDX-format CBOM referenced as a linked artifact. That works, but it leaves CBOM interoperability resting on one format.
This is changing. SPDX is adding a cryptographic object model, and once it is available the linked-artifact pattern becomes a choice rather than a necessity. For this methodology, the profile does not change when that happens; only the SPDX column of the mapping does. Readers should confirm the current state of both specifications rather than relying on the position described here. See Formats.
3 · Inconsistent algorithm naming
Deployments have shown the same algorithm expressed in several forms (AES256, AES-256-GCM, AES_256_CBC), which impedes policy enforcement and cross-organization analysis. The CycloneDX 1.7 Cryptography Registry provides stable identifiers to address this; CBOMs authored to earlier versions carry free-text names and require normalization on ingest. See Versioning.
4 · Multiple valid encodings of the same information
Both CycloneDX and SPDX permit the same cryptographic information to be encoded correctly in more than one way. A given fact (for example an algorithm reference, a protocol version, or the association between a certificate and its signature algorithm) may be represented in different but equally valid locations or structures within a single document. A consumer that must accept any valid encoding has to implement and maintain parsing logic for each variant, which increases complexity and the risk of inconsistent interpretation.
The mapping component of this project addresses this by defining a single, canonical encoding for each profile attribute in each format. When producers follow the mapping, a consumer extracts the information a CBOM requires from one defined location rather than several, which reduces parsing complexity and improves consistency of interpretation. Normalization of encoding is complementary to normalization of naming (item 3): the former concerns where and how a value is represented, the latter concerns the value itself. See Formats.
5 · Ambiguity of lifecycle and state
The statement that a product uses a given algorithm admits four distinct meanings: the algorithm may be intended in the design, implemented in the binary, configured in a deployment, or observed on the wire. A vendor's build-time CBOM and an operator's runtime scan may legitimately differ. Without an explicit lifecycle indicator, a consumer cannot distinguish capability from actuality. See Lifecycle Data.
6 · Depth of disclosure
Excessive reporting reduces the value of the data and may expose intellectual property, while insufficient reporting conceals risk. A tension exists between operational utility and legitimate vendor confidentiality. A well-defined profile establishes a lower bound that prevents underreporting while limiting the scope of required disclosure.
There is a third force, and it is the one most often missed: time. A supplier able to answer everything a mature profile asks for is rare at the start, and a profile pitched at what suppliers can produce today will still be pitched there in three years. So depth is not only a question of how much to ask, but of how to ask for more later without either freezing the current answer or making the first request unanswerable. That is the sequencing lesson above, and it is why a profile that defers a subject should still require a statement of where that subject stands.
7 · Supplied, withheld, unknown and undeclared are four different things
Most CBOM tooling treats an attribute as either present or missing. That collapses four situations a consumer needs to tell apart: the producer holds the information and supplied it; the producer holds it and is withholding it under a confidentiality policy; the value is unknown to the producer; or the attribute is undeclared, with neither a value nor any marker saying which of the other cases applies.
The distinction changes what a consumer should do. An unknown value points to a limitation in the producing process and may justify improving tooling or discounting the result. A withheld value is a policy decision, and the consumer knows the information exists and could be released under other terms, such as a non-disclosure agreement. Reporting both as an empty field loses that difference, and in procurement it misrepresents the supplier: a vendor whose scanner cannot see hardware cryptography is not in the same position as one that has chosen not to publish a library version.
Undeclared is the fourth case and the one most easily overlooked, because it looks identical to the others in a document that carries no markers at all. It means the document was not built against the profile: the producer never addressed the attribute, so nothing can be inferred about whether the information exists. The 2026 minimum elements guidance requires an SBOM author to state whether missing information is unknown or withheld, treating it as a practice maintained across the SBOM lifecycle rather than a single data field, and the fourth outcome is what remains when the author has not done so. Neither CycloneDX nor SPDX has a native field for this, so it falls to the mapping to fix a convention. The four outcomes and their effect on a verdict are set out in Conformance, where distinguishing them is a MUST on any evaluation tool. This connects to redaction, described in the Inventory section, where a CBOM extracted for an external party is deliberately reduced.
8 · Tooling coverage and confidence
Automated tools may fail to detect cryptography that is dynamically loaded, configuration-driven, or provided by hardware. The reliability of a CBOM is limited by the process that produces it; provenance and, where feasible, signing are therefore important, and the confidence attached to a CBOM depends on the lifecycle phase at which it was captured.
9 · Linking cryptography to its environment
Knowledge that a system uses a given algorithm is incomplete without the version of the library that implements it, which determines whether modes such as hybrid key exchange are available, and without knowledge of whether execution occurs in software, in a Hardware Security Module, or in a Trusted Execution Environment, the last of which may require hardware replacement rather than a software update. CBOMs are therefore produced and consumed alongside SBOMs, and in some cases Hardware Bills of Materials. The linkage between these artifacts is not yet mature.
10 · Versioning and legacy artifacts
Standards are revised (CycloneDX 1.6 to 1.7), profiles are tightened, and a product's CBOM is regenerated over time. Treating "older" as a single concept produces incorrect verdicts; the three version axes must be handled explicitly. See Versioning.
11 · Identifying the same asset across different tools
An inventory is assembled from several sources: a vendor CBOM, a build-time scan, and a runtime discovery tool. Each names things in its own way, and for some classes of asset there is no agreed name at all. Where two records cannot be shown to describe the same asset, the inventory either counts one asset twice or merges two distinct assets into one, and neither error is reported by the process that produces it.
The difficulty is not uniform across asset classes. Some have an established identifier and require only that producers use it; others have none.
| Asset class | Identity available today | Assessment |
|---|---|---|
| Software components | Package URL, and formerly CPE | Workable. Baseline rule I9 already requires the pkg: form for the implementing library. |
| Certificates | SHA-256 fingerprint of the DER encoding, or issuer and serial number | Workable, though tools disagree on which of the two to use, so a consumer may hold two records of one certificate. |
| Keys | No agreed identifier | The hard case. A public key can be thumbprinted; a private key held in a hardware module has only a local label or handle; and the same key material present in a module and in a backup is genuinely ambiguous. |
| Algorithms | Registry identifiers, of which several compete | An open question, and the subject of item 3 above. |
| Interfaces | interfaceId, chosen by the producer and unconstrained by design | Undefined across documents. Nothing connects an interface record in one document to an interface record in another. |
The interface row is a consequence of a deliberate decision. The profile does not constrain interfaceId, so that profiles remain independent of any product's internal naming, and the cost of that independence is that the identifier carries no meaning outside the document containing it. A consumer should treat it as a label rather than as a stable cross-organization identifier. See Formats.
Correlation has to hold across tools and also across time. An inventory that cannot determine whether today's record describes the same interface as last quarter's cannot report migration progress, which is one of the stated use cases. The same requirement applies to any attempt to link several CBOMs into a picture of a deployment, because the linkage is expressed between identified assets. What an inventory does about all of this — choosing a join key per class, recording the basis of a merge, and constructing a stable key for interfaces — is in Inventory. This section owns the taxonomy; that one owns the practice.
The profile mechanism provides a partial remedy. A profile can require a particular identifier form, which is what baseline rule I9 does by requiring a pkg: Package URL for the implementing library. Generalized, identity requirements are a profile concern, and a profile intended to feed an inventory states which identifier form it requires for each asset class it covers. That converts a problem with no general solution into a decision taken once per profile. As with the other items in this section, the position described here is the position at the time of writing, and identifier schemes for the classes that lack one may yet be defined.