CVE-2020-19909 is everything that is wrong with CVEs
https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/
The author has a point that the NVD has no clue about the security implications of a bug. But can we really expect them to? At a conservative guess, I’d say there are millions of pieces of code floating around. Should the NVD be deeply involved in all of them just to provide the most accurate security score? That’s an impossible ask.
The author also takes issue with the NVD’s stance that they cannot just trust any dude’s email. Is that not a fair take? “Trust me. I’m the maintainer of this project. Do as I say.” Should the NVD now also check each and every email they receive for forgeries? Should they assume that the author of the email would write an assessment in good faith and not downplay a real threat because it looks bad for their project?
My claims above about this issue can of course be verified by reading the publicly available source code and you can run tests to reproduce my claims.
(That quote is from another of his blog posts [daniel.haxx.se].) Now this is really ludicrous in my opinion. You cannot expect any outsider to read the internals of “over 160,000 lines of feature packed C code (excluding blank lines)” to verify a claim. There is simply not enough time on the NVD’s hands.
I’m happy I learned something about these magical CVE numbers. My takeaway from this is: The database is good, the scores may not be.
The last place I worked, we had a cyber security team, whose job it was to send us CVEs to investigate. I mean random CVEs that had zero relevance to our systems or the technologies we used. Sometimes they sent us low level kernel type CVEs and expected us to explain why we weren’t affected. Mostly it was a waste of time. If they knew how to do their job, they’d have a list of technologies we used on each project and could filter out the irrelevant stuff, instead of wasting developer time.
Grrrrrr!!
By definition, that is not a CVE (common vulnerability and exposures). What is NIST doing??
ugh, I’m glad i’ve moved on from IT but I’ve had many arguments with ‘security managers’ about some bogus qualys findings. If the CVE is that a user could do a thing in an unexpected way, but they have permission to do the thing that is a bug not a vulnerability. IMO It’s only a vulnerability if someone that is not allowed to do something can do the forbidden thing.