Include CVSS Score in api response

[fwilhe]

CVSS is the metric used to describe the severity of CVEs.

We have the data from NVD in our database, but querying is not trivial because the json schema is quite complex. There are multiple versions of CVSS and each CVE might have multiple scores in each version.

It should be possible to query this using Postgres json features.

Expected outcome:

The response objects currently look like this

  {
    "cveId": "CVE-2002-1377",
    "sourcePackageName": "vim",
    "sourcePackageVersion": "2:9.1.0016-1",
    "gardenlinuxVersion": "1443.7",
    "cvePublishedDate": "2002-12-23T05:00:00.000",
    "vulnerable": false
  }

They should have a new field

"score": 7.0,

This score should be the highest cvss version available for the given cve.

[fwilhe]

Question: Is it ok to mix different cvss versions here?

I think the details of the different semantics in different versions don't matter too much for our use-case, so I guess it should be fine to leave those details out.

For triage purposes, the information 'this is rated very severe' is much more important than the details of the semantics of cvss.

[Akendo]

Question: Is it ok to mix different cvss versions here?

Simple answer: No

Since we import this data, we have a different data sets to resort to. Often, you'll find CVSS v2 data; however, this can be ignored. bdba does return these, but the standard as of now is CVSS v3. That would be my baseline for this value.

Since we can add our own assessment to this, we should be able to define the given score. But that's one the side. As of now we should stick to the 'official' numbers.

[fwilhe]

@Akendo

kindly clarify your perspective

We can ignore cvssv2 if that is what's needed. So score will be null if only cvss2 exists in a cve, is this what you think is correct?

Would you prefer multiple properties to keep the versioning information, so instead of

"base_score": 7.0,

it would be

"base_scorev4": 7.0,
"base_scorev31": 6.6,
"base_scorev30": 6.6,

or in other cases

"base_scorev4": null,
"base_scorev31": null,
"base_scorev30": 6.6,

?

[Akendo]

I must admit that I missed the question here. What's the question? Do we want to keep track of different types of CVS scores? Do we want only to return a single number of a given CVS type, or do we just want to share if a CVE has a simple rating like low, medium or high, critical?

Maybe this is a bigger issue here. Here is what I think:

To my understanding, we have a consistency problem. Since the CVSS is, at least with its base rating, something that is more often not available. It requires further details from the vendor and the given CNA might not have done the proper effort, or they're missing due to some embargo. Additionally, CVS changes based on the information that is learned about OR when the NIST isn't getting their processes properly enacted. In short, the data set needs to change, and we need to be able to keep track of that change.

This leads me to the key questions, how much do we want to consider this in the API and database design. Because for now, I want to ensure that we tell the Linux operate that the system has an update. And here is the list of vulnerabilities. Once we have more details on the CVS score, we can add it in the output. But maybe this should be then an explicit call then?

However, that means we can map CVSS to the given table within the database. This becomes even tricker once we want to reassess them. Would could use the CVS-BE as a value then. The questions now becomes, how do we keep track of our reassessments, then? Because when we keep this within the JSON files, I fear we run into inconsistency of our own.
Because we could make a reassessment of a CVSS that isn't properly assessed, and THEN it will be updated? This makes my head explode. Not even considering if the initial assessment is in a consistent format to ours.

When I think what you want is to know what we want to return, let's try the following:

Just return the mapping of the "Qualitative Severity Rating Scale"[0][1]. Meaning: We return based on the base score we have None, low, Medium, High or Critical. These are the same foe CVSS 3 and 4. So we can work better with the data we have.

I hope this helps.

[0]: https://www.first.org/cvss/v3.0/specification-document#Qualitative-Severity-Rating-Scale
[1]: https://www.first.org/cvss/v3.0/specification-document#Qualitative-Severity-Rating-Scale

€dit: Fix hyperlink with github markdown