CBOM: Add CycloneDX v1.6 support for cryptographic assets

[stevespringett]

Current Behavior

Currently, Dependency-Track does not support cryptographic assets.

Proposed Behavior

Add support for cryptographic assets and their dependencies once CycloneDX v1.6 is released.

• Display cryptographic assets in inventory
• Display cryptographic assets in dependency graph
• Display cryptographic-specific fields in component view and modal dialogs
• Add support for dependency types (display on dependency graph)

NOTE: May be able to reach out to IBM Quantum for a git patch or PR, as they've performed an internal fork of DT that adds support for some of these things already.

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[n1ckl0sk0rtge]

@stevespringett @VinodAnandan could you assign this issue to me, would like to work on it.

FYI @san-zrl

[dshafranskiy-r7]

@n1ckl0sk0rtge do you have any ETA on that feature being implemented ?

[n1ckl0sk0rtge]

Hi @dshafranskiy-r7, not yet, but we are working on it, see

• feat: CBOM support
• feat: render CBOM data

Together with the Dependency Track maintainers, we decided to implement this feature for Dependency Track 5.x.

[dstuart]

Will this make it into Track 5 or do you think it will be pushed out.

[san-zrl]

@dstuart - Without additional work they will probably be pushed out. When we submitted the PRs two issues were criticised.

1. CBOM UI: Cryptographic properties should be read-only. DT is a tool for authoring SBOMs and thus all SBOM properties (licenses etc.) can be modified via the UI. Since we extended the UI based on the existing widgets CBOM data is also editable. This is error-prone, and it should not be possible to manually change the cryptographic posture of packages.
2. Backend: Cyclone DX CBOMs may contain many properties of type bom-ref. These are unique identifiers that represent references to other components of the BOM. Examples for such bom-refs are the links to the signature algorithm and the subject’s public key in certificate properties. The internal data model keeps them in their UUID-based raw form and does not resolve them to pointers to the CBOM object they refer to. This also shines through in the UI.

[dstuart]

Thanks @san-zrl,

Ok, I might apply the patches to a 5 instance and have a play as neither of the two items above seem like blockers for my use case and might be able to help out in some way (even if its just testing).

Thanks for your (and others) work on this very valuable in supporting our Y2Q efforts