Severity does not support multiple differing severities for one ID

[joshbressers]

I just noticed if I have two different severities for the same identifier, I can't note this in a sensible manner.

For example

Let's say ID-1 affects two Linux distributions differently. On one distro it's critical, on the other it's important.

Right now the severity field is inflexible
https://ossf.github.io/osv-schema/#severity-field

It's an array, but the spec only support CVSSv3, and there is no way to namespace the findings into package or ecosystem. In the affected fields, I will specify an ecosystem to account for this

{"ecosystem": "distro1", "name": "package"}

and

{"ecosystem": "distro2", "name": "package"}

I've also seen instances where different versions have different severities to make this even more difficult. This is less common, so trying to put severity in the affected field would create a lot of duplication for what is not a common occurrence.

[oliverchang]

Thanks for bringing this up! Not sure if there's a sensible way to encode the per-version severities, but perhaps we could add a per package "severity" field that overrides the top-level one. Is this something that you see often in practice?

[joshbressers]

Putting severity as an optional field in "package" would work I think, yeah

[kurtseifried]

I think there are two aspects here:

Nested data
Data viewpoints within a specific instance

So for example you have Red Hat Enterprise Linux 8, and 9, one is affected, one is not. Even within a version, you might have a default config that is not affected, and a common case config that is affected, thus very different severities. So I think nesting data e.g.:

Vendor
-Product
--Version 8
---Severity 8.2
--Version 9
---Config 1
----Severity 1.2
---Config2
----Severity 6.9

And then even within a specifically affected product/version/etc you may have different viewpoints on the severity, e.g. an information leak of just the user's first name may be viewed by many as Confidentiality: Moderate but by a regulated entity (e.g. due to privacy legislation) as Confidentiality: High. I think the way to express this is again with some version of nesting/namespacing within the data, e.g.:

Vendor
-Product
--Version 9
---Severity 1.2
---Viewpoint from X
----Severity 6.9

The logic generally being you traverse down the JSON and set values, and if you find a nested value it overides the already seen one.

[oliverchang]

At some point, I think it makes more sense to split out separate vulnerability entries rather than try to encode all of this complexity in a single one. A Red Hat specific entry would have its own ID with its own opinions on severity.

Re configurations, I think we need to all agree on a machine readable way to specify this.

We've also taken a rather careful approach to adding new fields for this schema, as we are committed to maintaining backwards compatibility with all new versions of the schema. For experimentation / to unblock uses, we have the ecosystem_specific and and database_specific extension points to add more context than what the schema supports.

For per-package severity specifically, do you have any example entries / databases that would really benefit from this? Feel free to put up a PR for more discussion too!

[captn3m0]

VMWare Photon OS advisories have a similar challenge:

PHSA-2022-0304 is an advisory issued against 3 CVES: ['CVE-2022-43552', 'CVE-2022-4415', 'CVE-2022-43551'].

As such, the severity is on a per-package level:

Important

systemd - ['CVE-2022-4415']

curl - ['CVE-2022-43551']

Moderate

curl - ['CVE-2022-43552']

One way would be to create pseudo-identifiers (such as PHSA-2022-0304-4414, PHSA-2022-0304-43551, PHSA-2022-0304-43552) which all link to the same reference, but link against separate CVEs, and have single value of severity.

[kurtseifried]

So the CVE JSON was specifically designed to support this by nested containers o data, e.g. (pseudo code, I forget the actual values):

{
"id": "some-id",
"affected": [
{
"curl": {
"impact": "really bad"
}
},
{
"systems": {
"impact": "not that bad"
}
}
]
}

[kurtseifried]

Also the problem with pseudo identifiers is what happens if the severity changes, and then changes back, and do we do a pseudo identifier only for different values, or for all the packages/etc? Having a proper data structure is a MUCH better solution than taking a data structure and making it work by partially replicating it, poorly. There's also issues around discoverability, cross-referencing, updates, etc.

[oliverchang]

Thanks for the input and the Photon OS example. +1 to avoiding pseudo IDs. Would someone like to suggest a PR to add this?

I think the easiest way to fit this in the OSV schema is to add an identical "severity" field at an "affected" package level.
The semantics of this would be that it's optional, and defaults to the top level value in the OSV entry. If specified, it overrides any top level entry.

[oswalpalash]

Hi @oliverchang, I opened #106

[oliverchang]

This was released in 1.4.0