Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: add new severity[].source field #248

Open
marco-silva0000 opened this issue Jun 21, 2024 · 4 comments
Open

Proposal: add new severity[].source field #248

marco-silva0000 opened this issue Jun 21, 2024 · 4 comments

Comments

@marco-silva0000
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

dodys commented Nov 14, 2024

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
Copy link

litios commented Nov 14, 2024

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
Copy link
Collaborator

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants