71–80 of 116 posts
This article does a good job explaining the Linux kernel position on cves: https://lwn.net/Articles/961978/ The relevant part: > Kroah-Hartman put up a slide showing possible "fixes" for CVE numbers. The first, "ignore them", is more-or-less what is happening today. The next, option, "burn them down", could be brought about by requesting a CVE number for every patch applied to the kernel. They intend to burn down the…
Earlier quoted context omitted.
you’re missing the CVSS aspect which is intrinsically tied to CVE issuance (atleast when issued through the CNA-LR). It’s not _just_ an identifier, it’s a entirely valid and useful tool of triage and classification
CVSS is a Ouija board. Nobody takes it seriously. It was also introduced long after CVEs were. And even if it was meaningful --- it isn't, but stipulate --- it wouldn't change the fundamental point of CVEs.
Undercutting my own point though, it doesn’t hurt to rerun a calculation if you think the public vectors is “lacking” or if temporal/environmental metrics matter in your context
Earlier quoted context omitted.
CVSS is a Ouija board. Nobody takes it seriously. It was also introduced long after CVEs were. And even if it was meaningful --- it isn't, but stipulate --- it wouldn't change the fundamental point of CVEs.
CVSS as practiced sucks sometimes, the rules around not chaining vulnerabilities to up a score are rarely followed, but as specified it’s actually a good system. Undercutting my own point though, it doesn’t hurt to rerun a calculation if you think the public vectors is “lacking” or if temporal/environmental metrics matter in your context
I feel like I'm on reasonably safe ground when I say that my take on CVSS is a mainstream one in the field.
Earlier quoted context omitted.
There are many more good and useful CVEs. I'd also kindly request you to suggest a better system.
Filing a CVE used to be a dialog between the researcher, developers, and third-party domain experts. Accepting every random LLM-generated report and granting it a 9.8 score is not useful in any way. I have to patch hundreds of CVEs in a month, and only a handful are actually valid. The vast majority is "CVSS 9.8: regex complexity explosion in $library" which my project only uses during build. But I've got to patch it…
Earlier quoted context omitted.
CVSS as practiced sucks sometimes, the rules around not chaining vulnerabilities to up a score are rarely followed, but as specified it’s actually a good system. Undercutting my own point though, it doesn’t hurt to rerun a calculation if you think the public vectors is “lacking” or if temporal/environmental metrics matter in your context
I would be interested in seeing a professional vulnerability researcher of any note jumping in here to make a defense of CVSS. I'd rebut, respectfully, if they did. But I don't expect it to happen, despite that there are plenty of researchers on HN. I feel like I'm on reasonably safe ground when I say that my take on CVSS is a mainstream one in the field.
For example, what does Network vs Local vs Physical mean if it's an exploit in a cloud microservice?
Ooh let me consult the tea leaves. What's that? They consider it "Network" even though it's S3 mounted locally as a filesystem? Now that sev:med looks like a sev:crit.
The known alternative to CVSS is to rate severity levels entirely on vibes, and I find vibes to be more accurate.
Earlier quoted context omitted.
There's a good-faith community norm that CVEs are for bugs that the reporter believes are security-related. Sure, that norm is regularly violated, but community standards always are and it doesn't diminish their value.
CVEs have been filed for e.g. memory corruption issues with no known exploit or even plausible path to exploit since time immemorial, or at least since time-since-CVE-was-invented. The idea that there is a burden of proof or certainty required to number something with a CVE is a commercial vendor invention. It's easy to see why people want CVE to work that way! It implies that people numbering potential security issu…
Cynically, I'd bet there are more than a few less technical but academic operators on the board who would run this play.
Earlier quoted context omitted.
Most people don't get a choice of which legislation/regulations to comply with.
There's plenty of people in that position, but they're all working at huge corporations. Nobody ends up having to chase things like SOC2 and PCI-DSS without getting paid for it. Why should unpaid volunteers working on the Linux kernel do compliance work for FAANG-sized companies without getting paid for it? If these companies want the reports carefully triaged, they can send some employees to carefully triage them.
A vulnerability / bug in an upstream component may or may not end up being a vulnerability in a complex system incorporating that component. A vulnerability in upstream functionality that is disabled (or not used, with no possible path through which an attacker could trigger the upstream vulnerability) in a particular system is not a vulnerability in that system. Standards like ISO27001, SOC2, and PCI-DSS generally ask teams to have processes to discover vulnerabilities, but not necessarily to patch things that are not vulnerabilities in practice.
The purpose of CVEs is to ensure that people discussing vulnerabilities are talking about the same thing. CVEs aren't a checklist, they aren't a perfect enumeration, and it shouldn't matter if a CVE is issued for a nonissue. People who are burdened by requirements to ship (or produce rolling updates) to address every Linux kernel CVE are living in a state of sin. It doesn't make sense for the kernel CNA to alter its…
The problem here seems to be fear over how EU legislators and judges will interpret CVEs more than anything the kernel is doing. Looks like a complex and legally risky situation; good luck to the EU devs, hope it stays as a theoretical concern. I imagine common sense will prevail and the law will be interpreted the sensible way.