Hacker News Reader

"The social issue continues in that people want some quick and easy to understand number, because they and their company also cannot process in a short time if these security vulns are substantial or not.

"

Uh, none of this explains why they re-score the vulnerabilities themselves, ignoring the vendor scores and deciding they know best, when they seem to know ... nothing.

Which if you read through the links, you'll see is one of the main complaints, and something they document here:

https://nvd.nist.gov/general/FAQ-Sections/CVE-FAQs#faqLink9

Their take is basically "we get to do this and if it's wrong it's your problem to get us to correct us".

That doesn't make any sense.

As my child's kindergarten teacher once asked a student: "Do you think if everyone decided to do that, it would turn out okay?"

NVD and CVE teams will simply never have the expertise or time or information necessary to actually re-score these things correctly. You'll also note that despite claiming they score things based on publicly available information, and that othres must do the same, they cite absolutely no sources to Daniel to defend their scoring.

They light themselves on fire, generate smoke and noise that others have to deal with, and then complain that it's the job of others to put it out.

The gaming of the system is the reason they rescores themselves and do not take a vendors statement as fact. There's a long history of vendors underreporting and underscoring their security issues.

So?

That's a different problem to deal with a different way.

People keep lying to me, so i'm going to ignore what they tell me and make it up myself doesn't seem like it's going to generate great results.

Put another way - "NVD making stuff up that is not accurate" is not a solution for "other people making stuff up that is not accurate".

If you want responsibility, you have to incentivize it somehow, whether carrot or stick. This doesn't achieve that. They can tell their customers whatever they want, and then blame any difference on NVD being mean.

>> vendors underreporting and underscoring their security issues

> So?

So he comprehensively refuted your point by explaining why

No, he called out the obvious reason why NVD would decide it needs to operate this way, without acknowledging that the process they've come up with doesn't work, and is sort of an industry embarassment.

The root of the problem is that if NVD lacks the resources to adequately assess CVEs, then they can't do better (well-intentioned or not!) than what the vendor reports, and them trying to do so only adds more noise.

Sure the vendors have motive to underestimate, but they're also far better equipped to accurately assess severity. Better to focus on them and hold them accountable.

I think the implied premise is that vendors are likely to score with a low bias, downplaying security vulnerabilities.

If NVD completely re-scored submitted CVEs from scratch, then they'd replace a biased dataset with a noisier but unbiased dataset.

On the other hand, if NVD accepts high severities and only re-scores low severity CVEs, then the collected database might exchange a low-severity bias for a high-severity bias.

> I think the implied premise is that vendors are likely to score with a low bias, downplaying security vulnerabilities.

Indeed. It occurs to me that there's a possible feedback loop here. To the exent that NVD increases the severity of all (or even some) CVEs, they are effectively increasing the incentive for vendors to report lower severities, since the vendors may rightly assume that NVD will inflate the severity anyway.

If vendors were responsible -- and known to be responsible -- for scoring their own security issues, then everyone would at least know that, and understand that the vendor's assessment could be biased.

Instead, many people seem to believe they can blindly trust NVD, when their severity assessment is arbitrary and based on wild guessing. And individuals at NVD probably have their own biases as well!

Disclaimer:

I had worked for Red Hat prodsec for 6 years doing the kernel work. It is common that I regularly resubmit rescores requests to CVSSv3 to NVD, they seem to be pretty good about it when it is clearly explained.

NVD will sometimes consider flaws scoring it the 'general' use case not in the specific use case which can make scoring libraries environment and usage specific.

Can you - by any chance - talk about the tooling you used in that work (as in: the tech behind https://access.redhat.com/security/cve/cve-2023-34416 ). I assume it's all custom but we're looking for something just like it: https://news.ycombinator.com/item?id=36311682

If you're willing to you can find my contact details in my profile. Thanks!

I am sure there are somewhat reasonable people on the other side. But it doesn't make it a sane process :)

Making your own stuff up is not a solution for other people making stuff up or underselling things.

I have to agree, publishing your own scoring is not ideal however it is sometimes specific to the use case. This is one of the reasons why people are uncomfortable with CVSS, some scorers consider the general case, some scorers consider the actual used case.

It's the inverse of the "boy crying wolf" - if they mark a vulnerability low and it ends up being the next log4shell, they look really bad and the organization may be effectively over.

But if they rank everything "7+" then they have plausible deniability.

So everything will be ranked 7-10. Meaning 1-6 are useless.

That was my thought too. Imagine someone at some desk in some drab office building with a huge pile of these to sort though. Different libraries, languages, frameworks etc. They probably have some quota to fill. How motivated are they going to be find out who the authors are, how to contact them, compose a long message, explaining, asking questions? Nah, just look at the code, google a few things, and assign as high of a score as possible. Nobody needs to have someone come and yell at them for assigning a 3 to the next log4shell.

They could have a tiered system where at least things that have deployments in the billions get a special treatment. Holidays can be cancelled, releases rescheduled over a bad enough vulnerability in a sufficiently common software. Miscoring a vulnerability makes a thing that is supposed to be good, by promoting a more secure ecosystem, end up being actually bad, wasting resources that could have been spent on solving actual issue. Not even speaking about the lowered trust in NVD...

So stop assessing severity. Rather than do a shitty job, say nothing, like: "Severity not assessed"

Interesting thought. The lack of rating might cause rating authorities to pop up and compete with each other for accuracy.

If the scores really mean that little, then the service is doing more harm than good. Spreading lots of false information is not better than nothing.

Obviously this comes down to how often they're wrong and by how much.