Backward compatibility: the CycloneDX 1.5 metadata->tools case

[dn-scribe]

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.

[jkowalleck]

@dn-scribe , Could you explain what the specific backwards-incompatibility you are referring to?

I mean, every valid CycloneDX JSON document MUST include a specVersion -- trivy could just have implemented a proper check for this, and do the correct deseserialization based on that value, but they decided to not do it...

In terms of a document standard, we do not talk about specific implementations, but about the actual documents. In these terms, for example, it is expected that CycloneDX 1.2 document is also a valid CycloneDX 1.3 document. Not the other way around, nor that implementors do not need to do their job right. ;-)

[jkowalleck]

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.

Looks like trivy does not support all features of CycloneDX 1.5 -- so I'd disagree ;-) But anyway, could you provide an example data set, how this would have been possible, in your opinion?

[jkowalleck]

see also: https://github.com/aquasecurity/trivy/discussions/5976

[dn-scribe]

What I mean by backward compatible: I suppose Trivy does not check the spec version, but it was probably tested on some version - I guess 1.4. They assume that future cdx versions will not break the "basic" use of cdx - to describe software components (Trivy does not care about objects of type data, for example).

Attached is an SBOM generated from syft labeled superset-cdx-original.json, and a patched version ```superset-cdx-patched.json". On the original - trivy fails, on the patched - it passes (also passes if the specVersion and schema are set to 1.4). It also passes if I add to the tools an "externalReference" with a bom-link internal to the document (my understanding of the spec is that this is legal):

{
    "$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
    "bomFormat": "CycloneDX",
    "specVersion": "1.4",
    "serialNumber": "urn:uuid:103c7f88-d7ed-4ab2-bec0-dc7fb3eeb2a6",
    "version": 1,
    "metadata": {
        "timestamp": "2024-01-21T09:20:35+02:00",
        "tools": [
            {
                "vendor": "anchore",
                "name": "syft",
                "version": "0.100.0",
                "externalReferences":[
                    {
                        "url": "urn:cdx:uuid:103c7f88-d7ed-4ab2-bec0-dc7fb3eeb2a6/1/some-bom-ref",
                        "type": "bom"
                    }
                ]
            }
        ],
        

In this way cdx 1.4 could give all the expresiveness of a component to the tools. And when services where added - they would be just another external reference of a tool - the tool section would not need to be updated.

superset-cdx-original.json superset-cdx-patched.json

[stevespringett]

I suppose Trivy does not check the spec version

Likely a bug in Trivy then.

All CycloneDX versions are backward compatible. In this case, the legacy bom->metadata->tools continue to work just fine in v1.5. in fact, we have hundreds of test cases for this very reason.

For example, these two JSON test cases pass validation, and the deprecated one continues to validation in previous versions of CycloneDX, thus ensuring backward-compatibility.

• New tool support in v1.5+
• Legacy tool support

However, CycloneDX is not forward-compatible, meaning that parsing logic only tested for version x, may not continue to work when supporting version y. In order for a tool to support version y, the tool may need to be updated (including parsing logic) to support more recent versions. This is a forward-compatibility issue, not a backward-compatibility one. I'm not aware of any specification that guarantees forward-compatibility.

[dn-scribe]

@stevespringett , what do you think of the suggestion above, that could provide the same values of the new tools section without any change to CycloneDX1.4 ? Could it indeed provide the forward-compatibility, that although no one can commit to, but if gained is great?