Figure out how to import CVE's in the 'incomplete' state

[dommyrock]

Problem introduction

From NIST site we can se that the meaning of incomplete CVE means one of the 3 states.
CVE that is :

• Awaiting Analysis,
• Undergoing Analysis,
• Rejected

Will not include the configurations object.

This state is only visible from calling the new V2 API which produces similar response.

curl https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-9422

{
  "resultsPerPage": 1,
  "startIndex": 0,
  "totalResults": 1,
  "format": "NVD_CVE",
  "version": "2.0",
  "timestamp": "2025-05-13T10:21:02.769",
  "vulnerabilities": [
    {
      "cve": {
        "id": "CVE-2024-9422",
        "sourceIdentifier": "contact@wpscan.com",
        "published": "2024-11-22T06:15:20.370",
        "lastModified": "2024-11-22T18:15:18.287",
        "vulnStatus": "Awaiting Analysis", //THIS IS ONE OF THOSE STATES
...

We currently don't insert those CVE records because we cant extract product + vendor + cve unique identifier.

This is mainly because nodes: [] is empty and this node is responsible for containing CPE definitions (describing what products and versions are effected )

    "configurations" : {
      "CVE_data_version" : "4.0",
      "nodes" : [ ]
    },

Those kinds of cve's are filtered out by default here:

kepler/domain-db/src/cve_sources/nist/cve/mod.rs

Line 171 in 0758ec2

pub fn is_complete(&self) -> bool {

When configurations object is present, it looks like this:

 "cpe_match" : [ {
          "vulnerable" : true,
          "cpe23Uri" : "cpe:2.3:o:fedoraproject:fedora:39:*:*:*:*:*:*:*",
          "cpe_name" : [ ]
        }, {
          "vulnerable" : true,
          "cpe23Uri" : "cpe:2.3:o:fedoraproject:fedora:40:*:*:*:*:*:*:*",
          "cpe_name" : [ ]
        } ]

Example where cve is in "Rejected" Status (Bulk Gzip yearly API json srtructure)

NOTE: V2 API structure and Bulk Gzip Yearly json CVE dataset structure are not the same . (seems like other similar projects use newer API V2 after year 2023)
NOTE: Rejected CVE's have prefix "Rejected reason: ** REJECT ** in the cve "description" field.

{
    "cve" : {
      "data_type" : "CVE",
      "data_format" : "MITRE",
      "data_version" : "4.0",
      "CVE_data_meta" : {
        "ID" : "CVE-2024-9899",
        "ASSIGNER" : "cve-request@wordfence.com"
      },
//...
      "description" : {
        "description_data" : [ {
          "lang" : "en",
          "value" : "Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-2143. Reason: This candidate is a reservation duplicate of CVE-2023-2143. Notes: All CVE users should reference CVE-2023-2143 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage."
        } ]
      }
    },
    "configurations" : {
      "CVE_data_version" : "4.0",
      "nodes" : [ ]
    },
    "impact" : { },
    "publishedDate" : "2024-10-23T21:15Z",
    "lastModifiedDate" : "2024-10-23T21:15Z"
  }

Value seems to be consistently prefixed with " "value" : "Rejected reason: ** REJECT **" .

---

Possible solutions:

Seems like one option is to have multiple Data Sources instead relying just on the NVD.
Here is a great section on this from OSS project Trivy : Data Source Selection

Severity Selection

The severity is taken from the selected data source since the severity from vendors is more accurate.
Using CVE-2023-0464 as an example, while it is [rated as "HIGH" in NVD][nvd-CVE-2023-0464], Red Hat has marked its 'Impact' as ["Low"][redhat-CVE-2023-0464].
As a result, Trivy will display it as "Low".

The severity depends on the compile option, the default configuration, etc.
NVD doesn't know how the vendor distributes the software.
Red Hat evaluates the severity more accurately.
That's why Trivy prefers vendor scores over NVD.

If the data source does not provide a severity, the severity is determined based on the CVSS score as follows:

Base Score Range	Severity
0.1-3.9	Low
4.0-6.9	Medium
7.0-8.9	High
9.0-10.0	Critical

If the CVSS score is also not provided, it falls back to [NVD][nvd].

NVD and some vendors may delay severity analysis, while other vendors, such as Red Hat, are able to quickly evaluate and announce the severity of vulnerabilities.
To avoid marking too many vulnerabilities as "UNKNOWN" severity, Trivy uses severity ratings from other vendors when the NVD information is not yet available.
The order of preference for vendor severity data can be found here.

Relevant project repositories

Sources (some of them)

• https://github.com/aquasecurity/vuln-list (for more up to date nvd dataset vuln-list-nvd is better option)
• https://github.com/aquasecurity/vuln-list-nvd
• https://github.com/aquasecurity/vuln-list-redhat

DB Updater

• https://github.com/aquasecurity/trivy-db/tree/main/pkg/db

Source updater

• https://github.com/aquasecurity/vuln-list-update/tree/main

Updater code for specific sources

• RedHat
• NVD

Another solution

Look at sourceIdentifier and vulnStatus (api v2 only) as initial signal for further source lookups for the specific CVE-ID