Add a severity source field

[conorfitch]

Hello! Please also see this related PR for osv.dev: google/osv.dev#4729

• This PR adds an optional severity[].source field, previously discussed in this issue: Proposal: add new severity[].source field #248

• There are several data sources in OSV.dev that aggregate severities from other providers, such as NVD or Ubuntu. This can lead to cases where the same severity is duplicated across aliased or upstream records, because the severity came from the same source. It can also result in cases where multiple severities are provided in a single record, but is unclear what the difference between them is.

• The addition of this field should help these issues to be solved, by allowing the source of a severity to be specified. For example, it can be ascertained through the field that one severity was issued by NVD, while the other was issued by the CNA.

[conorfitch]

@another-rex @andrewpollock Does this kind of PR need to be brought to OpenSSF for discussion first?

[another-rex]

Hello! I added it to the monthly APAC Vulnerability Disclosures Working Group for discussion.

I can see the value in adding a source field to describe from where is comes from, but am a bit concerned about how free form the string is, e.g. there's no standard way to match only against "redhat" as the source, since it can be spelt a bunch of different ways, unlike ecosystem which is a rigid enum.

[conorfitch]

Thank you! That is a good point. Perhaps the shortName could be taken from the CVE5 data and then validate it against the data available at https://www.cve.org/cve-partner-name-map.json (and also add NVD to that list).

Although a custom string might still be useful in the event a source is not present in that list - maybe the x_ prefix could be also used to denote a non-standard source name?

[jess-lowe]

Thank you! That is a good point. Perhaps the shortName could be taken from the CVE5 data and then validate it against the data available at https://www.cve.org/cve-partner-name-map.json (and also add NVD to that list).

I don't particularly like the reliance on CVE's data provider structure for this as it only solves the issue of CVE records not having source information, and there would be a heavy dependence on an external program's schema and governance.

OSV has many more data providers outside of the CVE Program's scope (and vice versa). Severity scoring also can happen outside of just the issuing CNA and the NVD.

Instead of maintaining a list of CVE CNAs, an alternative that could cover CVE records is just using the term "Issuing CNA" or the like. I guess a similar case could be made for OSV data providers, with a more OSV specific term.

Either way, definitely agree it shouldn't be freeform text.

[conorfitch]

@jess-lowe That makes a lot of sense - to simply distinguish between CNA and NVD scores for example, would be excellent.

That sounds similar to how NVD display the categories on their site - i.e. NVD, CNA, as well as ADP I think (not sure if they have any other categories). And in the case of a CVE, someone could be able to look at the "cna_assigner" from database_specific if it exists and they wish to do so.

Could it be that if the record doesn't provide a severity source, then it is to be presumed that the severity was produced by the record's provider? Or maybe there could be an explicit way of denoting that, for example, putting the record's id prefix as the severity source?

It seems like a few databases copy the CVSS scores from NVD/CNA into their own OSV records currently, so I was wondering if those would ever end up being marked as such.

[gregkh]

Signed-off-by: Conor Fitch 173908980+conorfitch@users.noreply.github.com

Nit, I do not think this is not a valid email address for a signed-off-by line.

[jess-lowe]

To avoid having the external dependency in the schema, and still avoid the freeform text, I believe the best way forward is to have the field as an enum with options of:
CVE-CNA, NVD, and then some default generic one for the providing database for now, and we can add more as we come across them (in a similar but less involved way as ecosystems and ID prefixes).

Implicitly, if the source is missing, we consider the home database providing it to be "responsible" for the rating - whether it be providing it or endorsing it.

some suggestions for the default home database as the source provider (but I'm not a big fan of any):
SOURCE
HOME-DB
DATA-PROVIDER

For the CVE-CNA we can also add a linter check that checks that the record is at all related to a CVE record in a form of 1:1 mapping so that it can only have a single CNA.

[conorfitch]

Thanks @jess-lowe ! I like the sound of that - an enum with NVD, CVE-CNA and one to explicitly say it was provided by the record's database.

That is tricky to get the name right for the third option. The only suggestion I have to add to that list is "source": "SELF".

In addition to CVE-CNA, would CVE-ADP be a reasonable option to add? Here's an example with scores from NVD, CNA and an ADP: https://nvd.nist.gov/vuln/detail/CVE-2025-9491. (Is it correct to have the CVE- prefix for it, or should it just be ADP?)