What is vulnerability management?
Updated
Vulnerability management is the continuous, cyclical process of identifying, prioritizing, remediating, and verifying security weaknesses across an organization's software and systems. It is not a one-time scan but an ongoing program, because new vulnerabilities are disclosed constantly and a component that was clean yesterday can become vulnerable today with no change to your code.
The defining challenge is not finding vulnerabilities — scanners surface thousands — but deciding which to fix first. A raw list sorted by severity buries the few genuinely dangerous findings under many that will never be exploited, so the value of a mature program is in prioritization: combining severity, exploitation likelihood, confirmed activity, and asset exposure into a short, defensible queue.
The vulnerability management lifecycle
A working program cycles through discovery, prioritization, remediation, and verification. Discovery inventories assets and scans them — spanning first-party code (SAST), dependencies (software composition analysis), running systems (DAST), and committed secrets. Prioritization ranks the findings by real risk. Remediation patches, upgrades, mitigates, or accepts each. Verification confirms the fix actually landed, and the cycle repeats as new findings arrive.
Two honest-reporting disciplines run through the whole cycle. First, deduplicate: a single shared library CVE appears once per repository, so per-occurrence counts multiply one advisory into dozens and overstate the problem — count distinct vulnerabilities and normalize against estate size. Second, distinguish 'scanned clean' from 'never scanned'; a zero from a scanner that never ran is a blind spot, not a good result.
Prioritization and measuring the program
Effective prioritization layers complementary signals: CVSS for potential impact, EPSS for near-term exploitation likelihood, the CISA KEV catalog for confirmed active exploitation, and whether the affected asset is actually reachable. A defensible order fixes KEV entries first, then high-likelihood high-impact findings, rather than marching down a severity-sorted list that ignores whether anything is actually being exploited.
The program is measured by outcomes over the lifecycle, not by scan counts. Useful metrics include how many findings are open versus fixed, remediation time against a service-level target by severity, the share overdue past their fix-by deadline, and the age of the oldest open critical findings. These describe whether the process is keeping pace with incoming risk — the question a raw vulnerability count cannot answer.
Frequently asked questions
What is vulnerability management?
It is the continuous process of identifying, prioritizing, remediating, and verifying security weaknesses across systems and software. Because new vulnerabilities are disclosed constantly, it is an ongoing program rather than a one-time scan, and its hardest part is deciding which of the many findings to fix first.
How should vulnerabilities be prioritized?
By combining signals rather than sorting on severity alone: CVSS for impact, EPSS for exploitation likelihood, the CISA KEV catalog for confirmed active exploitation, and whether the asset is actually exposed. A strong default fixes KEV entries first, then high-likelihood high-impact findings, which turns a huge backlog into a short, defensible queue.
How do you measure a vulnerability management program?
By lifecycle outcomes, not scan counts: open versus fixed findings, remediation time against a service-level target by severity, the share overdue past their deadline, and the age of the oldest open critical findings. Counts should also deduplicate to distinct vulnerabilities and separate 'scanned clean' from 'never scanned' to stay honest.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.