> Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore.

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. For instance, one time we had a security team that required us to patch a vmware support package that was installed by default on ubuntu, but the CVE required being ran on vmware when we were running on EC2. Arguing with them was pointless because they were not interested in determining if the CVE applied to us, only that it needed fixed.

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. In some cases, like in the case of easy to update and centrally deploy SaaS products, that burden is more annoying and frustrating than difficult. In some cases, like when you have complicated deploy or have customer-controlled updates, those mandates cause a huge burden on teams not producing the decision to patch every low CVE.

▲

brewmarche 4 hours ago | parent | next [-]

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)

▲

roenxi 3 hours ago | parent | next [-]

> An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index.

https://nvd.nist.gov/vuln/detail/cve-2018-20225

Because I'm sure the public wants to know.

	▲	kernelbugs 2 hours ago \| parent [-]
		To be fair this behavior + extra-index-url definitely allowed for dependency confusion attacks. Now it's a bit silly for the CVE as written, but IIRC this was before you could use index-url to point exclusively to an internal package host so there were (and in other ecosystems still are) dependency confusion attacks going on in the wild where attackers are publishing "internal-package-a@999.9.9" on any public package host (NPM, PyPi, etc) to try to compromise companies that have internal packages of the same name.

▲

dataflow an hour ago | parent | prev [-]

I don't understand what's ridiculous about that pip CVE, could you explain? Just because something is by design that doesn't mean it's not a vulnerability or somehow unexploitable.

	▲	brewmarche an hour ago \| parent [-]
		Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can you do about it as a dev given that the pip maintainers have decided not to fix it? The only option is not to use pip at all (and sure, you can see the CVE as a critique of pip in a way), or discuss with your security team in hope for some exclusion. And since pip or at least ensurepip are part of Python you get a lot of these scan results E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct

▲

coldpie 2 hours ago | parent | prev | next [-]

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.

▲

justusthane 4 hours ago | parent | prev | next [-]

> 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.

▲

rotis 2 hours ago | parent | next [-]

In many (most?) companies it also takes nontrivial amount of time to patch potentially affected systems. In my company half IT department got recently an email that we need to urgently patch all Windows servers because of some critical CVE. I checked it. The description was maybe 3 lines and it said this affected domain controllers only. I raised this with security team and they said that in this case we don't need to patch everything. Now if we had to do this, it would force us to spend nontrivial time on unplanned patching. That this in itself disorganizes our operations can not be ignored. So comparatively me doing some legwork and checking the CVE was trivial effort and saved a lot of busywork for the department as a whole. That time we got lucky.

	▲	bluGill 2 hours ago \| parent [-]
		If something is hard do it more often so you get good at it. While this time you avoided something, it sounds like you need to figure out your patching process ASAP. There is every reason to believe a major issue will affect everything in the near future.

▲

ealready_value 3 hours ago | parent | prev [-]

Absolutely. I was focused on the burden CVEs place on everyone downstream of teams that don't take a nuance view, but even when teams do look at all the CVEs reported in scans, the proliferation of CVEs just adds workload to determine if they are affected. Unless teams say they will not look at lows (or lower-than-lows if the category existed) then what amounts to busy-work just piles up.

▲

nazgulsenpai 28 minutes ago | parent | prev | next [-]

I have the email response explaining what a backport is saved as a template because i have to send it so many times :)

▲

tsimionescu 3 hours ago | parent | prev | next [-]

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.

▲

Twirrim 2 hours ago | parent | prev | next [-]

> 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.

▲

bluGill 2 hours ago | parent | prev | next [-]

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.

▲

tetha 2 hours ago | parent [-]

This becomes fun if you start to prioritize security work on CVEs rated higher, not affecting you, over security work on CVEs rated lower and affecting you.

Or prioritizing chasing CVEs currently not affecting you over architectural work improving security.

The CVE should be fixed, I fully agree, but where does it land as a priority? Less competent security teams push /all/ CVEs as Sev0 over /all/ other topics.

	▲	bluGill an hour ago \| parent [-]
		I don't have a good answer to this problem. The reality is security is becoming very important - for good reasons. If you (as an organization) are spending all your time chasing CVEs instead of the other useful things (such as what you named) you have a problem, but not fixing CVEs right away is a terrible answer. There is some hope that LLMs have found most of the existing issues and things will settled down - but only time will tell if this becomes true or not.

▲

Aloha 2 hours ago | parent | prev | next [-]

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.

▲

tristor an hour ago | parent | prev [-]

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.