What is vulnerability management?

Key takeaways

Vulnerability management is the continuous practice of identifying, assessing, prioritising, remediating and verifying software and configuration weaknesses across an environment. It is the oldest mandatory function in security operations and, in most organisations, still the least satisfying to run.

• Prioritisation is necessary and insufficient. Ranking a backlog is not the same as reducing it. A well-sorted list of 40,000 findings is still 40,000 findings.
• Most findings are not exploitable in a given environment. Reachability and validation remove the large majority of a raw finding set before any remediation effort is spent.
• Scanning is not the differentiator. Discovery is well served by mature tooling. The unsolved work begins once a finding exists.
• Ownership is the hidden constraint. CMDB ownership data is routinely incomplete, so tickets reach the wrong team or no team at all.
• The exploit timeline has compressed. Volume has grown steadily for years, but the interval between disclosure and a working exploit has shortened sharply, which is what makes a monthly patch cadence harder to defend.

01 - Why does it matter?

Vulnerability management is the oldest mandatory function in security and still one of the least satisfying to run. The reason is structural: the function is measured on coverage and judged on closure, and the two have drifted apart.

The external evidence is unambiguous. The Verizon 2026 Data Breach Investigations Report finds exploitation of known vulnerabilities is now the leading initial-access vector in breaches at 31%, ahead of credential abuse for the first time. On CISA's Known Exploited Vulnerabilities catalog - the most authoritative short list in the industry - the median time to full remediation has risen to 43 days, with only 26% ever fully fixed. Two decades of tooling investment has not moved the number that matters.

Scanning became cheap and comprehensive, and the result is finding volume that no team can process. A skilled analyst can investigate perhaps ten to twenty vulnerabilities a day against a backlog measured in tens of thousands. The industry's response was prioritisation: better scoring, threat intelligence enrichment, business context. All of it useful; none of it a substitute for the work. A smaller list of must-do work is still work, and it still lands on teams outside security who own the systems, control the change windows and have their own priorities.

• Volume outruns capacity. Millions of findings, a double-digit daily investigation rate, and no realistic path to the bottom of the queue.
• Findings that cannot be exploited bury the ones that can. A large share of findings are not exploitable in the environment, and separating them by hand costs more than most teams can spend.
• Scores are not evidence. CVSS describes a vulnerability in general. It cannot see a particular network, call graph or control set.
• Ownership is unknown. Configuration management records are routinely incomplete or stale, so tickets reach the wrong team or no team.
• Remediation belongs to someone else. A security function cannot patch a server or merge a pull request. Handing over a list is not the same as getting a fix.
• Compliance substitutes for risk reduction. Programmes scan on the audit calendar and report coverage, because coverage is what gets asked about.

02 - What is vulnerability management?

Vulnerability management is the continuous practice of identifying, assessing, prioritising, remediating and verifying software and configuration weaknesses across an environment.

Traditional programmes run as a cycle of scan, report, ticket, rescan. Risk-based vulnerability management added prioritisation intelligence - threat intelligence, exploit prediction, asset criticality - to decide what to fix first. Exposure management widens the aperture again, to weaknesses that are not vulnerabilities at all: misconfigurations, unmanaged assets, identity weaknesses and attack paths.

The distinction is worth keeping straight, because the terms are used interchangeably in marketing and are not interchangeable in practice. A programme can be excellent at vulnerability management and still have no view of an identity misconfiguration that offers an easier route to the same data.

03 - How the terms relate

Most organisations do not choose between these. They grow a vulnerability management function into an exposure programme, and the practical question is which parts of that expanded cycle they are paying someone to remove.

• Vulnerability management. Concerned with vulnerabilities, usually CVEs, usually on assets. Measured on scan coverage, patch compliance and time to remediate.
• Risk-based vulnerability management (RBVM). The same function with prioritisation intelligence layered on: exploit prediction, threat intelligence and asset criticality decide the ordering.
• Exposure management. Covers any weakness an attacker could use, vulnerability or not, including misconfigurations, unmanaged assets, identity weaknesses and attack paths.
• Continuous threat exposure management (CTEM). Gartner's programme framework for running exposure management as a repeating cycle: scoping, discovery, prioritization, validation, mobilization.
• Exposure assessment platforms (EAP). Gartner's market name for the tooling that discovers and prioritises exposures across asset classes.
• Adversarial exposure validation (AEV). Gartner's market name for the tooling that tests exploitability directly, absorbing breach and attack simulation and automated penetration testing.

04 - The vulnerability management lifecycle

• Asset inventory. Establishing what exists, including the assets that endpoint and configuration tooling has marked unmanaged. Everything downstream inherits the gaps here.
• Discovery and assessment. Network scanning, agent-based assessment, cloud posture checks, software composition analysis and code analysis, each producing findings in its own identifier scheme.
• Normalisation and de-duplication. Reconciling findings that describe the same weakness on the same asset from several tools into one record before analysis begins.
• Prioritisation. Combining intrinsic severity, exploitation signals and business criticality to order the work. CVSS supplies severity, EPSS supplies likelihood, KEV supplies confirmed exploitation.
• Validation. Establishing whether the prioritised finding is exploitable in this environment, through reachability analysis and, where warranted, direct testing.
• Remediation and mitigation. Patching, upgrading, rebuilding an image, changing a configuration, or applying a compensating control where none of those is available in time.
• Verification and reporting. Confirming the fix landed and the finding is closed, rather than closed in the ticket system and still present on the asset.

