search

anchore / syft

CLI tool and library for generating a Software Bill of Materials from container images and filesystems
Apache License 2.0
5.73k stars 526 forks source link

Add CycloneDX 1.6 Support #2974

Closed ashearin closed 1 week ago

ashearin commented 1 week ago

What would you like to be added:

Support for CycloneDX 1.6 Specification.

Why is this needed: Teams and Tools that leverage Syft as part of the SW supply chain security have a need for the additional fields and to avoid compatibility issues when working with sboms

Additional context: The underlying go library used for cyclonedx has added support for 1.6 (as of v0.9.0) and is already in use with syft as of this PR.

ragaskar commented 1 week ago

This is related to https://github.com/anchore/grype/issues/1951, as grype appears to be using the syft internal cyclonedxutil decoder for decoding. ... I may take a shot at PR-ing a fix this evening, let me see if I have enough time.

ragaskar commented 1 week ago

Just a quick note after digging into syft. I now believe I'm incorrect about this being the root issue behind my particular problem. It's very related in the sense that if someone updated the list of supported cyclonedx versions to include 1.6 in syft my problem would go away -- for now ... but the core problem seems to be that grype, when it emits an SBOM is simply calling cyclonedx.NewBOM, which uses the latest available cyclonedx SpecVersion by default, whereas syft (very reasonably, imo!) has their own internal list of default + supported versions.

I'd like to fix both problems and not run into the grype problem again when cyclonedx spec 1.7 comes out, so I think I might start over there.

ragaskar commented 1 week ago

OK, that one looks ready for review.

An update on my goal of avoiding sbom generator surprises around cdx spec versions: 1) I was incorrect about how the DefaultVersion constant I saw worked. It looks like syft is configured to pick the latest available spec version (for formats for which syft supports "all versions"). 2) I think grype just unintentionally uses latest (via calling cyclonedx.NewBOM() and not using the EncodeVersion to select a specific output version) to emit. That said, after beginning to get my head around how syft encoding/decoding works, I'd suspect I should take another look at grype to see if I correctly understood the flow -- perhaps grype accepts similar configuration and there is a near-term workaround if you don't want 1.6 (beyond just pinning back). 3) For those of us concerned with surprises with backwards incompatible spec versions, syft supports configuring a cyclonedx spec either in a syft config file or by passing a "format@specVersion" pair to the output flag (e.g., -o cyclonedx-json@1.5=some-json-1.5.cdx.json). In some ways this is the best of both worlds, the defaults encourage lib owners to quickly support newer specVersions, but as a user you can protect yourself by locking down to a version (above issue with grype aside).