What is a Vulnerability Management Program and How to Build It

In 2025, 48,185 CVEs were published, a new record and a jump of roughly 22 percent over 2024's already overwhelming total, according to the 2026 Edgescan Vulnerability Statistics Report, now in its 11th year. The CISA Known Exploited Vulnerabilities catalog grew to 1,484 entries by year end, with 246 added during 2025 alone. Eoin Keary, Edgescan's CEO and founder, put the implication plainly in the report itself: the volume of CVEs is not going to decrease, so what has to change is how organizations respond to it.

That framing matters more than it sounds like it should. A vulnerability management program is not a project you finish. It is the ongoing discipline of identifying, prioritizing, and remediating weaknesses in your systems and networks faster than someone else finds and uses them first. Build it well and you materially improve your security posture. Build it as a one-time checklist exercise and you will be re-explaining to leadership next year why the same category of finding is still open.

The remediation gap is where most programs actually fail

Detection has gotten genuinely good. Response has not kept pace. For high and critical severity application and API vulnerabilities, the average mean time to remediate in 2025 was 54.81 days, per Edgescan. Device and network-level high and critical vulnerabilities fared better at 39 days, but for larger enterprises with 1,000 or more employees, 37 percent of vulnerabilities discovered in a given 12-month period simply remain unresolved when the window closes.

Part of the pressure comes from how fast exploitation now follows disclosure. The average time between vulnerability disclosure and confirmed exploitation has collapsed from months and weeks down to mere hours since 2019, according to SANS research cited by TechTarget. 'Organizations should stop treating vulnerability management as a closed loop ending in a patch,' said Nicole Carignan, senior vice president of security and AI strategy and field CISO at Darktrace. Her point was that teams need to know where they are exposed and what normal behavior looks like well enough to spot and contain out-of-place activity before it escalates, not just wait for the patch to land.

What CISA just required of federal agencies previews where everyone else is headed

CISA's binding operational directive 26-04 replaces traditional severity-driven patch management with a risk-based model for federal civilian executive branch agencies, weighing active exploitation, internet exposure, exploit automation potential, and attack impact rather than CVSS score alone. It requires remediating the highest-risk vulnerabilities within three days, with lower-priority items deferrable, and mandates a full forensic triage after high-priority remediation to check whether systems were already compromised before the patch landed.

Jeffrey Wheatman, senior vice president and cyber-risk strategist at Black Kite, argues the same logic applies well beyond government: build remediation tiers with realistic targets rather than one undifferentiated patching backlog, and supplement patching itself with compensating controls, disabling vulnerable features, blocking known exploit pathways, rotating exposed credentials, and tightening monitoring on assets you cannot patch on schedule.

Building the program: what still matters, updated

Start with ownership, not tooling. Most organizations put a security or IT department in charge, with a manager and one or more analysts responsible for detection, tracking, and remediation. Others bring in a cyber security company to run the program end to end, which tends to make sense once the internal team is spending more time triaging alerts than actually closing findings. Either model can work. What does not work is splitting ownership across departments with no single person accountable for whether the backlog is actually shrinking.

From there, the cycle is identify, evaluate, treat, and report, run continuously rather than as a quarterly event. Identification means scanning the full asset inventory, servers, endpoints, firewalls, switches, and increasingly IoT devices, against an up-to-date configuration management database, because a scanner cannot assess an asset it does not know exists. Evaluation is where teams now need to layer in more than a CVSS score: exploitability data, asset criticality, and whether the vulnerability sits on a path to something that actually matters. Treatment takes one of three forms. Remediation, actually fixing the flaw, is the best outcome when it is available. Mitigation buys time through compensating controls when a patch is not yet ready. Acceptance is a legitimate choice for genuinely low-risk findings where the cost of fixing exceeds the realistic cost of exploitation, but it should be a documented decision, not a default born of a backlog nobody got to.

Reporting closes the loop. Teams that track mean time to remediate by severity and asset type can tell leadership, with real numbers, whether the program is improving or quietly falling behind. Teams that only report a point-in-time vulnerability count cannot answer that question at all.

What has changed most since this discipline first became standard practice is how much weight any single score deserves.

'Organizations were never supposed to stop at the base score of a CVE,' said Jeff Williams, founder and CTO of Contrast Security and a co-founder of OWASP. 'The real value comes from combining technical severity with threat intelligence, environmental context and business impact.' A CVSS score is still a reasonable starting filter, but treating it as the final word on priority is exactly the habit that leaves the highest-value targets sitting unpatched behind a wall of lower-risk noise.

Common mistakes, and the ones that got worse

The old failure modes still apply: scanning only internal or only external assets instead of both, running scans against a stale configuration management database that misses new assets entirely, generating reports nobody acts on, and scanning on a cadence that does not match how fast your environment actually changes. Two mistakes have gotten more costly in 2026 specifically. Treating CVSS as sufficient on its own, without exploitability and asset-criticality context, wastes remediation capacity on the wrong targets. And assuming that if something cannot be patched immediately there is nothing else to do ignores the entire category of compensating controls Wheatman and Carignan both point to. if a system cannot be patched quickly, the organization still needs to be able to detect attempted exploitation and contain it fast, ideally through automation rather than a human watching a dashboard.

Who actually needs this, and the honest tradeoff

Every organization with internet-facing or even purely internal assets needs some version of this discipline, not primarily to satisfy an auditor but because, per Edgescan, more than 20 percent of discovered internet-facing vulnerabilities across the full stack are already critical or high severity. The tradeoff worth being honest about: doing this well, with behavioral analytics, exploit-likelihood scoring, and continuous asset discovery, takes resourcing most small and mid-size organizations cannot build entirely in-house. That is the legitimate case for bringing in a cyber security company to run or augment the program, not because the internal team lacks competence, but because the tooling and threat-intelligence feeds needed to do risk-based prioritization properly have real, ongoing cost.

Final thought

The goal was never zero open vulnerabilities. With 48,185 new CVEs landing in a single year, that target is not realistic for anyone. The real goal is shrinking, continuously, the population of vulnerabilities that are both exploitable in your specific environment and reachable by an attacker, while accepting that some lower-risk findings will sit open under compensating controls rather than consuming remediation capacity that belongs elsewhere. That is a less satisfying conclusion than patch everything, but it is the one the current volume of vulnerabilities actually supports.