I am assuming that many of these are found with automatic analysis tools that are very creative (i.e. LLMs) and there may be a high proportion of very "cornered" cases. I think there needs to be a triage method that would amount to the severity, likeliness, and detection dimensions used to rank risks in a systematic framework [1]. I think if this could be submitted (or estimated) along with such bug reports, it could go a long way toward sustainable intake patterns for this number of possible defects.

[1]: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...

▲

petra303 6 hours ago | parent | next [-]

In my company, the security team isn’t technical. They see CVE, find a vulnerable system, it gets flagged. We have to patch it.

We patched for a CVE last week that a malicious usb sound card device could be use the gain root.

On a Vm? Is that something we really need to worry about??

▲

lousken 5 hours ago | parent | next [-]

They see their dashboard, when the number is high, they want to get the number low as fast as possible. If the number is close to zero, they want to see zero. It is that simple.

They do not care if the issue is in a piece of code that is never executed and would require full access to the machine. It is there and tool X reports it.

Even security audits are terrible, when they don't find anything major they start reporting stuff that few percent of companies have implemented just to stuff their reports, it is ridiculous.

▲

chelmzy 5 hours ago | parent | prev | next [-]

Its the same at most orgs. Very rare for a vuln remediation program to utilize a truly risk based approach. They would have to trawl through and understand thousands of vulns and the context of your org. There's probably a market for some tool to accomplish this if the larger players haven't attempted already.

▲

thewebguyd 5 hours ago | parent | prev | next [-]

This is the rot that's happening in cybersec. Before we even had security teams as a dedicated role, sysadmins mostly handled security, and we would evaluate each CVE and determined if it even was applicable.

Then companies started hiring paper pushers into security roles and discretion no longer mattered, it just became a game of "Check the box" with no regard for what is actually running in prod, or whether you're actually vulnerable.

Same shit with auditors. I deal with PCI and it's a fight to explain why the "compensating controls" work to a non technical auditor. If it doesn't check the box exactly, good luck.

▲

dboreham 5 hours ago | parent | prev | next [-]

It's asymmetric warfare. It costs them little to demand a false positive be acted upon, but costs you plenty to refute it.

▲

pudgywalsh 5 hours ago | parent | prev [-]

[flagged]

	▲	zdragnar 5 hours ago \| parent \| next [-]
		Setting aside the merits of DEI, this anecdote isn't indicative of it. I recall a client getting HP to do a security audit of a site I was working on, and it absolutely read like a committee put together a checklist of every possible thing they could think of. They flagged that user sessions weren't pinned to IP addresses, despite this being right around the time that cell phones became popular and their suggested remediation would have caused users who were riding on a bus between cell towers to get logged out while they were using the site. There were plenty of even less useful flags, but that one stood out to me for some reason. "Checklist security" has been a thing for ages.
	▲	zenethian 5 hours ago \| parent \| prev \| next [-]
		That’s a pretty insane leap to go from “we have a non-technical security team” to “DEI caused this.”
	▲	linuxhiker 5 hours ago \| parent \| prev [-]
		Sometimes it is cheaper. Most businesses run on a, "least to be in compliance" model.

▲

bob001 5 hours ago | parent | prev | next [-]

The linux kernel team disagrees with your approach but what do they know?

> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

	▲	pixl97 5 hours ago \| parent [-]
		That with LLMs being decent at chaining exploits suddenly very difficult issues can be accomplished by people with middling abilities and resources.

▲

jerf 5 hours ago | parent | prev | next [-]

I only sampled them, but all the ones I sampled are announcements of fixes, not just vulnerabilities. This seems to be downstream of the "intake" already.

▲

5 hours ago | parent | prev [-]

[deleted]