In my experience, that's primarily because cybersecurity people know neither the probability nor the impact of the things which they are calling risks, which moreover means they don't know how to order them from a prioritization perspective.
Business people typically don't wanna hear that and then act all shocked pikachu face when it happens.
Plenty of risks arent vulns in public software. Some are vulns in your own software. Some are just deviations from best practises or lack of system isolation.
Even among public vulns with known PoC, the impact is going to depend on context. Plenty of times the impact is zero based on how software is used.
I’m actually a fan of embedding security resources into the eng teams and having those resources fix issues rather than toss shit over the wall. Knowing how software works is really hard without living inside the code base.
"if attackers can run arbitrary code on our systems then they can exploit vulnerabilities!" or "if attackers can send arbitrary payloads to services which are turned off in the actual image and in any case not accessible without breaching a perimeter firewall and passing through a DMZ then they can exploit vulnerabilities!"
OK, sure, what about "attackers kidnap the families of our AD admin team and force them to do whatever they want"?
Also, "high" meaning "sometimes we just don't care".
No, sorry, I do not care that (e.g.) CVE-2023-4911 has been categorized as "high", I am not in a rush to replace every single Fargate task that contains a vulnerable glibc because it's just not an interesting vulnerability in that context: let's assume you (a) bypass the payload validation on the (private!) API Gateway, (b) construct a payload that allows some kind of RCE in my JVM, (c) somehow escape from the JVM sandbox to run arbitrary native code, (d) successfully implement the attack, (e) get root in the underlying VM ... it's a Firecracker VM that doesn't have ANYTHING ELSE in it.
But, no, it's a "high", I better start cutting change tickets for literally everything in the universe to conduct an incredible load of busy work in order to do a no-op.
Really smart cybersecurity would be (I'm just making this up, I haven't really thought about it) "you know, if we're looking at services contained in a VM security boundary like Fargate, perhaps we don't care about Attack Vector = Local or Physical, or User Interaction = Required?" but what we actually get is "raw CVSS score tells you all you need to know and absolutely dictates urgency and triage priority".
I am actually fairly data driven, and it's why things like SBOMs are exciting. Based on my experience, if something is exposed to the world and that thing has a vulnerability... within a period of reasonable time (say within 12 months), it will be exploited.
> No, sorry, I do not care that (e.g.) CVE-2023-4911 has been categorized as "high"
I wasn't actually referring to my "high" being the cvss scores. It was likelihood of exploitation(in my org), not the score. In your example, that would be a local exploit, so wouldn't be a high in my book unless you are shoveling user input to a CLI, which I would hope isn't happening.
Personally unless you know there to be higher risks for certain things, if it ain't 9+ on cvss, it gets a ticket cut to deal with it like any other but at some convenient time in the future.
> but what we actually get is "raw CVSS score tells you all you need to know and absolutely dictates urgency and triage priority"
Your security org sucks and are doing it wrong. I'm genuinely sorry, and I'll say that not all of us are like that :(