the genereated .\_manifest\spdx_2.2\manifest.spdx.json scaned with trivy got no vulnerbiltiy

[baoj-dfo]

when use trivy to scan the image, got some vulnerbiltiy, but using this sbom tool to getnerated ._manifest\spdx_2.2\manifest.spdx.json, then run trivy sbom ._manifest\spdx_2.2\manifest.spdx.json returns 2024-11-04T... INFO [vuln] Vulnerability scanning is enabled 2024-11-04T... INFO Detected SBOM format format="spdx-json" 2024-11-04T... INFO Number of language-specific files num=0

._manifest\spdx_2.2\manifest.spdx.json contains about same number od packages as the sbom file genereated by trivy.

[JoseRenan]

Hi @baoj-dfo, thanks for reporting! Could you please provide more details on what are you trying to do, and the expected outcomes?

[baoj-dfo]

@JoseRenan , can you give me email ?, I'll send you the two spdx files generated by MS sbom and trivy for investigation the expected outcomes is to trivy sbom of those 2 files to get same results.

[JoseRenan]

@baoj-dfo you can send the files through Github Gist and give the links or upload them here!

[DaveTryon]

@baoj-dfo, we triaged this today. We will only be able to take action if you can provide a demonstrable case where the SPDX data generated by sbom-tool is non-compliant with the SPDX spec. We know that we're specifying 2.2 as our SPDX version (instead of 2.2.2), but other than that we believe that our output is SPDX-compliant.

As mentioned previously, please put the non-compressed manifest.spdx.json file into a Gist, as well as a reference to the SPDX spec that seems out of sync, and we can investigate it from there. Thanks!

[baoj-dfo]

@JoseRenan @DaveTryon thanks ahead for look into this:

https://gist.github.com/baoj-dfo/ce0fcad6d8e2b713b1cbc15be99ad49f

[JoseRenan]

@baoj-dfo I've noticed in the files that they are in different versions of SPDX format, our tool generates the SPDX 2.2 version format while the Trivy one is using the 2.3 version format. Maybe that's a issue you should bring to Trivy's team so they can investigate why the result is different for different formats. Also, we noticed that the files field is empty in one of the JSONs. But I'm not sure on how Trivy looks for vulnerabilities or generates the spdx, so you should try opening a issue with them for getting a better support on this scenario.

[baoj-dfo]

@JoseRenan It appears that Microsoft doesn’t provide a tool specifically for generating vulnerability reports from SBOM files. What tools would you suggest, or which ones are commonly used by Microsoft developers?

[JoseRenan]

@baoj-dfo yes we don't have a public tool for that unfortunately, but as I told you, what caught my attention is that your files section on the SPDX is empty for the one generated by our sbom-tool, I don't know how you ran the tool so the json was generated that way, but since I don't know how trivy works, that could be one of the reasons they are not finding any vulnerabilities, because besides that, the only other noticeable difference between the files seems to be the SPDX version.

[baoj-dfo]

@JoseRenan I didn't get any error, so files section is empty , that could be the sbom-tool's problem ? sbom-tool generate -di apsabacacr.azurecr.io/ncds/ncdsapi:latest -m . -ps 'aa' -pn 'bb' -pv "cc"

I also tried Grype, and it works well alongside Trivy. The SBOM generated by one tool can be scanned by the other, yielding the same vulnerability results.

[rhyskoedijk]

@baoj-dfo I believe the files section of the SPDX is only populated if you specify the -b or -bl options. It won't detect files within the ncdsapi image.

I could be completely misunderstanding what you are doing, but maybe something like this would get the results you are expecting?

# export the docker image filesystem to a local directory that sbom-tool can scan it
docker container create --name my-build-container apsabacacr.azurecr.io/ncds/ncdsapi:latest
docker export my-build-container -o my-build-container-fs

# generate a sbom using the exported filesystem (files) and docker image (packages)
sbom-tool generate -b my-build-container-fs/usr/local/ncds_api -di apsabacacr.azurecr.io/ncds/ncdsapi:latest -m . -ps 'aa' -pn 'bb' -pv "cc"

[baoj-dfo]

@rhyskoedijk Followed your steps, it generated the same ._manifest\spdx_2.2\manifest.spdx.json as before

(get-content ._manifest\spdx_2.2\manifest.spdx.json | convertfrom-json).packages.length return 43 (get-content .\sbom.syft.spdx.json | convertfrom-json).packages.length return 321 # syft (get-content .\spdx.json | convertfrom-json).packages.length return 321 # trivy

The SBOM file generated by MS missing a lots of packages, some of them contributed to vulnerabilities. spring-security-web
commons-io ...

[rhyskoedijk]

@baoj-dfo ignore me, looks like I misunderstood what you were trying achieve; Sounds like your issue is that the number of spdx "packages" reported by sbom-tool is not consistent with what is reported by other tools, which has nothing to do with the spdx "files".