Aspect
Section: 3.8 Relationship to other inventories and layering
Orientation relevance: both
A cryptography report doesn't stand on its own — the cryptography lives inside software (described by a "Software Bill of Materials," or SBOM) and sometimes inside hardware (a Hardware Bill of Materials, HBOM). This issue is about how a profile connects the cryptography to the software or hardware it belongs to, without wastefully copying all that information twice.
Example
A library book has a catalogue entry (think: the software/SBOM) and, separately, a note about the language it's written in (think: the cryptography/CBOM). Rather than repeat the whole catalogue entry, the language note just points to it by its catalogue number. We're deciding how a cryptography report points to its software and hardware instead of duplicating them.
Objective
Decide how a profile expresses the relationship between cryptographic assets and the software
and hardware that use them, including links to an accompanying SBOM and, where relevant, HBOM.
Background & links
Scoping document §3.8. A CBOM is rarely used alone; its value depends on being relatable to
the components it describes. References: SBOM/CBOM relationship; purl / BOM-ref for component
identity.
Options under consideration
- Reference, don't duplicate — the CBOM links to SBOM/HBOM components by identifier
(purl / BOM-ref); component detail stays in the SBOM/HBOM. (Trade-off: clean separation;
requires the linked artifacts to be present.)
- Limited duplication — allow key component attributes to be carried in the CBOM for
standalone use. (Trade-off: usable alone; risk of drift between artifacts.)
Open questions
Dependencies
Depends on attribute model (3.3 #1); coordinates with normalisation (3.7 #3) on
identifiers.
Decision
Not yet decided.
Impact on the specification
Spec section "Relationship to SBOM/HBOM and layering."
Aspect
Section: 3.8 Relationship to other inventories and layering
Orientation relevance: both
A cryptography report doesn't stand on its own — the cryptography lives inside software (described by a "Software Bill of Materials," or SBOM) and sometimes inside hardware (a Hardware Bill of Materials, HBOM). This issue is about how a profile connects the cryptography to the software or hardware it belongs to, without wastefully copying all that information twice.
Example
A library book has a catalogue entry (think: the software/SBOM) and, separately, a note about the language it's written in (think: the cryptography/CBOM). Rather than repeat the whole catalogue entry, the language note just points to it by its catalogue number. We're deciding how a cryptography report points to its software and hardware instead of duplicating them.
Objective
Decide how a profile expresses the relationship between cryptographic assets and the software
and hardware that use them, including links to an accompanying SBOM and, where relevant, HBOM.
Background & links
Scoping document §3.8. A CBOM is rarely used alone; its value depends on being relatable to
the components it describes. References: SBOM/CBOM relationship; purl / BOM-ref for component
identity.
Options under consideration
(purl / BOM-ref); component detail stays in the SBOM/HBOM. (Trade-off: clean separation;
requires the linked artifacts to be present.)
standalone use. (Trade-off: usable alone; risk of drift between artifacts.)
Open questions
Dependencies
Depends on attribute model (3.3 #1); coordinates with normalisation (3.7 #3) on
identifiers.
Decision
Not yet decided.
Impact on the specification
Spec section "Relationship to SBOM/HBOM and layering."