Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wenoukiz opened this issue Feb 6, 2024 · 3 comments
Open

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

wenoukiz opened this issue Feb 6, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@wenoukiz
Copy link

wenoukiz commented Feb 6, 2024

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:
image

@wenoukiz wenoukiz added the enhancement New feature or request label Feb 6, 2024
@tgerla
Copy link

tgerla commented Feb 8, 2024

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
Copy link
Author

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 :
image
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
Copy link
Author

wenoukiz commented Mar 5, 2024

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

2 participants