05 - Three views of the same finding

A single vulnerability record has to be rendered at least three ways, because three different people act on it and each needs a different unit of work. Most point tools render one of the three, and the resulting friction is often mistaken for a data quality problem.

Per CVE. A widely publicised vulnerability tracked across every affected asset. Fix once, close many. This is the security and vulnerability management team's view, and it is the one that reporting and audit expect.

Per asset. Every outstanding patch for one machine, batched. IT patches a box inside one window, so the useful answer to an operator who says they have an hour is a specific set of changes that fits the hour, not a ranked list that does not.

Per application. An installed application cannot always have a bundled component upgraded independently; the remediation is to move the application to a supported version, or to go to the supplier. This is the platform and engineering view, and it explains why a per-CVE instruction is sometimes impossible to follow.

The finding underneath is identical in all three, and disagreement between teams about what should be done is frequently a disagreement about which view they are looking at.

06 - What has actually changed recently

The variable that moved is not vulnerability volume. That has grown steadily for years and the growth is well understood. It is the interval between a vulnerability becoming public and a working exploit existing. Frontier AI models have compressed that window substantially, so a patch cadence measured in weeks is being asked to defend against an exploit timeline measured in hours or days. The arithmetic that made a monthly patch cycle defensible no longer holds for internet-facing systems.

A second change is that disclosure is no longer reliably the starting gun. The gap between a compromise being actively exploited and a CVE identifier being assigned can run to months. The 2025 Notepad++ supply-chain compromise was live and required remediation well before CVE-2025-15556 was assigned in early 2026, and a programme keyed exclusively to CVE identifiers was structurally blind for that entire period. The practical response is to correlate emerging-threat reporting against the installed software inventory rather than wait for a numbered advisory.

07 - How to evaluate a vulnerability management programme

• Report closure rate, not scan coverage. Coverage measures effort. The meaningful figures are the proportion of exploitable findings closed and the elapsed time from detection to verified closure.
• Separate exploitable from present. Track the size of the actionable set alongside the raw finding count. A programme that cannot state the difference is managing a scanner, not a risk.
• Audit ownership coverage. The percentage of assets with a named, current owner is the single best predictor of whether findings will close.
• Subtract routine cadence. A substantial share of findings will close through the owning team's normal patch cycle. Escalating those costs credibility needed elsewhere.
• Check that verification is real. A finding closed in the ticket system and still present on the asset is a reporting artefact. Verification should be by rescan or by attestation from the change record.

08 - Common misconceptions

• A critical CVSS score means urgent action. CVSS describes intrinsic severity under worst-case assumptions. It is an input to prioritisation, and FIRST's own guidance is that it should not be used alone to drive remediation order.
• Better prioritisation solves the backlog. Prioritisation improves the ordering of the queue. It does not address the queue's existence, and the work still has to be performed by teams outside security.
• Unpatchable means unmanageable. Where a fix is not available on the required timeline, compensating controls, network segmentation and exposure-specific detection are legitimate risk treatments and should be recorded as such.

09 - Standards and sources

Vulnerability management is unusually well served by public standards. The CVE Program assigns identifiers to publicly disclosed vulnerabilities and the National Vulnerability Database enriches them. FIRST maintains CVSS for intrinsic severity and EPSS for exploitation likelihood. CISA maintains the Known Exploited Vulnerabilities catalog. NIST SP 800-40 covers enterprise patch management planning, and CycloneDX and SPDX are the two established SBOM formats.

Frequently Asked Questions

Does exposure management replace vulnerability management? No. Exposure management is a wider practice that includes vulnerability management. Scanning and patching known vulnerabilities remains mandatory under most regulatory regimes. What changes is that vulnerabilities become one input among several rather than the whole picture.

How is risk-based vulnerability management different from vulnerability management? Risk-based vulnerability management improves the ordering of the queue by adding threat intelligence, exploit prediction and asset criticality to raw severity. It answers what should be done first. It does not answer whether a finding is exploitable in this environment or whether it has been closed.

What should be done about vulnerabilities that cannot be patched? Some exposures cannot be closed on the timeline the risk demands, whether because of a change window, a dependency, or a system that cannot be taken down. The established treatments are compensating controls, network segmentation and detection coverage scoped to that specific exposure, recorded as an accepted risk with a review date rather than left silently open.

How many findings should a programme expect to be genuinely exploitable? Far fewer than are reported. Reachability analysis typically removes the large majority of a raw finding set, because most vulnerable components are either not in a runtime path, not callable from application code, or not reachable by attacker-controlled data. The exact proportion varies with the environment, the language ecosystem and the mix of scanners in use.

Which metrics actually indicate a healthy programme? Time from detection to verified closure, the proportion of exploitable findings closed within the risk window, ownership coverage across the asset estate, and the size of the actionable set relative to the raw finding count. Scan coverage and total findings measure activity rather than outcome.