Vulnerability remediation is the work of correcting the cause of a security flaw so that it can no longer be exploited, and then proving the correction worked. It is one of three treatment options, alongside mitigation and acceptance, and the only one that removes the weakness instead of managing around it.
The second half of that definition is where programs break. In Fluid Attacks’ State of Attacks 2026, the remediation rate across assessed systems closed 2025 at 62.2%, and systems whose developers used Fluid Attacks’ IDE plugins reached a mean remediation rate of 55.4%, against 28.1% for systems that did not use them. Where a fix is written changes whether it gets written at all.
This page covers what vulnerability remediation is and is not, how it differs from mitigation and acceptance, how fixes are actually built for code, dependency vulnerabilities and infrastructure, how to verify that a flaw is really gone, what to do when no patch exists, and which metrics show whether the vulnerability remediation process is working.
What is vulnerability remediation?
Vulnerability remediation is the correction of a security weakness at its source, confirmed by retesting. It covers three kinds of change: fixing your own source code, updating or replacing a vulnerable third-party component, and correcting an insecure configuration in infrastructure or cloud services.
It is not a ticket status. A closed issue records that someone believed the problem was solved; it is not evidence that the weakness is gone. It is not a synonym for patching either. Patching is one path to a fix, and the NIST Special Publication 800-40 Revision 4, Guide to Enterprise Patch Management Planning (2022), defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying the installation of patches, and frames it primarily as preventive maintenance rather than a reaction to each advisory.
Vulnerability remediation sits inside the wider vulnerability management cycle. Detection, triage and prioritization decide what to fix and in what order. The vulnerability remediation process is what happens next, and fix verification is what ends it.
Why vulnerability remediation matters
Vulnerability remediation matters because exposure lasts exactly as long as the weakness does. Detection changes nothing by itself: a reported flaw that nobody fixes is the same attack path it was before the scan, now documented in two places.
Our 2025 vulnerability remediation data shows how uneven the work is. In the State of Attacks 2026, the median time to remediate was 14 days for critical-severity vulnerabilities but 40 days for high-severity ones, while the mean time to remediate reached 36 days for critical and 60 days for high. Critical flaws get attention; the tier immediately below them waits longer than anything else in the backlog, including low-severity findings at a median of 28 days.
Vulnerability remediation is also what auditors ask for, because a list of findings is not a control. Fluid Attacks sets its own remediation deadlines by severity for that reason, following the recommendations of frameworks such as PCI DSS and NIST.
Vulnerability remediation at Fluid Attacks
Fluid Attacks runs vulnerability remediation as a closed loop. AI, proprietary scanners and pentesters report a vulnerability with its exact location and exploitation evidence; the platform offers a fix path inside the developer’s own editor; and a retest confirms whether the fix worked before the finding can close.
What we fix, and under what rules
Our vulnerability remediation support covers the three targets we test. For source code, the platform shows the vulnerable lines and the secure pattern for that language. For components, Software Composition Analysis (SCA) returns upgrade paths for direct and transitive dependencies. For infrastructure, findings arrive with the corrected configuration for the cloud provider or container platform involved.
Nothing closes on assertion. A developer marks work as done by requesting a retest, not by changing a status. Our engine or our pentesters decide the outcome.
What it looks like in practice
Each vulnerability remediation path leaves a different kind of evidence:
Fix path | What the developer gets | What closes the finding |
|---|---|---|
Custom Fix | A step-by-step guide generated for the vulnerable code in the IDE | Retest |
Autofix | A suggested change applied directly in the file | Retest |
Dependency upgrade | Three versions to choose from: minimal fix, safe update, complete fix | Retest after the scanner reruns |
Pentester session | A 30-minute call with the pentester who reported the issue | Manual retest |
Fluid Attacks’ public fix catalog: 2,044 documented fixes covering 326 weaknesses across 23 programming languages.
Where remediation happens changes whether it happens
The strongest pattern in our 2025 data is not about tooling quality. It is about the distance between a finding and the person who can correct it. These comparisons are observational, so they show association rather than cause:
Practice in 2025 | Systems or clients that used it | Those that did not |
|---|---|---|
IDE plugins | 55.4% mean remediation rate | 28.1% |
MCP server | 49.7% mean remediation rate | 24.1% |
CI Gate | 72.2% remediation rate; 22-day median | 58%; 30-day median |
Source: Fluid Attacks, State of Attacks 2026. The IDE plugin figures cover the 23% of clients that used them from March 2025; the MCP server figures cover the 41% that used it from June 2025.
What GenAI remediation does well
Generative AI earns its place on the routine half of the work. In the State of Attacks 2026, Autofix and Custom Fix were used in 53.6% of systems, and Custom Fix accounted for 93% of those systems. The pattern is clear: teams reach far more often for a guide that explains the fix than for a patch applied on their behalf.
That preference is well placed, and our own documentation states the reason plainly: gen AI can produce vulnerable code, so each generated step has to be examined before it is accepted. AI-assisted remediation shortens the distance between a finding and a working fix. It does not remove the review, the tests or the retest.
The rules we apply to our own code
Fluid Attacks runs its full solution against its own technology stack, under published vulnerability remediation deadlines by severity:
CVSS v4.0 score | Time to remediate |
|---|---|
9.0 – 10.0 (Critical) | ≤ 7 days |
7.0 – 8.9 (High) | ≤ 15 days |
4.0 – 6.9 (Medium) | ≤ 30 days |
0.1 – 3.9 (Low) | ≤ 60 days or according to priority |
Our engineering team can accept a vulnerability temporarily while it builds the patch: a maximum of two times, 30 days each, 60 days in total. The target remediation percentage is above 99%. This is our internal remediation SLA, published in our transparency documentation, not a standard every organization must copy.
Remediation, mitigation and risk acceptance are not alternatives
Vulnerability remediation, mitigation and risk acceptance answer different questions, and treating them as a menu is how residual risk accumulates quietly. Remediation removes the weakness. Vulnerability mitigation reduces the chance or the impact of exploitation while the weakness stays in place. Acceptance is a documented decision to live with it.
Treatment | What changes | What remains | When it fits |
|---|---|---|---|
Vulnerability remediation | The weakness is corrected at its source | Nothing, once verified | Always the default |
Mitigation | Exposure or impact is reduced by a compensating control | The underlying flaw, and the control’s own cost | No fix exists yet, or the fix needs a release window |
Acceptance | Nothing technical | The full exposure, now documented and owned | Low risk, or remediation cost above the expected loss |
Two rules keep this honest. Mitigation needs an expiry date, because a temporary control that nobody revisits becomes permanent architecture. Acceptance needs an owner and a review date, because an acceptance without either is an unfixed vulnerability with better paperwork. In the systems we assessed in 2025, permanent acceptance covered 0.1% of high-severity and 0.3% of critical-severity vulnerabilities: in a mature vulnerability remediation process it stays an exception, not a release valve.
How vulnerability fixes actually get made
Vulnerability remediation takes three different shapes depending on where the weakness lives, and conflating them is why remediation plans slip.
Your own code. Vulnerability remediation here changes application logic: adding the authorization check, parameterizing the query, replacing the weak algorithm. These corrections are fully under your control, and they are the ones a security champion or an AI assistant can hand to a developer as a concrete diff.
Your dependencies. You rarely patch third-party code; you change versions. Our platform returns three options for each vulnerable component so teams can choose between security and stability. Each option is a different vulnerability remediation trade-off, and the platform names which one it is:
Option | What it does | Trade-off |
|---|---|---|
Minimal fix | Fixes the reported vulnerability | May introduce new ones |
Safe update | Fixes the reported vulnerability without adding new ones | Usually a larger version jump |
Complete fix | Updates to the latest version free of known vulnerabilities | Highest chance of breaking changes |
Transitive dependencies are the hard case in dependency vulnerabilities work, because you do not control their version directly. The platform identifies the direct package that pulls in the vulnerable code and gives the three remediation versions for it, so the team can confirm compatibility or move the parent package to its minimum supported version.
Your infrastructure. Here vulnerability remediation means correcting a configuration: closing a public bucket, enforcing TLS, removing an over-permissive IAM policy. These fixes are often the fastest to apply and the easiest to regress, which is why they belong in infrastructure as code rather than in a console.
Fix the weakness, not the CVE
A CVE is one instance of a flaw in one product; a weakness is the class behind many instances. Fluid Attacks writes vulnerability remediation guidance for the class, which is why a single fix pattern serves every CVE that shares it, across languages and frameworks.
Our public fix catalog holds 2,044 documented fixes covering 326 weaknesses across 23 programming languages, mapped from more than 340,000 vulnerability records. Each entry pairs non-compliant code with compliant code and names the security requirement the change satisfies, as our write-up of the database explains in detail. That mapping is what makes vulnerability remediation reusable across technologies and frameworks.
Each weakness entry also carries an expected remediation time, which turns vulnerability remediation into something a team can plan in a sprint instead of estimating by feel. Weakness 022, use of an insecure channel, lists 15 minutes and maps to requirement 181, transmit data using secure protocols; weakness 005, privilege escalation, lists 60 minutes and maps to requirement 035.
Entry 022 in Fluid Attacks’ catalog: impact, recommendation, linked requirement and expected remediation time.
How to verify that a vulnerability was remediated
Fix verification is the step that separates vulnerability remediation from a status change, and it exists because a correction can fail in two ways: it can miss the original weakness, or it can introduce a new one. Our documentation says exactly that, and it is the reason no vulnerability remediation closes without a retest.
At Fluid Attacks the vulnerability remediation reassessment is called a reattack. After syncing the corrected repository, the developer selects the location where the fix was applied and requests it. Automated retests are run by the tool; manual ones are run by the pentester who reported the finding. If the weakness survives, the vulnerability’s Reattack column shows Verified (vulnerable) and a comment explains what still works.
The response is bounded by a service-level agreement: at least 90% of these requests receive a first response within a median of less than eight office hours. A developer who asks for a retest in the morning usually knows before the end of the day whether the correction held.
Retests confirm vulnerability remediation after the fact. The CI Gate works in the other direction, breaking the build when a deployment carries vulnerabilities that violate the organization’s policy. Both controls serve the same rule: no finding closes on an assertion that nobody tested. A fix that passes a retest becomes a vulnerability remediation pattern the team can reuse; one that fails becomes a lesson before it reaches production.
When there is no patch available
Sometimes vulnerability remediation is not available on the timeline the risk demands: the vendor has not shipped a fix, the component is unmaintained, or the upgrade breaks a production dependency. The answer is a documented mitigation with an end date, treated as a stage of vulnerability remediation rather than a substitute for it.
Situation | Interim measure | What still has to happen |
|---|---|---|
No vendor patch yet | Restrict network access, disable the affected feature | Track the advisory and apply the fix on release |
Fix breaks compatibility | Isolate the component, add input validation upstream | Schedule the upgrade in a release window |
Component unmaintained | Replace it, or fork and patch | Treat replacement as the remediation |
Risk below the cost of fixing | Document acceptance with owner and review date | Re-evaluate when exposure or exploitation data changes |
Exploitation data decides the deadline. The CISA KEV catalog lists flaws with confirmed exploitation in the wild, and CISA’s Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued in June 2026, requires US federal civilian agencies to act on catalog entries within the deadlines each entry carries, some of them a matter of days. A listing in the CISA KEV catalog moves a finding to the front of the vulnerability remediation queue whatever its base score says.
How to measure vulnerability remediation
A vulnerability remediation program is measured by what closed and how long it stayed open, not by how many findings were reported. Four metrics cover it.
Vulnerability remediation rate. The share of reported vulnerabilities that were fixed. Ours across assessed systems reached 62.2% at the end of 2025.
Mean and median time to remediate. Report both and split by severity, because a mean hides the long tail and an aggregate hides which tier is being neglected:
Severity | Mean time to remediate | Median time to remediate |
|---|---|---|
Critical | 36 days | 14 days |
High | 60 days | 40 days |
Medium | 51 days | 30 days |
Low | 56 days | 28 days |
Source: Fluid Attacks, State of Attacks 2026, covering vulnerabilities remediated during 2025.
Failed retests. The share of fixes that did not survive verification. It is the one metric here that measures vulnerability remediation quality rather than speed, and a rising number is a reason to check how fixes are reviewed before they are submitted.
Residual risk exposure. Severity-weighted rather than counted, so one critical finding does not disappear behind a hundred low ones. We use CVSSF for this.
Conclusions
Vulnerability remediation is the only treatment that removes a weakness, and it is finished when someone other than the author has confirmed the weakness is gone. Mitigation and acceptance are legitimate choices, but both leave residual risk that needs an owner and a date.
The levers that move the vulnerability remediation process in our data are unglamorous: put the fix where the code is written, give developers a guide rather than a black-box patch, and make verification a retest instead of a checkbox. Systems whose developers used our IDE plugins remediated at nearly twice the rate of those that did not, and systems that broke the build closed findings eight days faster at the median. Every other metric in a vulnerability remediation program depends on that habit.
Frequently asked questions
What is the difference between vulnerability remediation and mitigation?
Vulnerability remediation corrects the weakness at its source, so the attack path disappears. Vulnerability mitigation leaves the weakness in place and reduces the chance or impact of exploitation with a compensating control, such as restricting network access or disabling a feature. Remediation is the goal; mitigation is what buys time until the fix is available, and it needs an expiry date.
How do you verify that a vulnerability has been fixed?
By retesting the specific location with the same technique that found it, not by closing the ticket. At Fluid Attacks this retest is called a reattack, run automatically by the tool or manually by the pentester who reported the finding. If the weakness survives, the platform marks it Verified (vulnerable). At least 90% of requests get a first response within a median of less than eight office hours.
How long should vulnerability remediation take?
It depends on severity and on the deadlines your remediation SLA defines. Fluid Attacks applies ≤7 days for critical, ≤15 for high, ≤30 for medium and ≤60 for low to its own code. In practice, across the systems we assessed in 2025, the median time to remediate was 14 days for critical vulnerabilities and 40 days for high-severity ones.
Can AI safely fix software vulnerabilities?
With review, yes, and the usage pattern reflects that caution. Autofix and Custom Fix were used in 53.6% of the systems we assessed in 2025, and 93% of those systems used Custom Fix, the step-by-step guide, rather than the automatic patch. Gen AI can produce vulnerable code, so AI-assisted remediation still needs testing and a retest before the vulnerability remediation counts as done.
Does Fluid Attacks verify that your fixes worked?
Yes. Vulnerability remediation only closes in our platform after a retest confirms it, requested from the platform, the IDE or your ticketing system. Clients on the Advanced plan get manual reattacks from the pentester who reported the vulnerability, with evidence either way.
Close the loop on every fix
Fluid Attacks’ pentesters and scanners retest every fix you report, so vulnerability remediation ends with evidence instead of an assumption. Start free trial · Contact us.
Get started with Fluid Attacks' ASPM solution right now
