I’m encountering an issue with Grype where certain CVEs, like “CVE-2020-0001,” are present in the vulnerability metadata but not in the main vulnerability table. This is causing some problems because the matching process fails when component data for these CVEs isn’t available, even though the CVE itself exists in the metadata.
For example, when I run:
grype db search "CVE-2020-0001"
I get a response that the vulnerability doesn’t exist.
I’m curious if anyone has insights on:
Why certain CVEs might appear in metadata but not in the vulnerability table itself.
Potential workarounds or configurations that could help Grype recognize or fetch component data for these missing CVEs.
The reason for this CVE not being present is that the only CPEs are for operating systems, and grype-db only includes records for applications.
The CPE “part” field indicates whether the CPE is targeting an OS (o), an application (a), or hardware (h). If you look at the CPE section of the CVE-2020-0001 record, you’ll see the only ones are cpe:2.3:o:google:android:8.0:*:*:*:*:*:*:* and similar. The :o: in there indicates it’s an OS CPE.
Recently there was a change merged to allow configuration to include additional non-application CPEs, but the grype-db nightly build is still configured to only include applications.
I think this is probably a bug in grype-db, the process that we use to build Grype’s vulnerability database. As Keith explained, the CVE itself is excluded because we only consider Application CPEs in Grype, not OS CPEs. So I think the bug is that the metadata row is present, not that the vulnerability row is missing.
$ sqlite3 ~/Library/Caches/grype/db/5/vulnerability.db 'select id, namespace, severity from vulnerability_metadata where id="CVE-2020-0001";'
CVE-2020-0001|nvd:cpe|High
$ sqlite3 ~/Library/Caches/grype/db/5/vulnerability.db 'select id, namespace from vulnerability where id="CVE-2020-0001";'
So @Azbar is exactly right: we have a metadata row but not a vulnerability row. I think we should probably have skipped the metadata row, but maybe this is not done or not easy for some reason I haven’t thought of.
@Azbar - Keith is right that we won’t match on this, because we don’t process type OS (cpe:o) type CPEs in Grype.
How did you encounter this CVE? In other words, can you help me understand what particular problem it’s causing? It seems like a vulnerability metadata row that is never matched on doesn’t do anything to Grype besides waste a few bytes of space. What am I missing?
@kzantow or @wagoodman do you think it’s worth trying to make grype db skip this metadata row? Or maybe we just won’t have this bug any more in schema v6? Or maybe I’m wrong to treat it as a bug?
I can’t see a reason to keep these in the metadata table if there aren’t any references in the vulnerability table. What if something is linked in a related vulnerability?
I encountered this issue while working on a project to retrieve and parse CVE data, along with the related metadata, directly from the Grype DB. I noticed that a significant portion of CVEs (about 40%) were missing from the main vulnerability table, even though they were listed in the metadata. CVE-2020-0001 was just an example; this issue affects a substantial number of entries.
The absence of component data for these CVEs is causing problems in our matching process, as we rely on the full set of vulnerability information for accurate results. This gap makes it difficult to account for all vulnerabilities effectively.
This issue is also related to another question I posted, where I encountered discrepancies between expected and actual artifact names in the DB. These missing entries are adding to the challenges in aligning and cross-referencing CVE data accurately.
Grype focuses vulnerabilities in software packages, not hardware or operating systems. For that reason, we only include CPEs of type a (“application”). If you look at CVE-2020-0001 you’ll see that it’s type o (It’s a vulnerability in the Android operating system).
I think the change that would make the most sense for Grype’s core use case is to drop the metadata for CVEs we are dropping, which would make the database more consistent. This would also make the database faster to download, which is something we’re always trying to improve one. Would this fix your use case?
We’ve also discussed building and publishing a Grype database with the complete set of CVEs (which will be significantly larger and take longer to download) at a non-default URL that grype can be configured to use. Do you have a use case for that? It sounds like you’re attempting to make use of these o and h CPEs?
@willmurphy , one thing you’d need to be careful with here on dropping metadata for CVEs that get dropped is that it would likely have to be a post-processing step on grype-db. The reason is that even though we may drop the NVD-based vulnerability rows due to having no a type CPEs, there may still be distro level data with a relationship to the CVE and some of the NVD data is queried and used to create the corresponding distro namespace vulnerability metadata record. So I believe you’d need to first populate all of the NVD namespace metadata rcords as we do today, let everything else run, and then remove any nvd vulnerability metadata records without a related id in the vulnerability table.
Thank you for the clarification regarding the missing 40% that makes a lot of sense now!
I agree that dropping the metadata for CVEs not included in the main vulnerability table would definitely make the database more consistent and easier to work with.
I’d also be interested in learning more about the database option with the complete set of CVEs. When you mention a “complete” set, does that mean it includes the hardware (cpe:h) and OS-level (cpe:o) CPEs that you mentioned?