The bogus CVE problem [LWN.net]

The bogus CVE problem

Posted Sep 14, 2023 9:37 UTC (Thu) by ringerc (guest, #3071)
In reply to: The bogus CVE problem by wtarreau
Parent article: The bogus CVE problem

The CVE noise is ridiculous. My org spends so much time and effort "fixing" these "vulnerabilities" that it has little left over for *actual real security efforts*.

They've decided it's too hard to classify the balance of supposed vulnerabilities, so they're just going to take the severities as fact, irrespective of where the component lives in our stack.

"Critical" vuln in a completely unrelated part of a golang executable that happens to share the same huge monorepo as a library we use? Everybody panic, rush to upgrade everything to the latest no matter what the breakage, even though we probably don't use it. Used by a 3rd pty component that didn't jump fast enough? Fork it and hack it.

Then we have all these mini forks of various 3rd party components sitting around rotting. Or they decide it's too hard to keep up with "security" for a perfectly good external component and rewrite it in-house, badly. No more CVEs because nobody's looking anymore! It's less secure, but we made the squeaky wheel go away. Go us.

They've also rolled out various mandatory and enforced static checkers and linters with centrally managed one-size-fits-all configs. The stupid things run on pull requests and they don't compare the pull request results to a scan of main with the same config and db version. So whenever the vendor or info-"security" management rolls out new config/dbs, totally unrelated changes become unmergeable. Sure you could raise a new separate PR to patch main then rebase your change. But you've got a gauntlet of Jira ticket workflow requirements, encorced pull request reviews from people who're often unavailable, slow unreliable GitHub workflows, etc. Who's got time for that? So we have PRs "fix off by one in A" that have 200 lines of completely irrelevant noise "fixing" meaningless non issues. They obscure the real changes and introduce new bugs.

Yay management of developers by non developers, and management of IT security by people who couldn't explain the difference between authentication and authorisation if you gave them a textbook first.

to post comments

The bogus CVE problem

Posted Sep 14, 2023 15:39 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (2 responses)

I feel sorry for you, really. It must be quite frustrating to work in your company :-(

The bogus CVE problem

Posted Sep 20, 2023 14:21 UTC (Wed) by bearstech (subscriber, #160755) [Link] (1 responses)

I work for companies who misconduct in that way, so the problem might spread to your company without your consent. At least I got to bill them for handling that nonsense bureaucracy.

The main flow of alerts/requests I've been handling for close to a year is composed of ... requests to add anti-XSS HTTP headers. By far. At the same time I got _zero_ status requests on the Zenbleed/Inception mayhem from this summer. The cultural gap is that wide.

In my case the problem is clearly companies who want to adopt security policies but are no trained on computer security. I can't blame them except their CTO which most of the time is totally missing the point while thinking that security is just another component that need dashboards and reports, and done.

CVE ranking is conceptually wrong, a security issue must be evaluated with context and is multi-faceted, there should never be a single figure in the first place. When talking with a dev or project manager I can educate about those issues and explain them how to handle a specific security issue in context, that's often satisfying for both parties. But then it won't bubble up to the top management and against the solidified bureaucracy they call security policy.

The bogus CVE problem

Posted Sep 29, 2023 4:01 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

I totally agree with what was said above!