When Critical Isn’t Critical: Uncovering the Truth in Your Findings Queue
Picture your findings queue right now. Somewhere in there is a Critical, CVSS 9.8, remote code execution, exploited in the wild according to every feed you subscribe to. And somewhere below it, ranked as a Medium, is a finding your scanner barely flagged.
Here’s the question I want you to sit with: which one is your team actually working on today?
If the answer is the Critical, you might be solving the wrong problem first. Not because the Critical isn’t real. Because nobody’s checked whether it’s actually reachable in your environment, while that quiet Medium has a confirmed, walked path straight to compromise.
This is the gap between two things that get treated as the same thing but aren’t: Theoretical Risk and Validated Risk. Scanning gives you the first. Only testing gives you the second. And if your prioritization queue is built entirely on the first, you’re triaging based on a fiction, a well-intentioned, mathematically rigorous fiction, but a fiction all the same.
Theoretical Risk vs. Validated Risk
Let’s give scanning its due, because this isn’t an argument against scanning. Scanners are fast, they’re broad, and they catch things a human would take weeks to find manually. CVSS gives you a shared language to talk about severity across an entire industry. None of that is wrong.
But here’s what CVSS is actually measuring: how bad this vulnerability would be under a specific set of assumptions, unauthenticated access, no network segmentation, no compensating controls, a clean and unobstructed path from attacker to asset. That’s not a description of your network. That’s a description of a lab. Your scanner sees a version number, a known CVE, and a severity score calculated in a vacuum, and it reports exactly that: Theoretical Risk, what could happen if nothing stood in the way.
Pentesting and red teaming answer a different question. A tester doesn’t ask “is this vulnerability severe.” They ask “can I actually get here from there, starting from where a real attacker would start.” That answer is Validated Risk, a confirmed read on whether the thing your scanner flagged is actually reachable and exploitable in your environment, not a theoretical one.
The problem isn’t that scanners are wrong. The problem is what happens when you treat “theoretically severe” as “actually dangerous to us” without ever checking.
Where Theoretical Risk Quietly Falls Apart
Think about everything that can stand between an exploit and the asset it’s targeting in your actual environment. None of it shows up in a CVSS score:
- Network segmentation that keeps a vulnerable system on an isolated VLAN
- A WAF rule that happens to catch the exact traffic pattern the exploit generates
- Endpoint detection that kills the process the second it tries to spawn a shell
- A firewall rule someone wrote two years ago for an unrelated reason, that happens to block the one port this exploit needs
CVSS doesn’t have a field for “yeah, but we patched the thing next to it that this exploit chains through.” It doesn’t ask whether the vulnerable service is internet-facing or buried three hops deep behind a bastion host. It scores the vulnerability in isolation, as if your environment were an empty room with the vulnerable system sitting alone in the middle of it.
Most environments are layered, messy, full of controls that were built for other reasons and happen to break exploit chains as a side effect. But if nobody validates that it’s doing its job, you’re stuck defending a priority list you can’t actually justify, because you’re guessing just as much as the scanner is.
The Inversion in Practice
Say your queue has a Critical sitting at the top: CVSS 9.8, remote code execution, exploited in the wild. Testing shows it requires access to an internal management interface, reachable only from a segment with maybe a dozen users, all on hardened, monitored workstations, with no known path in from anywhere an attacker could realistically start. Still a real vulnerability. Still worth fixing eventually. Not the fire your team should be dropping everything for.
Now look at the Medium sitting below it. Testing shows it’s reachable from a low-trust segment, a guest network or a contractor VLAN, with a documented, walked path from there to a domain admin credential. No exotic technique required, just a chain of ordinary things connecting in exactly the wrong order.
[GRAPHIC PLACEHOLDER: side-by-side attack path diagram, Critical finding as a dead end vs. Medium finding as a live, walked path to domain admin]
CVSS says Critical over Medium. Reality says the opposite. That inversion is the entire point of this piece, and it’s not a hypothetical. It happens constantly, in environments that have invested heavily in scanning and barely at all in validation.
What Changes When Validated Risk Drives the Queue
Once you have Validated Risk sitting next to Theoretical Risk, prioritization stops being a severity-sorted list and starts being an actual risk conversation.
- Your queue reorders. Findings with confirmed, walked attack paths move up, regardless of what CVSS says about them in isolation. Findings that are theoretically severe but practically unreachable move down, not off the list, just down, because they’re still worth fixing when the fire drills are handled.
- Your conversations with engineering change. Instead of “the scanner says this is Critical, go fix it,” you can say “here’s the actual path an attacker would take, here’s where it starts, here’s what it touches.” Engineers respond to that differently; it’s a concrete scenario they can picture and reason about, not an abstract score.
- Your conversations with leadership change. You can finally answer the question they’re actually asking, which was never “how many Criticals do we have?” It was always “are we actually at risk, and how do you know?” Validated Risk is how you know.
Building Validation Into the Workflow, Not Bolting It On
Here’s the part that trips a lot of programs up. Validation can’t be a once-a-year event that produces a PDF and then goes stale the moment your environment changes, because your environment changes constantly. New segmentation gets added. Old firewall rules get removed during a “cleanup” project nobody thought to flag as security-relevant. A compensating control that was doing real work quietly gets decommissioned.
Validated Risk has an expiration date, and that date is whenever your environment changes in a way nobody retested.
That means validation has to live in the same system as your scanning data and your remediation tracking, not off in a separate PDF that ages the moment it’s delivered. When a scanner flags something new, you want to know immediately whether it lands next to an already-validated attack path or in genuinely uncharted territory. When a compensating control changes, you want a system that flags which validated findings might need a second look.
This is exactly why treating scanning, pentesting, and remediation as three disconnected processes doesn’t scale. You end up with Theoretical Risk in one tool, Validated Risk trapped in a report from six months ago, and no way to tell which findings in your current queue actually reflect reality anymore.
Bringing Theoretical and Validated Risk Into One View
At PlexTrac, this is the problem we built the platform to solve. Scanner findings and pentest results don’t have to live in separate worlds where one gets updated daily and the other gets frozen the day the report ships. When they live in the same system, you can see, for any given finding, whether it’s still sitting at Theoretical Risk or whether it’s been walked, confirmed, and promoted to Validated Risk, and you can see it update as your environment changes instead of waiting for next year’s engagement to find out you were wrong.
Scanning tells you what’s possible. Validation tells you what’s real. The programs that are actually reducing risk, not just generating reports about it, are the ones that stopped treating those as the same question.
Ready to see what your queue looks like once you separate Theoretical Risk from Validated Risk? Request a demo.
