Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.

I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)

There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)

Unfortunately, while cybersecurity is a real thing with real concerns and there are some amount of highly competent people, it's mostly, as a field, full of box-checkers and grifters. That lack of nuance or even attempt to understand if you are affected by a CVE or have other mitigations is unfortunately par for the course, even though its far below basic expectations.

Our internal "security team" actually put gcc (yes, that gcc) on the banned software list. It was overturned in short order when the entire engineering org suddenly wasn't allowed to compile software. Luckily I don't have to deal with that team directly, but it definitely means I have zero respect for that entire team and anything they have to say.

> I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs

This is true, but also: needless CVEs place a burden even on security teams who do take a nuanced view of CVEs - it requires some amount of effort to evaluate every CVE and determine whether it's applicable or not.

> Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward

Unfortunately, I've had many a frustrating session with compliance auditors who do not care that it couldn't affect you, you're required to meet the PCI-DSS deadlines of 90 days for low, etc, and I've seen security groups force to accept that this is what they have to do, and then get the unfortunate task of dealing with engineers pissed off that them for forcing them to what security is being forced to do. Everyone's a whole big bundle of happy joy joy, all because of some stupid auditor following a stupid (but well intentioned) checklist.

Even if the CVE doesn't currently apply to you, how can you be sure? Is the CVE in code that only runs on vmware; or does the code also run on EC2 - it will just be a few more weeks before someone figures out how to exploit it there.

Which is why the default answer for everybody should be fix the CVE. You should only ask "does this CVE affect us" in the case where the fix in some way is a negative to you.

Of course one downside might be risks of upgrading and so if you determine this affects us it means you would risk updating with less verification even though the update might break something else. If the issues doesn't affect you a longer process to verify nothing breaks is safe.

As someone who has to respond for this kind of stuff at work, I am regularly in a situation where I am pushing back on a CVE, or telling them that our product neither uses nor installs that package (or its for a different OS entirely).

Our product is run in a moated environment, most systems have the same username and passwords (customers never change the defaults), so I only really care about RCE's even if it is an effected package.

The problem of CVE inflation is not just that you might be forced to patch a CVE that is not applicable to your product. Even investigating to understand whether a CVE is applicable or not takes time, and is simply not worth it for obscure issues like the one in this bug.

It sounds like the only end result of this is them making the bureaucracy even more bureaucratic by employing their own agents, where the only way to get anything done is to have your agents fight their agents.

Frankly, it feels like Kafka was actually an optimist.

There was a recent article in The Economist about people fighting employment disputes with AI (https://archive.ph/mi3zu). On the one hand, democratizing the system, on the other hand filling it with massive quantities of legally questionable slop.

Unless it's a critical CVE, they're worth very little now for your career.

Same for a lot of side projects or small contributions to OSS, people are still chasing them and wasting everyone's time for nothing. They wouldn't even work on them before AI.

In a way I think the false promise of open source that someone else would have gone through the code is actually going to come true as LLM would have gone through the code.

First thing that came to my mind... why people are so self-centric... and yet, somehow, you feel bad because the same people flex with these CVEs while you can't tell a single huge one you had found under NDAs, while they keep downplaying or ignoring you. I think its better to treat these people as less professional, and try to influence the common reception what is actually professional and what is not.

Or they had a bet in a prediction market.

According to the linked article, that’s exactly what they did. It was a legitimate bug, but the security consequences were lower than low. It’s a code quality issue, not a security issue, but both are worth fixing.

I don't see how that correlates, and that's already pretty much what they do anyway. The reporter's issue wasn't that it didn't get fixed (it did), but that it wasn't given a CVE.

If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time. So it's very much worth it, and I, for one, am very grateful for it.

And make no mistake - havin every user of curl spend time to read this CVE and decide that it doesn't affect that would be 10000% wasted effort for each and every one of them.