Just because it has a CVE number doesn’t mean it’s exploitable. Of the 800 CVEs, which ones are in the KEV catalogue? What are the attack vectors? What mitigations are available?
The idea that it is somehow possible to determine that for each and every bug is a crazy fantasy by the people who don’t like to update to the latest version.
The fact that you think it’s not possible means that you’re not familiar with CVSS scores, which every CVE includes and which are widely used in regulated fields.
And if you think that always updating to the latest version keeps you safe then you’ve forgotten about the recent xz backdoor.
I am familiar with CVSS and its upsides and downsides. I am talking about the amount of resources required to determine that kind of information for every single bug, resources that far exceed the resources required to fix the bug.
New bugs are introduced in backports as well, think of that Debian issue where generated keys had flaws for years because of some backport. The idea that any version, whether the same you have been using, the latest one or a backported one, will not gain new exploits or new known bugs is not something that holds up in practice.
I don’t know where you got the idea that I’m arguing that old versions don’t get new vulnerabilities. I’m saying that just because a CVE exists it does not necessarily make a system immediately vulnerable, because many CVEs rely on theoretical scenarios or specific attack vectors that are not exploitable in a hardened system or that have limited impact.
And I am saying that that information you are referring to is unknown for any given CVE unless it is unlocked by some investment of effort that usually far exceeds the effort to actually fix it and we already don’t have enough resources to fix all the bugs, much less assess the impact of every bug.
Assessing the impact on the other hand is an activity that is only really useful for two things
a risk / impact assessment of an update to decide if you want to update or not
determining if you were theoretically vulnerable in the past
You could add prioritizing fixes to that list but then, as mentioned, impact assessments are usually more work than actual fixes and spending more effort prioritizing than actually fixing makes no sense.
Just because it has a CVE number doesn’t mean it’s exploitable. Of the 800 CVEs, which ones are in the KEV catalogue? What are the attack vectors? What mitigations are available?
The idea that it is somehow possible to determine that for each and every bug is a crazy fantasy by the people who don’t like to update to the latest version.
The fact that you think it’s not possible means that you’re not familiar with CVSS scores, which every CVE includes and which are widely used in regulated fields.
And if you think that always updating to the latest version keeps you safe then you’ve forgotten about the recent xz backdoor.
I am familiar with CVSS and its upsides and downsides. I am talking about the amount of resources required to determine that kind of information for every single bug, resources that far exceed the resources required to fix the bug.
New bugs are introduced in backports as well, think of that Debian issue where generated keys had flaws for years because of some backport. The idea that any version, whether the same you have been using, the latest one or a backported one, will not gain new exploits or new known bugs is not something that holds up in practice.
I don’t know where you got the idea that I’m arguing that old versions don’t get new vulnerabilities. I’m saying that just because a CVE exists it does not necessarily make a system immediately vulnerable, because many CVEs rely on theoretical scenarios or specific attack vectors that are not exploitable in a hardened system or that have limited impact.
And I am saying that that information you are referring to is unknown for any given CVE unless it is unlocked by some investment of effort that usually far exceeds the effort to actually fix it and we already don’t have enough resources to fix all the bugs, much less assess the impact of every bug.
Assessing the impact on the other hand is an activity that is only really useful for two things
You could add prioritizing fixes to that list but then, as mentioned, impact assessments are usually more work than actual fixes and spending more effort prioritizing than actually fixing makes no sense.
If I had a dollar for the number of BS CVE’s submitted by security hopefuls trying to pad their resumes…