Include Syft's cyclonedx component properties in Grype output

[cjnosal]

What would you like to be added:
Syft's cyclonedx output was improved in anchore/syft#710.
I would like Grype to offer the same level of detail as Syft.

Why is this needed:
The current cyclonedx or vex outputs don't contain full information to aid in triage. I need to cross-reference grype cyclonedx against syft json to find additional metadata (e.g. file path containing a go module, which syft encodes as properties).

Additional context:
Syft component encoding:
https://github.com/anchore/syft/blob/main/syft/formats/common/cyclonedxhelpers/component.go#L30

Grype:
https://github.com/anchore/grype/blob/main/grype/presenter/cyclonedx/document.go#L48
https://github.com/anchore/grype/blob/main/grype/presenter/cyclonedxvex/document.go#L67

[kzantow]

Hi @xtreme-conor-nosal -- is the main gist of this ask to be able to match Grype CycloneDX results against elements in a Syft SBOM? In other words: if we added a file path would this allow you do do what you need -- or could there be a package ID that matches, which might be easier?

[cjnosal]

Using syft $image -o cyclonedx as a baseline, I would like syft $image | grype -o cyclonedx or grype $image -o cyclonedx to have at least as much detail about each component.

If I run grype -o cyclonedx and want to know why e.g. there's two copies of a package, I need to context switch, run syft against the same image, and search for the package name to see that the package is part of two binaries in my image. If grype surfaced the same information, it can save me a step as I triage each result.

[kzantow]

Thanks @xtreme-conor-nosal, so if only the location information was included in the Grype output, would that be sufficient for your use case here? I ask because that would be a fairly simple change to make, whereas including all the properties would be a much bigger lift.

[cjnosal]

Yes, having location would be a good first step.

[cjnosal]

Given Grype has the two use cases of generating the sbom internally via Syft vs reading an sbom from stdin (that may or may not come from Syft), what do you think about a second ticket for preserving any extra properties that appear in a provided sbom (in addition to this ticket focusing on properties generated by Grype)?

[kzantow]

This might be tricky to do... for CycloneDX -> CycloneDX it might be fairly straightforward, but mapping other arbitrary properties between formats might be a lot more work to determine where to put said properties.

[cjnosal]

Yeah, I was thinking it might need to be constrained to the cases where the input and output formats match, and even then could represent a sizeable code diff.

[cjnosal]

A second field that might be worth prioritizing is purl. Where package names from different ecosystems collide the type is a useful disambiguator, with the advantage of being a cyclonedx spec field (compared to the syft:package:* properties)

[spiffcs]

Hey @xtreme-conor-nosal check out #1038 and the enhancements made there. Using grype standalone now should give you the same output as if you had used syft. We updated grype to just consume our formatting library from syft.

If you have questions, comments, or improvements let me know and I can follow up!