Support ecosystem severity under severity[]

[litios]

Currently, the schema allows CVSS severities under severity[].
Nevertheless, you can find references to other severities under other
areas:

• On the summary (AlmaLinux, RockyLinux)
• Per-package under ecosystem_specific (Android, Ubuntu)
• Under database_specific (Bitnami, GitHub issues)
• Under references (RedHat)

It's common practice for security teams to provide a severity related to
the security issue within their ecosystem. The severities previously
mentioned are examples of them.

This presents a problem within the schema: publishers have the need to
provide this ecosystem severity, but there is no defined way to do so.
This results in having several references to severity within the
document and no standard way to retrieve this ecosystem severity, since
each publisher is taking a different approach.

Given that severity[] already exists, it would make sense to have an
ECOSYSTEM type severity. This is the same type used for providing
version ranges, so this wouldn't be unexpected. A namespace optional
field could be used to provide a reference to the meaning of the score
as per the ecosystem, similar to how it's done in CVE records.

An example using Red Hat namespace:

"severity": [
    {
      "type": "ECOSYSTEM",
      "score": "Low",
      "namespace": "https://access.redhat.com/security/updates/classification"
    }
]

This proposal was developed with feedback from Red Hat and Ubuntu, that
already support this request.

[oliverchang]

Thanks for the proposal! And sorry for the slow response -- just coming back after the holiday period.

Our initial intent was indeed to rely on database_specific or ecosystem_specific to encode qualitative severities, since the meaning of them likely depend on the data source. Since we now have a severity field, it might make sense to make this more easily encoded in a more consistent way across different sources.

Regarding the actual semantics of this proposal, we have two severity fields: a top level one and a package-specific one under affected[]. type: ECOSYSTEM would only make sense under the latter. I wonder if we should have this as type: DATABASE instead that applies to both?

Adding in some other distro PoCs for comment:

@Roo4L (AlmaLinux)
@luhring (Chainguard/Wolfi)
@mstg (Rocky Linux)
@jasinner (Red Hat)
@msmeissn (SUSE)
@dodys (Ubuntu)

And also @darakian @andrewpollock (other schema maintainers).

[litios]

@oliverchang thanks for the feedback!

I want to clarify this part:

type: ECOSYSTEM would only make sense under the latter. I wonder if we should have this as type: DATABASE instead that applies to both?

ECOSYSTEM is being used for packages with a meaning that is similar as to what we are aiming for here: the information is specific to the ecosystem referenced.

The severity definitions are defined by the ecosystem. For example, the definition of a Red Hat severity of Important won't change across databases, as it is defined by Red Hat.

Just to be clear, I'm not against your proposal but given that ECOSYSTEM is already covered by the spec and seems to fit the same goal, I want to clarify why it's not a valid option.

[oliverchang]

Thanks for the clarifying your rationale!

My main concern is that there isn't a concept of a top level ecosystem in OSV records -- there may be many ecosystems encoded within a single record under multiple affected[] entries. Having an top level severity type named ECOSYSTEM severity makes things potentially a little inconsistent/confusing here.

Perhaps QUALITATIVE might be a better word here that better communicates this severity type?

{
  "id": "ID-1234",
  "severity": [
    {
      "type": "QUALITITATIVE",
      "score": "Low",
      "namespace": "https://access.redhat.com/security/updates/classification"
    }
  ]
}

[litios]

The idea of this new severity type is not to provide a single top-level one but to use it just as another type. Probably, most cases would only have one instance (the one from the publisher) but multiple different ones could live in the same report, so it would be no different than the affected[] entries.

Following with your example, let's say Oracle Linux provides its severity but also wants to provides Red Hat one, because in this case there is a difference and that wants to be stated. Both of them would coexists under severity[] as different entries.

{
  "id": "ID-1234",
  "severity": [
    {
      "type": "ECOSYSTEM",
      "score": "Low",
      "namespace": "https://access.redhat.com/security/updates/classification"
    },
    {
      "type": "ECOSYSTEM",
      "score": "Moderate",
      "namespace": "https://oracle-linux/security-ratings"
    },
    {
      "type": "CVSS_V4",
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N"
    }
  ],
  "affected": [
    {
      "package": {
      ...
}

About QUALITITATIVE, that sounds good to me too!
I just want to clarify about the ECOSYSTEM one first, just to be sure I'm explaining the idea correctly.

[Roo4L]

Hi! I am no longer maintaining OSV entries in AlmaLinux, please contact @andrewlukoshko about this.

[oliverchang]

The idea of this new severity type is not to provide a single top-level one but to use it just as another type. Probably, most cases would only have one instance (the one from the publisher) but multiple different ones could live in the same report, so it would be no different than the affected[] entries.

Yep, I understand that :) My suggestion essentially boils down to renaming ECOSYSTEM to QUALITATIVE because ECOSYSTEM potentially clashes in meaning with existing ECOSYSTEM for describing package ecosystems.

[litios]

Thanks for the clarifying! If it's mainly for the purpose of not mixing the meanings I'm happy with QUALITATIVE.

Looking at next steps, would PRs from our end be preferred or would your team handle this internally?

[oliverchang]

Thanks for the clarifying! If it's mainly for the purpose of not mixing the meanings I'm happy with QUALITATIVE.

Looking at next steps, would PRs from our end be preferred or would your team handle this internally?

A PR would be great! What we'd also like to see before merging the PR though, is some feedback from other Linux distro database maintainers also.

[darakian]

Also coming back from some holiday time (and a bit sick 🤒). If I understand this correctly the basic idea is to allow for more severity systems with a link out to the rules for that new system? Is that an accurate gist? If so how many of these system do we expect to add and maybe they could be added as types akin to how cvss 3 and 4 are types?

[oliverchang]

Also coming back from some holiday time (and a bit sick 🤒). If I understand this correctly the basic idea is to allow for more severity systems with a link out to the rules for that new system? Is that an accurate gist?

Yep! Specifically qualitative ratings like "High", "Critical", because they're highly subjective measures that are very specific to a particular source/database.

If so how many of these system do we expect to add and maybe they could be added as types akin to how cvss 3 and 4 are types?

I'd imagine there would be a lot and too many to list in the schema, since there's not really a standard definition for "High", "Critical", "Medium", "Low". Every vulnerability database could have its own definition.

[jasinner]

Is it correct that we'd be able to use the new QUALITATIVE severity in both top level and for each package? I think that would be ideal to be able to describe Red Hat's assessed impact for the top level erratum impact (which is the highest of the package severities) and the individual packages themselves, which is often different.

[darakian]

I'd imagine there would be a lot and too many to list in the schema

Do we expect to have tens to hundreds of severity rating systems? Maybe I guess, but I feel like throwing these all behind a url makes the job of the reader much harder over time as urls come and go.

[litios]

Do we expect to have tens to hundreds of severity rating systems?

I don't think we will get to hundreds but tens sounds realistic. In most cases, a record will have the QUALITATIVE severity from the publisher itself and, in some remote cases, maybe another related to this. Nothing stops a publisher from providing others but that's the most realistic scenario IMO

as urls come and go.

This is part of the motivation of having it as a field itself and not as key-value type that users need to check in the documentation. It all comes down to maintaining those URLs. If they are on the records, the publisher can handle it. Otherwise, a request to change the documentation to point to the new URL (or to add a new one) would be needed for each case.