CycloneDX / CycloneDX/specification

Backward compatibility: the CycloneDX 1.5 metadata->tools case

Open
#364 6 comments 0 reactions 0 assignees View on GitHub
question
Dominant language
XSLT
Stars
547
Forks
93
Avg merge
7h 11m
Merged PRs (30d)
37

Description

Hi,

There is already an ecosystem of tools that are starting to break due to "breaking changes";
Take for exmple the Tools section.
Syft produces the 1.5-introduced object:

"metadata": {
"timestamp": "2024-01-21T08:54:33+02:00",
"tools": {
"components": [
{
"type": "application",
"author": "anchore",
"name": "syft",
"version": "0.100.0"
}
]
},
But tirvy fails on the decoding:
```
2024-01-21T08:56:33.671+0200 FATAL sbom scan error: scan error: scan failed: failed analysis: SBOM decode error: failed to decode: CycloneDX decode error: CycloneDX decode error: json: cannot unmarshal object into Go struct field Metadata.metadata.tools of type []cyclonedx.Tool
```
Removing the ```tools``` section from the meta-data enables Trivy to do it's magic.
Although this deserves fixing Trivy, Trivy could work on both cycloneDX 1.4 and 1.5 had this change not been introduced in this way.

My personal view it that the tools section does not justify to introduce a breaking change; one could add a bom-ref field to the existing object, and if someone wants to describe the tool as a component - he can add a component and have the tools object point to it.

I recommend trying super-hard to preserve backward compatibility.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.