Add CycloneDX read SBOM hook implementation#221
Conversation
…RICS observations
for more information, see https://pre-commit.ci
…ations' of https://github.com/LLNL/Surfactant into CYT-615-Add-SPDX-and-CycloneDX-read_sbom-hook-implementations
for more information, see https://pre-commit.ci
…ations' of https://github.com/LLNL/Surfactant into CYT-615-Add-SPDX-and-CycloneDX-read_sbom-hook-implementations
for more information, see https://pre-commit.ci
…ations' of https://github.com/LLNL/Surfactant into CYT-615-Add-SPDX-and-CycloneDX-read_sbom-hook-implementations
…k-implementations
|
In the CyTRICS schema working group I was thinking that it would be nice to be able to track what CycloneDX/SPDX identifier is associated with software entries, which would enable SBOM conversion to preserve a stable identifier for a roundtrip conversion from CycloneDX -> CyTRICS/internal -> CycloneDX. https://cyclonedx.org/capabilities/bomlink/ has an example of what a full ref looks like. |
…RICS observations
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…k-implementations
🧪 SBOM Results (15/15)
|
|
Some notes: |
Latest working draft of the CycloneDX input SBOM hook.
This includes adding any vulnerabilities from the CycloneDX SBOM into the observations section of the CyTRICS SBOM
Change in mapping requirements: It turns out that a CycloneDX component can have nested subcomponents. Mapping these subcomponents to the components section of the CyTRICS software entry format would fit better than mapping the CycloneDX services section to the CyTRICS components section since CycloneDX services are it's won section in the SBOM (rather than being part of individual CycloneDX component entries)
Some CycloneDX-exclusive component data is currently added to the metadata section of the corresponding CyTRICS software entry, while the rest needs to be transformed into formats that are JSON-serializable