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.