Exploitability analysis

Most vulnerability programs are drowning in findings. Everything is labeled critical, but almost none of it is actually exploitable. Teams burn engineering hours patching things that pose no real threat, while the one issue that truly matters stays buried in the backlog. The day-to-day reality looks like this:

• thousands of findings across cloud and code
• critical severity scores that don’t reflect real-world risk
• endless spreadsheets, meetings, and manual triage
• engineering time spent patching low-impact issues, instead of improving product
• a constant worry that the one truly exploitable issue is buried

Exploitability analysis cuts through this noise. Instead of treating every CVE equally, I evaluate whether each vulnerability can actually be exploited in our specific environment — and provide the evidence to back it up. I figure out what is not exploitable in context, what’s urgent, and what to do next, with reasoning the whole team can follow and trust.

---

​

The question: is it exploitable here?

A CVE is not automatically exploitable everywhere. Vulnerable code, written on a piece of paper, sitting on your desk, cannot be executed by an attacker to gain access to your computer. It has to be present on your system, part of a running service, exposed to the network, with a path to the internet. Every vulnerability has requirements like these. Think of them as a checklist of preconditions that an attacker needs to meet to succeed. Examples of exploitation requirements:

• the operating system must be a specific type (Windows vs Linux)
• the system architecture must be a specific type (x86_64 vs ARM/Graviton)
• a specific feature must be turned on
• a service must be running and reachable over the network
• a specific version of a software library must be present and used
• certain hardware must be attached

If the requirements aren’t met by our system and environment, the vulnerability cannot be exploited in our context. That’s what I do differently: for each CVE on each asset, I answer: Can this be exploited in our environment? And I show all the evidence behind the answer.

---

​

Examples: Critical on paper, not exploitable in practice

Here are common cases that create noise and drive alert fatigue. A CVE can be rated critical in a generic database, but the exploit requirements don’t fit how we actually run the workload.

​

Example 1: Windows-only vulnerability on a Linux workload (CVE-2024-49138)

• What we see: CVE-2024-49138, a critical Windows privilege escalation vulnerability, flagged on this server.
• Exploit requirements: the target must be running Windows.
• Our reality: the asset is running Linux.
• Result: not exploitable on this asset. It shouldn’t compete for attention and engineering time.

​

Example 2: RDMA requirement (CVE-2023-25775)

• What we see: CVE-2023-25775, a high severity vulnerability in the Intel Ethernet Controller RDMA driver.
• Exploit requirements: RDMA-capable hardware with the Intel RDMA driver installed.
• Our reality: standard NICs, no RDMA.
• Result: not exploitable on this asset.

​

Example 3: Network reachability (CVE-2024-6387)

• What we see: CVE-2024-6387 (regreSSHion), a critical remote code execution vulnerability in OpenSSH.
• Exploit requirements: OpenSSH server (sshd) must be running and reachable by an attacker.
• Our reality: sshd isn’t running on this asset.
• Result: not exploitable on this asset.

---

​

Operational severity: what’s urgent for us?

Once we know a vulnerability can be exploited, the next question is priority: How urgently do we need to act in our environment? There’s a difference between:

• Base severity: a generic score (like CVSS) that tries to describe an abstract worst-case impact.
• Operational severity: the score for our asset and environment, based on exploitability plus context.

So instead of treating every critical as equally urgent, I help us split work into clear lanes:

• Not exploitable: deprioritize with confidence.
• Likely not exploitable: deprioritize, but not completely, as evidence isn’t 100% conclusive.
• Likely exploitable: fix first, track to closure, align to SLAs.
• Unclear / missing evidence: investigate manually, then decide.

This is how teams get out of backlog prison without increasing risk.

---

​

Explainable decisions

I don’t just give you a severity score and send you on your way. I give you the reasoning you need to trust it. For each vulnerability on each asset, I show the requirements, whether each requirement is met, and what evidence and reasoning supports it. That means you can answer the questions that always come up:

• Why did we deprioritize this?
• What would make this exploitable?
• What do we need to change to reduce exposure?

It’s easier to align security and engineering - and defend decisions to auditors when the reasoning is transparent.

---

​

Orchestration: drive remediation to done

Once we know what matters, I help the team fix it without the usual coordination tax:

• create Jira issues or raise pull requests, aligned to SLAs
• provide clear remediation guidance engineers can act on
• show impact (e.g. fixing this resolves 158 vulnerabilities across 12 VMs)
• verify fixes and close the loop
• keep updates in Slack, Microsoft Teams, or email

---

​

The benefits I bring