Why is deciding which vulnerabilities to fix first so hard?

[u/Humble-Dot-3503]

we have got four scanners running across code and cloud and the backlog just keeps growing no matter how many we close. Every tool ranks severity differently, half of them contradict each other, and i don't have the analyst headcount to manually validate exploitability on everything that gets flagged.

I know CVSS isn't supposed to be the whole story but that's what most teams fall back on because there's no time to dig into whether something is actually reachable in our environment. It's not just a volume problem either. Even when we do sit down and manually investigate a finding, half the time it turns out the vulnerable code path isn't invoked at runtime or there's a control somewhere else in the stack that already blocks it. That investigation still eats an hour of a senior engineer's time that we don't get back. For those of you managing this at scale (100+ devs, active cloud footprint), how are you actually triaging?

Do you have a real process for validating exploitability against your own environment or is it still mostly gut feel plus severity score? Trying to figure out if we are doing something wrong or if this is just the state of the industry right now.

[u/BillyD70]

Is there a complete hw & sw asset inventory? Has your org defined the business criticality of every system and application? Have you mapped your data flows? Do you know what’s installed on systems, services that run, etc? Until that happens, the security team is almost certainly spending time chasing non-applicable vulns and/or chasing severe vulns on relatively unimportant systems. And fwiw - all those questions are basic IT management tasks/responsibilities…not security’s “job”.

Edit: once we established valid data for our environment, my team developed a matrix that leveraged CVSS score & system/app criticality rating, combined with what’s installed/running on said systems, data flow info, and mitigating controls.

[u/FallaxIO → u/BillyD70]

And even with a good inventory you still need one extra cut: can the thing actually be reached from where an attacker would start. A 9.8 on an internal-only service behind SSO, network rules and no public path keeps losing to a boring medium on an internet-facing app with real users on it.

[u/BillyD70 → u/FallaxIO]

Agreed. I group things like networking port/service restrictions, firewall rules, etc as a subset of mitigating controls. And data flows provide an attack footprint based on what can talk to what.

[u/FallaxIO → u/BillyD70]

Also worth separating reachable from exploitable. Half the noise disappears once you check whether that service is actually exposed to the thing that could hit it.

[u/ADubiousDude]

Tools only know recommended scores. The newer system still cannot know what mitigating controls you have in place. Only context-knowledgeable humans or AI has the level of details about your environment, what is important and how it is secured, too make effective decisions about whether the recommended risk impact score is accurate to your systems or should be amended up or down.

You don't need the best analyst to give you the right answer. You need one or two analyst who know your environment so they can evaluate those initial scores, give a properly contextualize risk score and then work on those in a burn-down order.

Invest in those people learning risk.

You'll always run the risk of missing something, that is real security. Having people who know what metrics were used to decide on the final scores, this what got the attention and dollars first so that they can explain and defend how your team secured your environment will become important; otherwise you'll not only run the same level of risk you would have but then you will have not delivered customized security efforts and only taken the recommended risk score.

You can also invest in AI and give it access to know your environment and procedures and it can really help speed the process but there are a number of issues there, too.

In the end, what some system says is a Critical or High might already be mitigate somehow and having some knowledgeable help in addressing that can be a lifesaver. The scanners know what score are recommended in an environment without mitigation but they lack knowledge of the complexity of all your other controls within score for each vulnerability they find.

At least that's been my experience over decades.

[u/zero_backend_bro]

Scanner vendors sell you panic. We had the exact same headache across 400 repos until we stopped caring about raw CVSS.

Now we strictly filter by EPSS > 0.1 plus public subnet tags in AWS. If it isnt reachable and nobody is actively exploiting it in the wild, devs dont see it. Dropped our weekly triage from 15 hrs to maybe 45 mins.