CycloneDX / CycloneDX/specification
Backward compatibility: the CycloneDX 1.5 metadata->tools case
- 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
Assessment
This issue has not been assessed yet.