Why are Hardware and OS cpes in NVD left out in GrypeDB ?

[wenoukiz]

In this script: pkg/process/v5/transformers/nvd/unique_pkg.go there is a clear instruction (l.45) to keep CPEs that are only of type "application". Since this seems intentional, can you explain this choice ?

What would you like to be added:

If there is no specific reason for that behavior, could there be a patch to allow for all CPEs from NVD to be retrieved? Or a command line argument to specify which type of CPEs you would like to fetch?

Why is this needed:

In my case, I am testing Grype on IoT products. Meaning, I would like to get an SBOM with application, OS and hardware dependencies. The current behavior of GrypeDB makes it impossible to scan for vulnerabilities on components that are not of type "application".

Additional context:

[tgerla]

Hi @wenoukiz, thanks for the question. At the moment, Syft has no catalogers that will report OS or hardware CPEs, so the SBOM won't match any vulnerabilities, and Grype only knows how to consider packages as input. Can you tell us a bit more about how are you generating your SBOM? Are you using Syft? Can you provide an example SBOM? Thanks!

[wenoukiz]

Hi, thanks for the response. I am using Syft to generate a base SBOM that I then tweak and edit with my own knowledge and analysis of the firmware I'm testing. The SBOM is not automatically generated, at least not completely.
As an example :
My firmware is running on Windows 10 IoT LTSC. Syft will not pick this up and it will not appear in the SBOM automatically, that is why I add it manually with an entry that could look like this :

The problem is that Grype DB does not store vulnerabilities that apply to "operating-system" product type. So when scanning this SBOM with Grype, I don't get any matchings although there are some

[wenoukiz]

For your information, with the objective of making GrypeDB and Grype work with hardware and OS vulnerabilities, I cloned this repository and removed the few lines of code I mentioned in the first comment. Then I built my own version of GrypeDB (obviously, the unit tests failed on this modification) and used it to extract the vulnerability data from the NVD. I then packaged the database as an archive to import into Grype and scanned my SBOM with the updated vulnerability data.

It worked perfectly. The only problem is that you have to use the "application" or "library" type in the SBOM for each component, as Grype ignores the "operating-system" type (for now at least, this could be a future fix for Grype). Apart from that, the vulnerabilities I was expecting appeared in the Grype scan result. In my use case, bringing this patch to GrypeDB and Grype would allow me to scan for vulnerabilities on my firmware and other IoT softwares. Could this feature be integrated officially ? Or is there a reason for this to stay ?

[willmurphyscode]

Hi @wenoukiz,

We discussed this recently at our community meeting today, and we've decided that we're not going to add hardware or OS CPEs into Grype's database at this time, for a couple of reasons

1. We don't want to make Grype's database a lot larger, since download times for it have already been an issue for some users.
2. Syft and Grype presently do not detect hardware at all, and are primarily used to scan container images, which do not really contain operating systems either, so the extra space used by OS and Hardware vulnerabilities would not benefit the vast majority of Grype users.

For these two reasons, we have no plans to add hardware CPEs into the Grype database right now.

It sounds like you've already got our data pipeline working with the changes to allow you to bake in hardware and OS CPEs. That's fantastic! I would recommend you continue down that path if it's working for you.