Is estimation of criticality possible without known use cases?

[tobie]

My understanding is that estimation of criticality is difficult/impossible without specific use cases yet it is indicated as a SHOULD in the spec:

vulnerability-management-spec/spec.md

Line 113 in 2e0d61a

The publication of the list of known Vulnerabilities takes a form of a list of their identification (one or multiple ones) and at least one link to a public resource describing this Vulnerability (at least the affected product and versions, affected configurations and a general description) and RECOMMENDED to include an estimation of severity of the Vulnerability. The Organization MAY include additional information.

[mrybczyn]

It is a typical practice to define it based on the typical scenario and then users might adjust it for their particular case. This is well shown in the new CVSS 4.0 score when you have the base estimation and then downstream can adjust it to their use case.

[tobie]

Discussed this today with @gregkh who confirmed my understanding that without specific use-cases, criticality can't be defined. The same vulnerability that is critical for a use case might have no impact in a different use case. Requiring open source projects to estimate the level of criticality in that context doesn't make sense and would lead to projects providing non-actionable information (e.g. every vulnerability is marked as critical).

Our specification should be a reflection of accepted community best-practices and shouldn't mandate (or even recommend) practices which are not broadly implementable.

Suggest rewriting the sentence to:

The publication of the list of known Vulnerabilities takes a form of a list of their identification (one or multiple ones) and at least one link to a public resource describing this Vulnerability (at least the affected product and versions, affected configurations and a general description). It MAY include additional information such as the estimation of severity of the Vulnerability.

[raboof]

I'm not sure it makes sense to make this optional, as it's explicitly required in the CRA (Article 14(2)c i and Annex I part II 4). While I guess you could argue it's only required for manufacturers and strictly speaking not for stewards (Article 24(3) refers to Article 14(1) and not Article 14(2)) that seems like a strange interpretation.

I do feel the difficulty of assigning severities to vulnerabilities in libraries and other components that are typically part of a bigger whole: we occasionally have issues that could in theory have serious consequences, but only in unlikely scenario's. While I get that CVSS recommends making 'worst case' assumptions to 'err on the safe side', it does seem to mostly cause unnecessary panic.

Corner cases aside, it's usually possible and reasonable to distinguish some broad categories of vulnerabilities - at the ASF we typically use https://security.apache.org/blog/severityrating/ instead of CVSS. Even for the Linux kernel I'm sure you could come up with some meaningful categories, e.g. "can lead to privilege escalation on a typical system" vs "can only lead to privilege escalation when userspace makes exotic assumptions" (I'm clearly no kernel dev 😆)? Perhaps we could keep the severity as mandatory, but highlight the option of choosing categories that fit your ecosystem?

[gregkh]

For Linux there is no "typical system", so no, we can't come up with those categories, sorry. Remember, we have billions of Linux systems out there, what you might consider "typical" (i.e. a server), is really just a rounding error compared to everywhere else Linux is used :)

Also look at the rate of how security issues are published, Linux averages 13 per day, there is no way we can do a "deep dive" for this type of categorization for all of them, and we publish LESS issues than the other two major operating systems out there.

And this MUST be optional for stewards, as again, we do not know how you use our software, only a manufacturer does.

[rjb4standards]

@gregkh If vulnerability reporting really is optional for stewards then how will manufacturers know if a component they are using contains a vulnerability?

[gregkh]

Reporting a vulnerability is not optional, attempting to provide a "severity level" is the thing that must be optional. All a steward can do is say "hey, we fixed this issue over here that might be a vulnerability for your systems, take a look at it please!"

[rjb4standards]

@gregkh Thanks for clarifying. I concur, reporting a vulnerability is not optional, which also includes checking for vulnerabilities before going to market (which I think means making an open source project available via the typical package managers, but not sure about this).

[gregkh]

I do not think the "checking for vulnerabilities" is really a thing yet. let's see what the recommendations for stewards that are going to be discussed next week at the next CRA meeting look like before worrying about anything like that.

[rjb4standards]

I agree, more clarify is needed around the expectations/obligations for open source stewards.
There is no doubt that manufacturers will need to check for vulnerabilities in a product before going to market, per the EU CRA obligations: Article 13 (12), Article 31 and Annex I Part II makes this clear.
12. Before placing a product with digital elements on the market, manufacturers shall draw up the technical documentation referred to in Article 31.

[tobie]

@rjb4standards: let's please stay on topic. This issue is about whether severity levels should be mandatory or optional in CVEs of (stewarded) open source projects.

[rjb4standards]

@tobie Thanks Tobie, will do.
My customers don't need a severity score for a vulnerability, they only want to know if a product is trustworthy each day, and if it's not trustworthy then they need to know mitigating steps to prevent a cyber-crime disaster.

The original software supplier needs to provide the information to answer the question, "Is this software product trustworthy today, and if not what steps are needed to prevent a cyber crime disaster?" Trustworthy = not exploitable in this context.

[gregkh]

One other relevant point here, if a "estimate of criticality" is required, Linux, and many other open source projects, will just default to "SEVERE" or whatever the highest level is, in order to comply and be sure we got it correct.