[HN Gopher] NIST gives up enriching most CVEs
___________________________________________________________________
NIST gives up enriching most CVEs
Author : mooreds
Score : 154 points
Date : 2026-04-17 15:09 UTC (7 hours ago)
(HTM) web link (risky.biz)
(TXT) w3m dump (risky.biz)
| DeepYogurt wrote:
| Long overdue to be honest.
| rwmj wrote:
| https://archive.ph/S8ajd
|
| "Enrichment" apparently is their term for adding detailed
| information about bugs to the CVE database.
| smsm42 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| My favorite: a Linux kernel pcmcia bug. On EC2 VMs.
| Sohcahtoa82 wrote:
| In a similar vein:
|
| Raising alarms on a CVE in Apache2 that only affects
| Windows when the server is Linux.
|
| Or CVEs related to Bluetooth in cloud instances.
| minetest2048 wrote:
| Or raising alarm on a CVE in linux mlx5 driver on an
| embedded device that doesn't have a pcie interface
| nikanj wrote:
| "If you use that installed Python version to start a web
| server and use it to parse pdf, you may encounter a
| potential memory leak"
|
| Yeah so 1) not running a web service 2) not parsing pdf
| in said non-existing service 3) congrats you are leaking
| memory on my dev laptop
| jjav wrote:
| Very early in my career I'd take these vulnerability reports
| as a personal challenge and spent my day/evening proving it
| isn't actually exploitable in our environment. And I was
| often totally correct, it wasn't.
|
| But... I spent a bunch of hours on that. For each one.
|
| These days we just fix every reported vulnerable library,
| turns out that is far less work. And at some point we'd
| upgrade anyway so might as well.
|
| Only if it causes problems (incompatible, regressions) then
| we look at it and analyze exploitability and make judgement
| calls. Over the last several years we've only had to do that
| for about 0.12% of the vulnerabilities we've handled.
| rdtsc wrote:
| > 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 wrote:
| 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 wrote:
| 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
| michaelt wrote:
| _> 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._
|
| That sounds like a nigh-impossible requirement, as you've
| written it.
|
| I suspect the actual requirement is much more limited in
| scope.
| LocalH wrote:
| Also, sometimes CVEs aren't really significant security issues.
| See: curl
| moomin wrote:
| Pretty sure if I had to bet on incentives or expertise, I'd bet
| on incentives every time.
| j16sdiz wrote:
| TBH, I don't see much enrichment they are giving in last 5 or 6
| years.
| Retr0id wrote:
| Maybe we should just assign UUIDs
| woodruffw wrote:
| 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 wrote:
| > 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 wrote:
| NIST does many other things in addition to handling the CVE
| database.
| tptacek wrote:
| Like producing the world's most premium peanut butter!
|
| https://shop.nist.gov/ccrz__ProductDetails?sku=2387
|
| (The only problem with it is that it's backdoored the NSA.)
| prophesi wrote:
| Assuming this is in reference to the great Veritasium
| video[0] going over what these reference materials are used
| for and why they're so expensive.
|
| [0] https://www.youtube.com/watch?v=esQyYGezS7c
| lesuorac wrote:
| You mean to tell me that the peanut butter at my store
| has junk besides peanut butter in it?
|
| I'm gunna call RFK right now and tell him to fix this!
| chuckadams wrote:
| https://shop.nist.gov/ccrz__ProductDetails?sku=2782&cclcl=e
| n...
|
| Who doesn't love a jar of Industrial Sludge?
| dragonwriter wrote:
| > but from a superficial glance it kind of seems like trying to
| cut down on standards or efficiency.
|
| That's kind of the norm in the current US administration, so it
| shouldn't be surprising.
| tptacek wrote:
| 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.
| pimlottc wrote:
| What is the data that NIST is adding for enriched entries?
| khalic wrote:
| 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 wrote:
| I was always wondering - are there alternative lists like this?
|
| Maybe not in english or smth
| dlor wrote:
| 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.
| DeepYogurt wrote:
| CPE is a joke. The offical spec doc asserts that correctness of
| names is not in scope for the spec. See section 5. Well-Formed
| CPE Name Data Model
|
| https://csrc.nist.gov/pubs/ir/7695/final
| strenholme wrote:
| The deluge of new security reports is somewhat of a pain in the
| butt for those of us who have written notable open source
| software decades ago that is still in use. I recently got about a
| dozen reports from one reporter, and they look to be AI-assisted
| reports.
|
| Long story short, the reports were things like "If your program
| gets this weird packet, it takes a little longer than usual to
| free resources". There was one supposed "packet of death" report
| which I took seriously enough to spend an afternoon writing a
| test case for; I couldn't reproduce the bug and the tester
| realized their test setup was broken.
|
| There seems to be a lot of pressure for people to get status by
| claiming they broke some old open source project, to the point
| people like me are getting pulled out of retirement to look at
| issues which are trivial.
| deckar01 wrote:
| Mitre used to issue CVEs within 24 hours. I am going on 4 months
| now with no follow up, and no way to tell them GitHub issued a
| CVE already... I'm pretty sure they were just rubber stamping
| before. Considering disclosure normally should be coordinated
| with maintainers, 3rd parties like Mitre don't seem to have much
| to offer or much to gain other than being a bottleneck.
| a34729t wrote:
| Honestly im surprised private industry doesnt take this over.
| Everybody already has their enriched, supplemental data on top
| of the Mitre/NVD definitions.
| lo_zamoyski wrote:
| I can't parse this grammatically-tortured title.
| pojzon wrote:
| Im close to Security MVP for EU parliment, listening on weekend
| bbq how stupid and pointless vast majority of CVEs are and how
| stupid and pointless majority of reports are - thank god someone
| wants to put an end to this.
|
| Majority of researchers dont care how important the bug is,
| everyone wants something to put on CV, they get paid extra by
| companies to finding bugs in SAP or SalesForce that will never
| ever ever be used for anything.
|
| Pointless moot just to generate noice. Like 90% of whole infosec
| sector.
|
| At least thats what I understood from discussions with someone
| who has many nations security at stake at work.
___________________________________________________________________
(page generated 2026-04-17 23:00 UTC)