Grype not reporting vulns on SPDX SBOMs

[nishakm]

What happened:
Grype was able to catch vulnerabilities when given a CycloneDX SBOM but not for an SPDX SBOM reporting the same package/component.

What you expected to happen:
Grype should be able to report vulnerabilities given an SPDX SBOM which it supports (unless I have misunderstood, in which case, please disregard).

How to reproduce it (as minimally and precisely as possible):
I've attached two SBOM formats reporting the same component json. Grype reports vuln GHSA-4jq9-2xhw-jpx7 and GHSA-3vqj-43w4-2q58 against this component when parsing the CycloneDX SBOM but not the SPDX SBOM.

$ grype component_json.cdx.json 
 ✔ Vulnerability DB                [no update available]  
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]  
   ├── by severity: 0 critical, 2 high, 0 medium, 0 low, 0 negligible
   └── by status:   2 fixed, 0 not-fixed, 0 ignored 
[0000]  WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
NAME  INSTALLED  FIXED-IN  TYPE          VULNERABILITY        SEVERITY 
json  20220924   20231013  java-archive  GHSA-4jq9-2xhw-jpx7  High      
json  20220924   20230227  java-archive  GHSA-3vqj-43w4-2q58  High
$ grype package_json.spdx.json 
 ✔ Vulnerability DB                [no update available]  
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored 
[0000]  WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
No vulnerabilities found

Anything else we need to know?:

Environment:

• Output of grype version:

$ grype version
Application:         grype
Version:             [not provided]
BuildDate:           [not provided]
GitCommit:           07656abef0fcea6540e77e4cfa2981d32c01ceee
GitDescription:      
Author: plavy <[email protected]>
Date:   Tue Jan 16 16:17:17 2024 +0100

    chore(tests): fix logging configuration in tests (#1655)
    
    Signed-off-by: plavy <[email protected]>

Platform:            linux/amd64
GoVersion:           go1.21.1
Compiler:            gc
Syft Version:        v0.100.0
Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar): Ubuntu 22.04 LTS
  component_json.cdx.json
  package_json.spdx.json

[tgerla]

Hi @nishakm, I ran Syft on both of these SBOMs for a quick test to see what was going on:

tgerla@Timothys-MacBook-Pro-2 syft-2525 % syft package_json.spdx.json
 ✔ Indexed file system
 ✔ Cataloged contents
   └── ✔ Packages                        [1 packages]
NAME           VERSION   TYPE
org.json:json  20220924
tgerla@Timothys-MacBook-Pro-2 syft-2525 % syft component_json.cdx.json
 ✔ Indexed file system
 ✔ Cataloged contents
   └── ✔ Packages                        [1 packages]
NAME  VERSION   TYPE
json  20220924  java-archive

It looks like the SPDX version has the package name as org.json:json but the CycloneDX document is just json, which is what Grype is matching.

My apologies but I'm not too familiar with the ecosystems here. Do you know how the org.json: part gets added to the package name? If that is standard syntax it might be the case that we need to parse it out, but I will have to check with the rest of the team to be sure.

[willmurphyscode]

I haven't been able to reproduce this in a general case:

❯ syft -o spdx-json solr:latest > /tmp/solr.latest.spdx.json
...
❯ grype -q solr:latest | wc -l
      96

❯ grype -q /tmp/solr.latest.spdx.json| wc -l
      96

(I just picked Solr as a random public image that has a fair number of JARs in it.)

I think the org.json is the group ID of the Java package, but I'm not sure why it would be in the way here. I'll try to investigate some more later this week.

[nishakm]

@tgerla The org.json is the groupID which for CycloneDX is a separate property. One thing to note is that the SBOMs were not generated by Syft but by the SPDX and CycloneDX maven plugins. So I am guessing the issue may be with the way Grype converts the SPDX information into Syft's internal data model. I haven't been able to find the relevant code though.

[nishakm]

@willmurphyscode For SPDX, I used the maven plugin which can either print out the project name or groupID:artifactID as the SPDX name. SPDX doesn't have a group property like CycloneDX.

[nishakm]

cc: @goneall @kzantow You may be interested in the CycloneDX group to SPDX name compatibility.

[wagoodman]

This sounds like a good generic add to grype specifically. Where the details are:

• if the package type is Java (TBD on if that info is available from the tooling that generated the SBOM example from this issue)
• and the Name is exactly two fields delimited by :
• Then pack in this information into the java metadata ArtifactID and GroupID to allow for matching to behave effectively

Developer note: this should be done fairly early in processing (during the package provider processing) such that CPE generation will take these values into consideration.

[spiffcs]

Potentially related: #1701

[spiffcs]

Moved this to ready based on the implementation details suggested by @wagoodman