Proposal: add new severity[].source field

[marco-silva0000]

Proposal to add a new optional string field on a severity entry that represents "who" scored or where that scoring came from.

Different entities score vulnerabilities differently and sometimes there are different sources that don't agree on scoring for the same vulnerability, this would allow the schema to support both instead of having to make a decision on which one is best.

[oliverchang]

Hi,

So sorry for missing this issue earlier!

As OSV is a distributed database, where database owners publish their own vulnerability records, the implication is that all values in that record (including severity values) come from the database itself.

For example, if a GHSA advisory has a severity field, then the implication is that this severity comes from GitHub (or at least, GitHub endorses the severity if it came from somewhere else).

[dodys]

Hi @oliverchang,

Just saw this issue and I think it would be nice to have a source field. Users/customers might be interested in seeing more than one rating in a single view. Therefore if Ubuntu wanted to have two different CVSS scores published in OSV, it would be unclear why they differ or who calculated/published it (for example one from NVD, one from Intel). It is more than just endorsing, it is also about users wanting this single view of all the different ratings.

[litios]

I agree with @dodys here, it's not uncommon for distributions to provide their own CVSS and there is value in specifying who did the severity analysis. When looking at distro-specific CVEs, the user doesn't know if the CVSS score listed there is specific to the distribution or it comes from the general CVE without having to consult both entries.

Talking about CVE entries coming from NVD, their CVSS scores can be both their own ones as well as others, like
CVE-2024-49394. In this particular case, the analysis actually comes from Red Hat and there is no way to identify this from OSV data.

Same happens with most NVD CVEs coming from a GitHub advisory, in which case the CVSS comes directly from GitHub.

[andrewpollock]

Circling back to the point @oliverchang made in #248 (comment) and attempting to restate it differently:

For a given OSV record with a given identifier prefix, it has a singular home database. That home database is implicitly the source of the entire record, including the severity scores in it. While OSV.dev is loosely analogous to the NVD in terms of being a downstream aggregator of OSV records, it's not aggregating multiple records into a single record, nor is it adding any subjectively determined data from other sources. In other words, the only way any severity values will appear in an OSV record if they are included by the record's publisher. Is the desire here for a record publisher to include multiple severity values and differentiate which ones are first-party versus third-party?

It may be helpful for the folks interested in this functionality to drop in some worked examples (take an existing OSV record and demonstrate how this functionality would work) to clarify?

[litios]

Is the desire here for a record publisher to include multiple severity values and differentiate which ones are first-party versus third-party?

Yes, I think fundamentally that's the case, for example to list NVD CVSS and specific publisher CVSS.

Also, in some cases, to clarify who produced the information. The publisher chooses what information to publish, but this still does not clarify if the information was produced by the publisher or not. As per severity, I feel like it is relevant if the source of it is the publisher itself or if it was inherited from somewhere else. NVD takes a similar approach as they clarify where the CVSS came from.

As per an example, coming back to CVE-2024-49394, NVD shows this CVSS score was generated by "Red Hat, Inc". This "source" field will clarify this information was not produced by the publisher, but still wanted it to be showed.

    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "source": "Red Hat, Inc."
    }

as per the multiple cases, given that Debian packages are listed there, I'll use that as the other party for the example. If Debian considers the complexity high:

    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "source": "Red Hat, Inc."
    },
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "source": "Debian"
    }