cves / day · 2025
0+
New CVEs disclosed every day — before counting misconfigs that never get a CVE.
DeepStrike 2025 Vulnerability Report
What is vulnerability remediation?
If you've spent any time in security or IT, you already have a working definition of vulnerability remediation: find what's broken, fix it, prove it's closed. The hard part is doing that at the scale and speed the modern threat surface demands — and recognizing that "vulnerability" is a much broader category than the CVE list your scanner produces. This guide covers the process, where it breaks down, and what good looks like in 2026.
What it is
Vulnerability remediation is the process of identifying, prioritizing, and fixing security exposures across an organization's systems, software, and endpoints — then confirming the fixes actually worked. In practice, "vulnerability" covers more than CVEs: it includes misconfigurations, hardening gaps, supply chain compromises, and any other condition that creates risk an attacker can exploit.
What it isn't
It's not detection, which only surfaces problems. It's not patch management, which only covers what a vendor has already fixed. Remediation is the work that actually closes risk — patchable or not.
The vulnerability remediation process.
Most organizations treat vulnerability remediation as a linear process. In practice it's a loop that never fully closes. But the steps are consistent — and understanding where each one breaks down is most of the battle.
Discovery starts with your scanners. Tenable, Qualys, Rapid7, and others continuously surface findings across endpoints, cloud infrastructure, and applications. The output is a list of vulnerabilities, each scored and documented. This part of the process is mature. The industry is good at it.
Prioritization is where most teams get stuck. A scanner doesn't know which server runs payroll and which runs an internal wiki. It can tell you a vulnerability scores 9.8 on CVSS — but not whether it's reachable from the internet, whether you have mitigating controls in front of it, or whether anyone is actively exploiting it. Without that context, prioritization is just sorting by number. Which produces a list that's technically accurate and operationally useless.
Remediation is the execution step: actually fixing what's been prioritized. This is where most programs hit a wall. Security identifies the problems. IT owns the systems. Neither controls the other. The fix requires a ticket, a handoff, a queue, and someone with time to work through it. That someone rarely exists at the scale the problem demands.
Validation confirms the fix worked — and it gets skipped more often than not. A patch gets deployed, the ticket closes, the vulnerability stays open because the deployment failed silently. Without validation, your remediation data is aspirational.
Reporting closes the loop. Not a count of open tickets, but actual evidence of exposure reduction over time. That's what security leadership, IT management, and the board can act on.
Vulnerability remediation vs. patch management.
Patch management is a subset of vulnerability remediation. It handles vulnerabilities for which a vendor has released a software update. If Microsoft releases a patch for a Windows flaw, patch management tools deploy it. That's the job. They do it reasonably well — within that scope.The problem is scope. Patch management only works where a patch exists. A significant portion of real-world vulnerabilities don't have one.
Misconfigurations — systems deployed with insecure defaults, open ports, or weak permissions — aren't fixed by a patch. Someone has to go fix the configuration.
Hardening gaps require active configuration changes, not software updates.
End-of-life systems will never receive patches; they need compensating controls applied and documented. Non-standard software — custom builds, legacy tools, anything outside the standard package managers — patch managers often can't see, let alone touch.
Even the strongest patch management programs address roughly 50% of an organization's attack surface. The other half requires something different: custom scripting, configuration changes, or autonomous agents that can reason about what a specific environment actually needs.
Conflating patch management with vulnerability remediation is how organizations end up with a program that looks thorough and leaves half the exposure open.
Why vulnerability remediation fails at scale.
The volume problem is real and getting worse. In 2025, more than 130 new CVEs were disclosed every day (DeepStrike 2025 Vulnerability Report). That's before counting misconfigurations and hardening gaps that never get a CVE at all. No team — regardless of size or skill — can manually remediate at that rate.
Speed is the second problem. The average organization takes 55 days to remediate 50% of critical vulnerabilities once a patch is available (Verizon 2024 DBIR). 77% of organizations need more than a week just to deploy patches (Expert Insights 2025). During that window, the vulnerability is open, known, and potentially being exploited.
The org chart makes it worse. Security owns the finding. IT owns the systems. Neither controls the other. Security escalates; IT triages against ten other priorities. The handoff is where remediation stalls. It's not a people problem — it's a structural one. Two teams, different mandates, no shared ownership of the outcome.
The CrowdStrike incident added another layer to anxiety that was already there. A security vendor's update took down systems globally — not from a breach, but from a patch pushed without adequate testing. The lesson the industry took from it: you can't push changes to endpoints without understanding the blast radius. Patches need testing. Production systems need approval gates. Rollback should be automatic. All correct. All adds friction to a process already too slow.
Tool sprawl compounds everything. Large enterprises run 40 to 80 security tools. Detection is highly developed. Remediation is not. 51% of security professionals say patching and remediation is now a bigger operational challenge than detection itself (Ponemon 2024). The industry got very good at finding vulnerabilities. It never built the execution layer to close them.
How to prioritize vulnerabilities before you remediate.
CVSS scores are a starting point, not a strategy. Every vulnerability gets a number between 0 and 10. A 9.8 sounds urgent — and sometimes it is. But CVSS doesn't know whether the affected system is internet-facing, whether you have compensating controls in front of it, or whether anyone is actively trying to exploit it. Sorting by CVSS and working down the list produces effort that doesn't match actual risk.
EPSS — the Exploit Prediction Scoring System — adds what CVSS misses: the probability that a given vulnerability will be exploited in the wild within the next 30 days. A moderate CVSS score with a high EPSS score is often more urgent than a critical CVSS score that attackers have shown no interest in. Using both together is better than either alone.
Business context is where prioritization gets real. A developer's workstation, if breached, could expose source code and production access. A sales rep's laptop exposes pipeline data and customer contacts. A customer-facing server is different still. Prioritization that ignores business impact — what does this system do, what happens if it's compromised — is still just sorting by number with extra steps.
The practical output of good prioritization isn't a ranked list. It's a set of actual decisions: fix this now, fix this this week, accept this risk temporarily with documentation, apply a compensating control here. That's what security and IT teams can act on.
What good vulnerability remediation looks like.
It runs continuously.
Not quarterly, not after the next audit. New findings come in, fixes execute, outcomes get validated, the loop repeats. The gap between detection and remediation should be shrinking, not holding steady.
It's context-aware.
Which endpoints are business-critical? What software dependencies need to be understood before a fix runs? Which systems require explicit approval before anything changes? A program that treats every endpoint the same is either too aggressive or too conservative — usually both at once, for different parts of the environment.
It accounts for IT's reality.
Security isn't IT's only job. They're managing systems, shipping features, handling requests, and responding to incidents. A remediation program that requires a human handoff for every fix will always lose to the queue. The programs that work handle volume autonomously and surface only the exceptions that genuinely need human judgment.
It validates.
Deploying a fix and closing the ticket is not remediation. Confirming the vulnerability is actually gone — that the fix held, the configuration stuck, the exposure is closed — is remediation. The difference shows up in audits and board conversations.
It's honest about what patch management can't do.
A mature program has an answer for misconfigurations, hardening gaps, end-of-life systems, and non-standard software — not just the vulnerabilities that come with a vendor patch.
Autonomous and agentic approaches are becoming the meaningful answer to the volume problem. Furl is built specifically to close the execution gap — investigating findings, generating environment-specific fixes, and deploying them autonomously across vulnerabilities, misconfigurations, hygiene gaps, and supply chain exposure. Continuous, validated, within the guardrails your team defines.
What is the difference between vulnerability remediation and vulnerability management?
Vulnerability management is the broader program: scanning, tracking, reporting, and coordinating the response to vulnerabilities over time. Vulnerability remediation is the execution piece inside that program — actually fixing what's been found. Management without remediation produces very detailed records of everything that's wrong. Remediation is what closes it.
How long does vulnerability remediation take?
It depends on the vulnerability, the environment, and the organization. For critical vulnerabilities with available patches, the industry average is 55 days to remediate half of them — which means the other half are still open past that point. For misconfigurations and hardening gaps, timelines stretch further. Organizations with mature, automated programs can close many findings within hours of discovery. Organizations relying on manual processes measure in weeks or months.
What is a vulnerability backlog?
A vulnerability backlog is the accumulation of known, unfixed vulnerabilities a team hasn't been able to close. It grows when detection produces findings faster than the team can execute fixes — which is the default state for most organizations. It's not a sign of a careless team. It's a sign that the volume has outpaced manual capacity. Most organizations have hundreds to thousands of open items at any point in time.
What's the difference between remediation and mitigation?
Remediation eliminates the vulnerability. A patch is applied, a misconfiguration is corrected, the exposure is closed. Mitigation reduces the risk without fully eliminating it — a firewall rule that blocks the attack vector, an access control that limits exposure, a monitoring rule that catches exploitation attempts. Mitigation is often the right interim move when full remediation isn't immediately possible. It's a legitimate holding position, not a substitute for closing the vulnerability.
Why do most organizations struggle with vulnerability remediation?
Three reasons, usually in combination. Volume: more vulnerabilities are disclosed every year, and AI-assisted attack tools are accelerating the pace. Structure: the team that finds vulnerabilities and the team that fixes them are organizationally separate, with different priorities and no shared ownership of the outcome. Tooling: the security industry built excellent detection tools and never built an equivalent execution layer. Most organizations are patching with tools designed for a simpler problem, in an environment that's grown well beyond what those tools were built to handle.