Backward compatibility: the CycloneDX 1.5 metadata->tools case about specification

[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.

[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: aquasecurity/trivy#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

[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?