Grype appears to be writing v1.6 spec cyclonedx files that grype itself cannot read (affects 0.79.0+)

[ragaskar]

What happened: After updating to grype 0.79.1 which now emits v1.6 spec cyclonedx-json (and cascading that spec change down through all our internal utils that deal with cyclonedx and needed the cyclonedx-go library bumped to latest), I discovered that grype was unable to process a file itself had emitted (we scan artifact bits with syft/grype, emit cyclonedx json and store the result in a database, later retrieving just the SBOM and running grype against that in order to refresh vuln results without a full artifact rescan).

What you expected to happen: I expected grype to be able to process cyclonedx SBOMs it emits. (I also kind of -- maybe unreasonably? -- expected grype to emit an older, more compatible cyclonedx spec format unless/until it needs updated spec features ... but I don't think this is default behavior of the cyclonedx-go lib, so might be kind of tricky -- and is certainly more feature request, less bug ;). Also I guess not sure how much of this is on the syft side vs grype side? 🤷 ).

How to reproduce it (as minimally and precisely as possible): grype alpine -o cyclonedx-json > /tmp/grype-out.json && grype /tmp/grype-out.json -o cyclonedx-json

which w/ 0.79.1 results in (on my darwin arm machine):

❯ grype alpine -o cyclonedx-json > /tmp/grype-out.json && grype /tmp/grype-out.json -o cyclonedx-json
 ✔ Vulnerability DB                [no update available]
 ✔ Loaded image                                                                                                                                                                                                                alpine:latest
 ✔ Parsed image                                                                                                                                                      sha256:442043f030d33ff05cf2b6dcb64a3948ce38f2663d146558281a828d78eae5fd
 ✔ Cataloged contents                                                                                                                                                       8946eb426fbf9ed6260ee859e60462b834c8d1d50349f15e73aa17928f7991e8
   ├── ✔ Packages                        [14 packages]
   ├── ✔ File digests                    [77 files]
   ├── ✔ File metadata                   [77 locations]
   └── ✔ Executables                     [17 executables]
 ✔ Scanned for vulnerabilities     [8 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 6 medium, 0 low, 0 negligible (2 unknown)
   └── by status:   8 fixed, 0 not-fixed, 0 ignored
 ✔ Vulnerability DB                [no update available]
failed to catalog: unable to decode sbom: sbom format not recognized

0.79.0 is similarly affected, 0.78.0 works as expected (emits an SBOM vs. throwing an error re: SBOM decoding).

Anything else we need to know?: Affects 0.79.0 and 0.79.1 (the move to cyclonedx-go 0.9.0 occurred in 0.79.0). I suspect (but haven't dug into it much yet) that the problem lies in the internal cyclonedxutil lib, which doesn't seem to have any references to the 1.6 spec and appears to be involved in the SBOM decoding workflow.

Thanks for all your work on grype!!!! It's a great tool! Hopefully I'm not coming off too salty in this issue, but I admit I am a bit bummed to have updated libs across our toolchain to achieve 1.6 cdx compatibility just to run into this blocker. :) I guess in the near-term I can pin back to 0.78.0 and at least internally we're up-to-date cyclonedx spec-wise now :)

Environment:

• Output of grype version: grype 0.79.1
• OS (e.g: cat /etc/os-release or similar): OSX Sonoma 14.4 M1, also observed on alpine (where we run our jobs).