Your Scariest Vulnerabilities Might Not Be the Ones That Get You Hacked
Scanner reports full of 'critical' flags are drowning security teams. The real question is which of those flags actually give an attacker a path in.
Key points
- Security scanners flag thousands of 'critical' vulnerabilities, but most sit behind defences that stop an attacker from ever reaching them.
- Treating every high-severity finding as equally urgent burns out security teams and delays fixes that actually matter.
- Context, meaning where the flaw lives and what protects it, decides whether a bug is a real risk or just noise on a report.
- Teams get more value from asking whether an attacker can actually reach a flaw than from chasing raw severity scores.
Ask any security engineer what fills their week and the answer is usually the same: the scanner report came back with a column of critical flags, and someone upstairs wants a plan by Friday.
We've gotten very good at finding vulnerabilities. A vulnerability is a flaw in software that an attacker could, in theory, abuse to break in or steal data. What we're still bad at, honestly, is working out which of those flaws matter.
Why does a 'critical' bug not always mean critical risk?
Because severity scores rate the bug in isolation, not the environment it lives in. A top-severity finding on a server that sits behind network segmentation, identity controls and a web application firewall isn't the same emergency as a lower-rated flaw sitting on a box exposed straight to the internet.
The industry-standard score, called CVSS, tells you how bad the bug is in a lab. It doesn't tell you whether an attacker can reach it in your network, whether the vulnerable feature is even switched on, or whether stealing data from that machine would matter to your business. We've tracked CVSS scoring debates across [eight stories since June](/ story/why-security-teams-are-ditching-the-quarterly-scan-for-something-that-never), and the frustration from practitioners hasn't changed: the score answers the wrong question.
In practice, most critical findings on a scan report are already blocked by something else: a firewall rule, an access policy, a service that's not running. The failure mode is treating scanner output as a to-do list instead of a starting point.
What does a smarter approach look like?
Start with reachability. Could an attacker on the internet, or a low-privilege user inside the company, actually get to this service and trigger the bug? If not, that ticket sits behind the ones where the answer is yes. Not laziness: triage.
A useful reframe, as The Hacker News laid out in its recent piece, is to stop asking how bad a vulnerability is and start asking what path to compromise it creates.
| Question | What it tells you |
|---|---|
| Is the vulnerable service exposed to the internet? | Whether an outside attacker can even try |
| Does exploiting it give useful access? | Whether it leads anywhere valuable |
| Are other controls in the way? | Whether the attack chain actually completes |
| Is there evidence of active exploitation in the wild? | Whether the clock is ticking today |
Run a finding through those four and you get something closer to a real risk rating.
What should ordinary people take from this?
If you work at a company with a security team, this is why patching sometimes feels slow. They're not ignoring the scary-sounding email from IT; they're working out which of the week's alerts actually lets a criminal in.
For everyone else, the lesson is broader. Headlines about 'critical vulnerabilities' rarely translate directly into 'you're about to be hacked'. Layered defences usually do their job quietly and the bug never gets touched.
The ones that hurt are usually mundane: an exposed admin panel, a forgotten test server, a password reused from a breach years ago. Attackers are opportunists, not scholars of CVSS. Our 28 August story on continuous exposure management made the same point from the other direction: organisations switching to always-on scanning still drown if they can't rank what they find.
The post-mortem will say it every time: the bug that got them in wasn't the one at the top of the report.
Operational takeaway: rank vulnerabilities by reachable attack path, not by scanner colour. Your Friday will thank you.
