Hi folks,
currently the json output of Grype includes useful metadata missing from the CycloneDX-json format, namely:
- is fix available for the package
- was the match direct or indirect (based on package name or upstream name)
In the json format this can be found in the vulnerability.fix and .matchDetails fileds of a match. In CycloneDX-json format, custom metadata can be added to the properties field (Syft makes use of this to store e.g. syft:package:type).
So I wanna ask how do you feel about adding this metadata to Grype’s CycloneDX-output. The metadata must contain strings only, so structured output could be stringified. I want to hear your thoughts on this change.
I think adding information to help consumers would be valuable. About the specifics: I think the fix version could be inferred from the vulnerable range(s) if we added that, would that work? I realize this might require a bit of parsing, but we also might have multiple fix versions so outputting these would similarly require at least some processing to split a list or collect multiple property entries.
Regarding direct vs indirect, I don’t see a more appropriate spot for this in the CycloneDX model. One of the things I’m interested to understand is what the best representation of the match details is; I’d like to understand why you specifically asked about this property and not other match details?
Adding vulnerable ranges would work. Following the standardized SBOM fields is a better approach than adding custom properties. The ranges should be specific to a given package on a given software distribution (e.g. Debian 10), so I don’t expect there to be more than one vulnerable range in most situations.
I specifically asked about direct/indirect match to separate direct matches from matches based on the upstream package as discussed here. It would help us to filter out matches with less confidence. We could stringify the whole match details object and put it into a single property to include everything, but I have only use case for that one specific field.
Could you add a Grype issue for adding the CycloneDX vulnerable ranges? I didn’t see one with a quick search; this is definitely something that seems like we could add. There are many vulnerabilities that end up being fixed in different versions, for example Java might fix a bug in 8.0r245 and 21.0r193 etc. we end up showing all these versions in the table but suggest the closest one visually in the table output, but cyclonedx would just end up having all these potential upgrades and potential downgrades – e.g. if you’re at 21.0r192, the potential fix would be to downgrade to 8.0r245 in this fictitious example. Maybe the details will take a little discussion, but given it’s in the spec, we should support it with the data we have.
One thing we want to add is a confidence value – the indirect match would end up being a lower confidence value, for example. Maybe it’s time to explore adding this? This isn’t exclusive to adding match details to CycloneDX somehow. Could you add a separate issue for this? I think adding these to the properties would include the fact it’s an indirect match, we can talk about the details in the issue there, too (maybe the tools section would be more appropriate?)
Let’s continue the discussion on GitHub:
1 Like