Vulnerability management is the continuous process of identifying, evaluating, prioritizing, treating and verifying security vulnerabilities across an organization's software and infrastructure. Its goal is not a short list of findings but a low risk exposure that stays low as systems change.
The numbers explain why ranking matters more than counting. In Fluid Attacks' State of Attacks 2026, high- and critical-severity flaws were only 4.5% of the 1,119,396 vulnerabilities reported in 2025, yet they carried 79.9% of the total risk exposure. A vulnerability management program that treats every finding the same spends most of its effort on the 95% that matter least.
This page covers what vulnerability management is and is not, how it differs from a one-off assessment and from CTEM, how to prioritize with CVSS, EPSS and KEV, the six stages of the lifecycle, and what the practice looks like when Fluid Attacks runs it with AI, scanners and pentesters.
What is vulnerability management?
Vulnerability management is a recurring cycle, not a one-time scan. It starts with knowing which assets are in scope, continues with detection and ranking, and ends only when a fix is verified. Then it starts again, because code, dependencies and infrastructure change every week.
A vulnerability is a weakness in a system, usually the result of a software bug, a design error or a misconfiguration, that an attacker can use to gain unauthorized access or disrupt operations. Vulnerability management treats each one as a unit of work with an owner, a priority, a treatment decision and a verification step.
What vulnerability management is not
Vulnerability management is not a scanner report. A report is an input; the program is everything that happens after it: triage, assignment, remediation, acceptance decisions and retesting. It is also not a promise of zero vulnerabilities. Mature programs measure risk exposure and remediation time, not raw counts.
Vulnerability, risk and threat
These three terms get mixed up, and the difference shapes prioritization:
Vulnerability: the weakness itself, for example an endpoint that skips authorization checks.
Risk: the chance that the weakness causes harm, weighted by likelihood and impact.
Threat: the actor or event that could exploit it, often called a threat actor.
If a system has a vulnerability, there is a risk that a threat actor exploits it. Vulnerability management works on the only part of that sentence an organization fully controls: the vulnerability.
Why is vulnerability management important?
Vulnerability management matters because the volume of flaws grows faster than any team can fix them one by one. Without a way to rank and verify, effort goes to whatever looks scariest on paper instead of whatever attackers are likely to use.
The volume outgrows the team
The number of published CVEs keeps rising each year, and a large share receives a high or critical base score. Vulnerability management that treats every critical CVSS score as an emergency is not sustainable. Fluid Attacks' analysis of severity scoring found that doing so would exhaust staff and budget chasing risks that are often theoretical.
Our own data points the same way. In the State of Attacks 2026, 70% of assessed systems had at least one high- or critical-severity vulnerability, up from 53.3% the year before. More code, much of it AI-assisted, means more findings to triage.
Known flaws keep causing major incidents
Most damaging incidents do not need a zero-day. They exploit a vulnerability that was public, scored and often patchable. Two cases show where vulnerability management tends to break:
Case | Vulnerability | Where the cycle failed |
|---|---|---|
Log4Shell (2021) | CVE-2021-44228, Apache Log4j | Visibility into direct and transitive dependencies, the job of software composition analysis |
MOVEit Transfer (2023) | CVE-2023-34362, SQL injection | Speed: the flaw was exploited in the wild and added to CISA's KEV catalog, so exposed instances had to be found and patched fast |
Vulnerability management, vulnerability assessment and CTEM are not alternatives
A vulnerability scan or assessment is one stage inside vulnerability management, and continuous threat exposure management (CTEM) is a wider program that contains both. Confusing them leads teams to buy a scanner and believe they have a program.
An assessment identifies, classifies and reports security issues at a point in time, with automated tools, manual pentesting or both. Vulnerability management adds what comes after: prioritization, treatment, verification and repetition. Continuous threat exposure management extends the scope to the whole attack surface and adds validation of whether exposures are actually exploitable.
Approach | Main question | Output | Ends when |
|---|---|---|---|
Vulnerability assessment | What weaknesses exist right now? | A list of findings with severity | The report is delivered |
Vulnerability management | Which weaknesses do we fix first, and are they really fixed? | Prioritized, assigned and verified remediation | Never: it is a cycle |
Risk-based vulnerability management | Which weaknesses are likely to be exploited here? | Priority that combines severity, exploitation data and context | Never: priority updates as data changes |
CTEM | Where is our whole attack surface exposed, and can attackers use it? | Scoped, validated exposures across assets | Never: it runs in repeated cycles |
At Fluid Attacks, we described an early version of this idea in 2022 as a move from attack surface management to attack resistance management: knowing the assets is not enough without continuous testing and verified remediation.
Vulnerability management at Fluid Attacks
Fluid Attacks runs vulnerability management as one continuous program: AI, proprietary scanners and pentesters find vulnerabilities, and a single platform handles prioritization, assignment, remediation support and reattacks. The difference shows in what gets found and in how fast it gets fixed.
Video: we show how Fluid Attacks combines AI-native scanners, deterministic scanners and certified pentesters to help teams prevent, detect, manage and remediate vulnerabilities.
What we test, and under what rules
Our vulnerability management program tests three targets of evaluation: source code, running applications and infrastructure. Automated testing covers Static Application Security Testing (SAST), AI-powered SAST (AI SAST), Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST) and Cloud Security Posture Management (CSPM).
Manual testing adds Pentesting as a Service (PTaaS), Secure Code Review and Reverse Engineering. Our pentesters hold multiple offensive security certifications and attach exploitation evidence to their findings.
What it looks like in practice
Each stage of the vulnerability management lifecycle maps to something the platform records, so every decision leaves evidence:
Stage | What the platform does | Evidence left behind |
|---|---|---|
Identification | Consolidates findings from scanners and pentesters in one view | Location, type, severity and exploitation evidence per vulnerability |
Vulnerability prioritization | Ranks findings with seven attributes the organization can reorder: transitivity, use, KEV, EPSS, fixing cost, VLAI severity and reachability analysis | A priority rank that adjusts the CVSS v4.0 score by up to two points |
Assignment | Assigns each vulnerability to a developer and syncs with Jira or Azure DevOps | Owner, treatment status and audit trail |
Treatment | Offers GenAI fixes (Autofix, Custom Fix), Talk to a Pentester sessions and acceptance policies | Justified temporary or permanent acceptances |
Verification | Runs reattacks on request and blocks risky deployments with CI Gate | Closed status only after a successful retest |
Fluid Attacks platform priority policy with seven ordering attributes
Organizations reorder seven attributes to set how the platform ranks each vulnerability.
The prioritization attributes are documented in our prioritization attributes guide. Reachability analysis applies only to SCA findings: it tells whether your code actually calls the vulnerable function in a dependency.
Automated versus manual detection, in numbers
Scanners find most vulnerabilities; pentesters find most of the risk. That split is the main reason vulnerability management cannot rely on tools alone:
Metric | Automated tools | Manual testing | Source |
|---|---|---|---|
Share of vulnerabilities found (2025) | 88.4% | 11.6% | State of Attacks 2026 |
Share of total risk exposure found (2025) | 55.8% | 44.2% | State of Attacks 2026 |
Share of critical-severity findings (2025) | 13% | 87% | State of Attacks 2026 |
Recall on a 1,201-vulnerability web application | 22.7% (best tool: our scanner) | 89.6% (one pentester) | Tool benchmark |
In Fluid Attacks' benchmark of 36 third-party AppSec tools plus our own scanner, run against a web application with 1,201 vulnerabilities, a pentester found 1,076 of them: 89.6% recall at 100% precision, covering 98.9% of the risk exposure. The best automated result, from our scanner, reached 22.7% recall and 8.8% of the risk exposure.
State of Attacks 2026 chart of risk exposure by detection method
Share of total risk exposure that automated tools and manual testing found in 2025. Source: Fluid Attacks, State of Attacks 2026.
The limit of automated remediation
Automation helps most with the easiest fixes, and our own data shows it. In the State of Attacks 2026, Autofix and Custom Fix were used in 53.6% of systems, but mostly on low- and medium-severity vulnerabilities. GenAI speeds up routine dependency updates and simple code changes; it does not yet carry the critical issues.
Tools that promise automatic fixes usually work on direct dependencies with a clear upgrade path. A transitive dependency, a breaking API change or a logic flaw still needs someone to triage the finding, check that it is a true positive and confirm the fix does not break production. Our guide to fixing SCA vulnerabilities covers strategies for transitive dependencies. Remediation is faster with GenAI, but proper vulnerability management today cannot be fully automated.
The practice that decides the rest: verify the fix
A fix that nobody retests is a hope, not a remediation. Two controls decide whether vulnerability management closes the loop: reattacks, which confirm each fix, and breaking the build, which stops new vulnerabilities from reaching production.
The State of Attacks 2026 shows the effect. Systems that used our CI Gate reached a 72.2% remediation rate by the end of 2025, compared with 58% for systems that did not. Their median time to remediate was 22 days versus 30, or 26.7% faster. For critical-severity vulnerabilities, the mean time to remediate across all clients dropped 17.5% compared with 2024. Clients who set custom prioritization criteria reached a mean remediation rate of 64.4%, against 34% for those on the default order.
Systems that broke the build remediated more vulnerabilities, and faster. Source: Fluid Attacks, State of Attacks 2026.
Go deeper: how to break data silos between development and security teams explains how a shared platform shortens the path from finding to verified fix.
Scoring and prioritization: CVSS, EPSS and KEV
Effective vulnerability prioritization combines three signals: CVSS for potential impact, EPSS for likelihood of exploitation, and the CISA KEV catalog for exploitation already observed. No single score answers both "how bad could this be?" and "will someone use it here?"
CVSS: severity, not risk
The Common Vulnerability Scoring System (CVSS), maintained by FIRST, rates severity from 0.0 to 10.0. The current version is CVSS v4.0:
CVSS v4.0 score | Rating |
|---|---|
0.0 | None |
0.1 – 3.9 | Low |
4.0 – 6.9 | Medium |
7.0 – 8.9 | High |
9.0 – 10.0 | Critical |
The base score describes a worst case in a generic environment. Environmental and threat metrics adjust it to your context, but many tools report only the base value. That is why two tools, or two databases, can rate the same flaw differently.
EPSS: probability of exploitation
The Exploit Prediction Scoring System (EPSS), also from FIRST, estimates the probability that a CVE will be exploited in the next 30 days. FIRST measured a common policy against exploitation observed in October 2023: prioritizing every CVE with a CVSS 3.x base score of 7 or higher had an efficiency of about 4% (3.96%), so only around 4 in 100 of those fixes addressed a vulnerability exploited within 30 days. In vulnerability management, EPSS works best as a second filter after confirmed exploitation, not as the only number that decides a queue. Our EPSS guide covers thresholds and percentiles.
KEV: exploitation already confirmed
The CISA Known Exploited Vulnerabilities catalog lists CVEs with evidence of active exploitation. A KEV entry is the strongest signal to move a finding up the queue, regardless of its CVSS score. Under Binding Operational Directive 22-01, US federal civilian agencies must remediate KEV entries within set timeframes, and CISA recommends that every organization include the catalog in its vulnerability management plan.
[Image] File: vm-nvd-cve-2023-34362-kev.png · ALT: NVD record for CVE-2023-34362 showing its CISA KEV catalog entry
The MOVEit Transfer SQL injection in NVD, flagged as listed in CISA's KEV catalog. Source: NIST NVD.
CVSSF: comparing risk across systems
CVSS scores do not add up well, which makes vulnerability management reports misleading when they sum or average them: ten vulnerabilities rated 1.0 are not as risky as one rated 10.0. Fluid Attacks uses CVSSF, calculated as 4^(CVSS − 4), to aggregate and compare risk exposure. Those ten low-severity findings add up to 0.2 CVSSF units; the single critical one equals 4,096.
Putting the signals together
Risk-based vulnerability management ranks findings by severity, exploitation data and business context together. In practice that means a reachable, internet-facing vulnerability in the KEV catalog goes first, even if its CVSS is 7.5, and an unreachable 9.8 in a test dependency can wait. Our risk-based vulnerability management solution applies this ranking automatically.
The vulnerability management lifecycle
The vulnerability management lifecycle has six stages, repeated continuously. The model is not strict, but skipping a stage is where most programs fail.
The six stages repeat continuously; every fix is retested before the cycle restarts. Own work.
1. Scope, roles and policies
Define which systems and components are in scope and how critical each one is. An accurate asset inventory is the precondition for vulnerability management: what is not in the inventory is never scanned. Assign roles for detection, remediation and approval, and set policies for review frequency, remediation deadlines and acceptance criteria.
2. Identification
Vulnerability management usually starts detection with automated scanning, which compares systems against known vulnerability patterns and runs early and often. Manual testing follows to find what tools miss: business logic flaws, chained attacks and previously unknown vulnerabilities. The two are complements, not substitutes.
3. Evaluation and prioritization
Validate scanner output to remove false positives and add the vulnerabilities the tools missed. Then rate each true finding with CVSS, adjust it with EPSS, KEV and context, and rank it. Exploitability is the key question: can this be exploited here, how easily, and with what impact? Pentesters answer it with evidence.
4. Reporting
Report findings as they are confirmed, not in a large batch at the end of a test, so vulnerability management keeps a steady flow of work. Each report should include type, severity, location, detection date, status, description, evidence and a treatment recommendation. Small, prioritized batches are easier for teams to act on.
5. Treatment
Vulnerability remediation, the full fix, is the preferred option. Mitigation reduces the likelihood or impact of exploitation while a fix is prepared. Acceptance, temporary or permanent, is a documented decision that the cost of fixing exceeds the risk. In mature vulnerability management, permanent acceptance of high-severity issues stays close to zero.
6. Verification and reporting
Rescan and reattack to confirm each fix and to check that it did not introduce new vulnerabilities. Then update the status and track vulnerability management metrics such as remediation rate, mean time to remediate and risk exposure over time.
Types of vulnerabilities
Fluid Attacks groups vulnerabilities by attack mechanism into nine categories, an approach similar to MITRE CAPEC. Each weakness in our public database links to security requirements, and each requirement maps to standards such as CWE and the OWASP Top 10, which helps vulnerability management teams group findings by root cause:
Category | Example weaknesses |
|---|---|
Access subversion | Privilege escalation, cross-site request forgery |
Information collection | Use of software with known vulnerabilities, sensitive information in source code |
Functionality abuse | Non-upgradable dependencies, asymmetric denial of service |
Deceptive interactions | Server-side request forgery, missing subresource integrity check |
Protocol manipulation | Insecure HTTP headers, insecure authentication method |
Unexpected injection | SQL injection, remote command execution, reflected XSS |
Probabilistic techniques | Guessed weak credentials, lack of brute-force protection |
System manipulation | Inadequate file size control, log injection |
Data manipulation | Insufficient data authenticity validation, local file inclusion |
command execution with CVSS 4.0
Each weakness in Fluid Attacks' public database includes its CVSS v4.0 vector, requirements and fixes by language.
In the State of Attacks 2026, "authentication mechanism absence or evasion" alone accounted for 19.1% of total risk exposure, and the top 10 weaknesses together carried 68.4%.
Conclusions
Vulnerability management is a cycle of finding, ranking, fixing and verifying, and it fails at whichever stage gets skipped. CVSS alone ranks by potential damage; vulnerability management that adds EPSS, KEV and reachability analysis ranks by real likelihood.
Scanners find most vulnerabilities, but pentesters find most of the risk, and our 2025 data shows 87% of critical findings came from manual testing. The controls that move remediation the most are the least glamorous: reattacks and breaking the build. Vulnerability management works when every finding ends in a verified fix or a documented decision.
Frequently asked questions
What is the difference between vulnerability management and vulnerability assessment?
Assessment is one stage of vulnerability management. Assessment identifies and reports weaknesses at a point in time. Vulnerability management also prioritizes them, assigns and treats them, verifies each fix and repeats the cycle continuously. A program that only assesses produces reports; one that manages produces verified fixes and lower risk exposure.
Is CVSS enough to prioritize vulnerabilities?
No. CVSS measures potential severity in a generic worst case, not the likelihood of exploitation. In FIRST's October 2023 measurement, fixing every CVE with a CVSS 3.x score of 7 or higher was only about 4% efficient. Combining CVSS with EPSS, the CISA KEV catalog and reachability analysis gives a ranking closer to real risk.
Can vulnerability management be fully automated?
Not today. Tools detect most vulnerabilities and can fix simple dependency issues, but in Fluid Attacks' State of Attacks 2026, 87% of critical-severity findings came from manual testing, and GenAI fixes were used mostly on low- and medium-severity issues. Automation speeds up detection and routine fixes, but vulnerability management still needs people for triage and verification.
Does breaking the build speed up vulnerability remediation?
Yes. In the State of Attacks 2026, systems using Fluid Attacks' CI Gate remediated vulnerabilities with a median of 22 days versus 30 for those that did not, and reached a 72.2% remediation rate versus 58%. That median is 26.7% faster.
Does Fluid Attacks offer vulnerability management?
Yes. Fluid Attacks combines AI, proprietary scanners and pentesters to find vulnerabilities, and its platform handles prioritization with EPSS, KEV and reachability, assignment, GenAI remediation support and reattacks to verify each fix. Pentesters attach exploitation evidence to their findings, and CI Gate can break the build to stop risky deployments.
Close the loop on every finding
Fluid Attacks runs vulnerability management as one continuous program that finds, ranks and retests your vulnerabilities, so every fix is verified before it counts. Start free trial · Contact us.
Get started with Fluid Attacks' RBVM solution right now
