Comment by DannyBee | Hacker News Reader

Comment by DannyBee | Hacker News Reader

Parent Full thread

"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.

Reply on news.ycombinator.com