Show SBOM package IDs in Grype output formats

[luhring]

What would you like to be added:

When scanning an SBOM, Grype's machine-readable output formats should cite the SBOM's ID for any package with a vulnerability match.

Why is this needed:

Without this, it's difficult/impossible to correctly associate Grype's results with the SBOM "source of truth". The ideal use of Grype as a "scanner of SBOMs" is to rely on Grype for the vuln match details, but to rely on the SBOM itself for the package details.

Additional context:

All SBOM formats (including Syft's) have a mechanism of attaching unique IDs to packages. Grype should be able to plumb these values through all the way to its output.

cc: @wagoodman

[tgerla]

Hi @luhring, are you OK if we close this issue now that #1266 has been merged? Thanks!

[luhring]

Hi @tgerla, I just tested with Grype v0.62.2, and I don't think this has been fully implemented yet. #1266 incorporates Syft-format IDs into Grype's own JSON format, which is useful when having Grype scan Syft-format SBOMs, but I think that's all that was achieved in that PR.

This situation might make more sense in table form 🤓 ...

Input SBOM format	ID used in Grype JSON?	ID used in CDX JSON?	ID used in SARIF?
Syft JSON	✅ (b/c #1266)	(If you squint kind of, but technically a ❌ )	❌
SPDX	❌	❌	❌
CycloneDX	❌	❌	❌

The user pain here is that for SBOM-scanning, there's no better source of truth about the software than the SBOM, but in most scenarios (per the above table) Grype is offering no way to be sure which component in the SBOM is being referred to in Grype's vulnerability findings.

All three SBOM formats have reasonably mature ID systems, and Grype users should be able to link back to the software described in their SBOMs via these strong IDs.

Does that help at all?

[jneate]

@luhring I think I've fixed the input CycloneDX -> JSON (bottom left cell in your table) but I can't fully test whether it works for the other columns in the CycloneDX row.

The ID was being extracted in syft but the package ID was not being set, this PR should fix that issue anchore/syft#1872

Or, the entire BOM-Ref field could be set as the artifact ID field?

Looking at SPDX format it raises a similar question:
"SPDXID": "SPDXRef-Package-java-archive-log4j-cc19cc6120e2ffa6",

Would the ID be java-archive-log4j-cc19cc6120e2ffa6 or the final suffix cc19cc6120e2ffa6

[hectorj2f]

Generally I'd expect it to be Package-java-archive-log4j-cc19cc6120e2ffa6 or even SPDXRef-Package-java-archive-log4j-cc19cc6120e2ffa6.