SBOM generation and CVE checking

[Rico-van-Dongen]

lately we started making use of the west spdx command to generate SBOM files and it works pretty nice. We are using cve-bin-tool to automatically also check for vulnerabilities but there something goes wrong.
I tried deliberately to use an older version of mbedtls in my project such that it would flag the vulnerability but mbedtls is not being recognized correctly.
I've debugged the generated SPDX files and i found that the cve-bin-tool gets confused by the PURL reference.

as an example, the generated modlules-deps.spdx has an entry like this:

PackageName: mbedtls-deps
SPDXID: SPDXRef-mbedtls-deps
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageDownloadLocation: NOASSERTION
ExternalRef: SECURITY cpe23Type cpe:2.3:a:arm:mbed_tls:3.5.1:*:*:*:*:*:*:*
ExternalRef: PACKAGE_MANAGER purl pkg:github/Mbed-TLS/mbedtls@V3.5.1
FilesAnalyzed: false
PackageComment: Utility target; no files

if I run this file trough the vulnerability scanner, mbedtls is not correctly listed with a vendor and version and more importantly no vulnerability is flagged. instead in only shows the product mbedtls-deps with unknown vendor

however, if I take out the ExternalRef: PACKAGE_MANAGER purl pkg:github/Mbed-TLS/mbedtls@V3.5.1 then it is correctly identified and the vulnerability is correctly flagged.

Does anybody happen to know if there is a way to skip purl references from my sbom generation or knows an alternative vulnerability scanner that does correctly link the purl and the cpe reference?
furthermore. I noticed that the mbtls repo uses 'trusedfirmware' in their cpe reference as vendor rather than 'arm' perhaps this should be adopted in the zephyr fork to avoid confusion?

https://github.com/Mbed-TLS/mbedtls/blob/127c78e5895640206b5426f9a0888699d71d38fa/scripts/sbom.cdx.json#L16

finally, it would be nice if all the other zephyr forks get a cpe entry in their module.yml such that the SBOM gets more and more complete.

[Rico-van-Dongen]

I think I found a tiny bug in the SBOM writer scripts. (

zephyr/scripts/west_commands/zspdx/writer.py

Line 104 in 21b20de

f.write(f"ExternalRef: PACKAGE_MANAGER purl {ref}\n")

)
according to https://spdx.github.io/spdx-spec/v2.3/package-information/#721-external-reference-field the package manager field should be of type 'PACKAGE-MANAGER' rather than 'PACKAGE_MANAGER'
I manually changed the underscore in the output spdx file and then the processing works fine.

[pdgendt]

Could you please open a PR to fix this?

[pdgendt]

Possibly related: spdx/spdx-spec#792 and spdx/spdx-spec#869 ?

[Rico-van-Dongen]

ah, good find. those issues are definitely related. is my understanding correct that this means there would be no issue in stating to use the dash rather than the underscore? than i can indeed create the PR for it

[pdgendt]

I didn't dig into the details, but if this the current specification for SPDX, I would assume so. Opening the PR would also make it more visible and we can ping people to take a look.

[Rico-van-Dongen]

ok, I did a bit more testing and just changing the underscore to a dash isn't the (full) solution. then it is still showing in the cve-bin-tools with a UNKNOWN vendor.
I did a bit more digging and when i manually change the package name from mbedtls-deps to mbed_tls the cve check finds even more hits. I'm starting to wonder if there was a special reason to use the xxx-deps naming convention but i guess the cve-bin-tool needs more meta data in order for it to match to the vulnerability database
Also I found in the writer.py an option to print PackageVersion: but I dont see that being used. It would be cool to see and example of a zephyr modules.yml that uses all the meta data options. Maybe adding ExternalRefComment: field may be useful to highlight the relation with the original repo