Rendered at 18:39:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
smsm42 3 hours ago [-]
> This opens the door for a lot of infosec drama. Some of the organizations that issue CVE numbers are also the makers of the "reported" software, and these companies are extremely likely to issue low severity scores and downplay their own bugs.
It is true but the reverse is also true. It may be very hard for an external body to issue proper scoring and narrative for bugs in thousands of various software packages. Some bugs are easy, like if you get instant root on a Unix system by typing "please give me root", then it's probably a high severity issue. But a lot of bugs are not simple and require a lot of deep product knowledge and understanding of the system to properly grade. The knowledge that is frequently not widely available outside of the organization. And, for example, assigning panic scores to issues that are very niche and theoretical, and do not affect most users at all, may also be counter-productive and lead to massive waste of time and resources.
zbentley 2 hours ago [-]
Very true. So many regulated/government security contexts use “critical” or “high” sev ratings as synonymous for “you can’t declare this unexploitable in context or write up a preexisting-mitigations blurb, you must take action and make the scanner stop detecting this”, which leads to really stupid prioritization and silliness.
gibsonsmog 2 hours ago [-]
At a previous job, we had to refactor our entire front end build system from Rollup(I believe it was) to a custom Webpack build because of this attitude. Our FE process was completely disconnected from the code on the site, existing entirely in our Azure pipeline and developer machines. The actual theoretically exploitable aspects were in third party APIs and our dotNet ecosystems which we obviously fixed. I wrote like 3 different documents and presented multiple times to their security team on how this wasn't necessary and we didn't want to take their money needlessly. $20000 or so later (with a year of support for the system baked in) we shut up Dependabot. Money well spent!
lokar 59 minutes ago [-]
My favorite: a Linux kernel pcmcia bug. On EC2 VMs.
moomin 5 minutes ago [-]
Pretty sure if I had to bet on incentives or expertise, I'd bet on incentives every time.
rdtsc 1 hours ago [-]
> It is true but the reverse is also true.
Yup. Almost every single time, NVD came up with some ridiculously inflated numbers without any rhyme or reason. Every time I saw their evaluation it lowered my impression of them.
semi-extrinsic 40 minutes ago [-]
Every month when there is a new Chrome release, there is a handful of CVSS 9.x vulnerabilities fixed.
I'm always curious about the companies that require vendors to report all instances where patches to CVSS 9.x vulnerabilities are not applied to all endpoints within 24 hours. Are they just absolutely flooded with reports, or does nobody on the vendor side actually follow these rules to the letter?
PunchyHamster 27 minutes ago [-]
the rating is nonsense anyway, which one actually applies to code you run varies wildly
9.x vulnerability might not matter if the function gets trusted data while 3.x one can screw you if it is in bad spot
LocalH 36 minutes ago [-]
Also, sometimes CVEs aren't really significant security issues. See: curl
dlor 5 minutes ago [-]
Enriching does a few things, but the main ones are adding CVSS information and CPE information.
CVSS (risk) is already well handled by other sources, but CPE (what software is affected) is kind of critical. I don't even know how they're going to focus enrichment on software the government uses without knowing what software the CVEs are in.
tptacek 2 hours ago [-]
The NVD was an absolutely wretched source of severity data for vulnerabilities and there is no meaningful impact to vendors/submitters supplying their own CVSS scores, other than that it continues the farce of CVSS in a reduced form, which is a missed opportunity.
j16sdiz 2 hours ago [-]
TBH, I don't see much enrichment they are giving in last 5 or 6 years.
khalic 50 minutes ago [-]
I can’t help but draw a connection with the numerous budget cuts from this admin, including the almost-crisis from last year with NIST.
RandomTeaParty 28 minutes ago [-]
I was always wondering - are there alternative lists like this?
"Enrichment" apparently is their term for adding detailed information about bugs to the CVE database.
pimlottc 1 hours ago [-]
What is the data that NIST is adding for enriched entries?
DeepYogurt 3 hours ago [-]
Long overdue to be honest.
Retr0id 2 hours ago [-]
Maybe we should just assign UUIDs
woodruffw 54 minutes ago [-]
Separate from everything else, this would have the virtuous effect of reducing clout-chasing via CVE IDs. It's not quite as cool (for some definition of "cool") to have 095503C9-B080-4C43-AAB6-B704DEB2FAF7 on your resume as it is to have CVE-20XX-YYYYY.
shevy-java 2 hours ago [-]
> Going forward, NIST says its staff will only add data—in a process called enrichment—only for important vulnerabilities.
Now - I am not saying I disagree with everything here, mind you; I guess everyone may agree that CVEs may range in severity. But then the question also is ... what is the point of an organisation that is cut down to, say, handle 1% of CVEs - and ignore the rest? Why have such an organisation then to begin with?
I don't have enough data to conclude anything, but from a superficial glance it kind of seems like trying to cut down on standards or efficiency.
tsimionescu 1 hours ago [-]
NIST does many other things in addition to handling the CVE database.
tptacek 58 minutes ago [-]
Like producing the world's most premium peanut butter!
It is true but the reverse is also true. It may be very hard for an external body to issue proper scoring and narrative for bugs in thousands of various software packages. Some bugs are easy, like if you get instant root on a Unix system by typing "please give me root", then it's probably a high severity issue. But a lot of bugs are not simple and require a lot of deep product knowledge and understanding of the system to properly grade. The knowledge that is frequently not widely available outside of the organization. And, for example, assigning panic scores to issues that are very niche and theoretical, and do not affect most users at all, may also be counter-productive and lead to massive waste of time and resources.
Yup. Almost every single time, NVD came up with some ridiculously inflated numbers without any rhyme or reason. Every time I saw their evaluation it lowered my impression of them.
I'm always curious about the companies that require vendors to report all instances where patches to CVSS 9.x vulnerabilities are not applied to all endpoints within 24 hours. Are they just absolutely flooded with reports, or does nobody on the vendor side actually follow these rules to the letter?
9.x vulnerability might not matter if the function gets trusted data while 3.x one can screw you if it is in bad spot
CVSS (risk) is already well handled by other sources, but CPE (what software is affected) is kind of critical. I don't even know how they're going to focus enrichment on software the government uses without knowing what software the CVEs are in.
Maybe not in english or smth
"Enrichment" apparently is their term for adding detailed information about bugs to the CVE database.
Now - I am not saying I disagree with everything here, mind you; I guess everyone may agree that CVEs may range in severity. But then the question also is ... what is the point of an organisation that is cut down to, say, handle 1% of CVEs - and ignore the rest? Why have such an organisation then to begin with?
I don't have enough data to conclude anything, but from a superficial glance it kind of seems like trying to cut down on standards or efficiency.
https://shop.nist.gov/ccrz__ProductDetails?sku=2387
(The only problem with it is that it's backdoored the NSA.)
That's kind of the norm in the current US administration, so it shouldn't be surprising.