What's wrong with CVEs? Daniel Stenberg of cURL wants you to know | Hacker News Reader

What's wrong with CVEs? Daniel Stenberg of cURL wants you to know

podcast.sustainoss.org

58 pointsjdorfman16 comments

His earlier blog post on the topic: https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve...

And thread here: https://news.ycombinator.com/item?id=37394919

The security industry has perverse incentives, and from what I have seen, these bounty systems which have been pushed for in recent years have made it worse. Not only do we have more of an incentive for these bogus security events, which waste real engineering hours across the economy thanks to automated systems, but we also now see researchers campaigning publicly against companies when their bounty is denied for this sort of thing. Just a total waste of time and effort, which creates a boy-who-cried-wolf mentality amongst the engineers fixing these issues whenever a breathless researcher shows up with a new "CRITICAL" vulnerability.

Been dealing with the same stuff across multiple very popular repositories for years now. I've lost most faith in the CVE system and overall tend to take reports significantly less seriously than when I first started receiving them.

Most other maintainers I've talked to feel very similarly. I just had an interview with a research group a few days ago who said this wasn't an unpopular opinion, either.

This approach to security is extremely harmful overall, and I'm glad Daniel is speaking frankly about it. He's spot on.

It will be interesting to see if created sub-CNAs (CVE Numbering Authorities) will indeed allow upstream projects to get more control over the CVE assignment for their software. In theory, the existence of the sub-CNA should block assignment from less specific CNAs, but I wouldn't be surprised if that doesn't actually happen.

The cool kids are looking at KEVs: https://www.cisa.gov/known-exploited-vulnerabilities

These bogus CVEs have real downstream effects - if you have say, a compliance team that wants every docker and base os image to be updated to patch every CVE over a certain level. False security through process.

Is that really a problem with the CVEs, though?

That sounds more like a problem with the compliance team in question having policies that are flawed in one or more ways.

One entity blindly/inflexibly/irrationally/wrongly reacting to some other entity's proclamation isn't the fault of the entity making the proclamation.

The lack of granularity in CVE's alongside their accepted authority enables clumsy, brute-force compliance procedures and gives them teeth. The two are tied together.

Exactly - there can be no argument allowed, because the issue is so “severe”.

Just try working with banks around this...

Bank "Your container is showing this CVE"...

Us: "Any container that uses library X will show this CVE"

Bank "You have to get rid of the CVE"

Us: "You cannot get rid of that CVE because your software checks for the existence of the library, not the existence of a potentially weak configuration that could cause a problem. This is like saying we have to get rid of the car because it contains gas, rather than ensuring we have safe gasoline storage practices"

The CVE game is brutal and favours unrecognized unknown bugs (and security risks) over handling recognized flaws that might get a high score but are totally irrelevant in your context.

Can you explain that second half a bit more?

Was that point meant to be reversed … favors the irrelevant over the unknown?

Valid points to problems that have been debated for decades.

Yeah hopefully this discussion can help shine a light on this issue. Maintainers have enough to deal with.

Reply on news.ycombinator.com