Configure CVSS score prevalence

In this tutorial, we will configure CVEScan's nvd connector's score_sort attribute to reflect on the UI and CSV export exposed scores.

For each vulnerability, CVEScan JSON report will contain every score maintained by the NVD. However both UI and CSV export, for readability purposes, limit the number of scores exposed. Hence the UI will show a single score, where the displayed score is the first score available in the CVSS section of the highest version. While the CSV export will maintain the first score available in CVSS v2, v3.x and v4 versions. CVEScan let you pick a rule that internally reorders vulnerabilities's scores given their caracteristics. The available rules are "default", "force_nvd" and "legacy"

default: NVD primary scores come first, then other primary scores, then secondary scores. force_nvd: NVD scores come first, primary are favored, then secondary scores. legacy: NVD or loaded report scores order is unchanged.

Examining a CVE row in a exported CSV

We will start by scanning an inventory, as we do not need a full run for this tutorial purposes, without modifying the NVD connector default sorting rule.

cvescan scan-inventory --inventory demo.inventory.json

In the .json output we assume that we report a CVE-2025-5351. If we look at it in details we should see:

"cve": "CVE-2025-5351",
...
"impact": {
    "cvssMetricV31": [
        {
            "source": "secalert@redhat.com",
            "type": "Primary",
            "cvssData": {
                "version": "3.1",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "baseScore": 6.5,
                ...
            },
            ...
        },
            "source": "nvd@nist.gov",
            "type": "Secondary",
            "cvssData": {
                "version": "3.1",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "baseScore": 6.5,
                ...
            },
            ...
        }
    ]
},

Then let's export the output report to a CSV and take a look at one of the rows.

cvescan export-report --input demo.report.json

You can see that CVSSv3 columns have been filled from a Red Hat defined score, which defines the only primary score for this CVE.

Configure CVE scores sort

In CVEScan's working directory config.yml connectors section we will configure the nvd connector as follows:

connectors:
  nvd:
    scores_sort: "force_nvd"

We won't have to re-scan the inventory as a sort will be performed during report load with this configuration.

cvescan export-report --input demo.report.json

Our CVE-2025-5351 will now look like this.

In this specific example both source scores the vulnerability similarly.

Finally, let's change the sorting rule to legacy so that the NVD maintained scores order is maintained.

connectors:
  nvd:
    scores_sort: "legacy"

Here we need to re-scan the inventory as no sort will be performed and we need to be sure that CVEScan serialize NVD data in the report as is.

cvescan scan-inventory --inventory demo.inventory.json

It turns out that the scores for CVE-2025-5351 are maintained in the same order that we obtained with the default rule.

"cve": "CVE-2025-5351",
...
"impact": {
    "cvssMetricV31": [
        {
            "source": "secalert@redhat.com",
            "type": "Primary",
            "cvssData": {
                "version": "3.1",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "baseScore": 6.5,
                ...
            },
            ...
        },
            "source": "nvd@nist.gov",
            "type": "Secondary",
            "cvssData": {
                "version": "3.1",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "baseScore": 6.5,
                ...
            },
            ...
        }
    ]
},

Therefore the CSV row is also identical.