Skip to main content
Vulnerability management overview
Vulnerability management isn’t supposed to be a fire drill. But it becomes one when everything is labeled critical. Worse yet, it’s a complete waste of time when most of those criticals are not exploitable in practice. The day-to-day reality of vulnerability management often looks like this:
  • thousands of findings across cloud and code
  • critical findings that don’t match 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
I change this by turning vulnerability management into clear decisions that match real risk. I don’t just point out vulnerabilities. I figure out what is not exploitable in the context of our environment, 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

Cut noise by ~90%

Reduce alert fatigue by filtering out vulnerabilities that aren’t actually exploitable on our assets, so the backlog shrinks to what matters.

Save investigation time, fix real risk faster

I explain what’s exploitable and why (with an audit trail for engineers and auditors), then drive remediation to closure for the vulnerabilities that truly need fixing.