Table of Contents
What is Vulnerability Management?
Vulnerability management (VM) is the continuous, proactive process of identifying, classifying, prioritising, remediating, and verifying security vulnerabilities across an organisation's IT infrastructure, applications, and services.
The key word is continuous. Vulnerability management is not a one-time audit or a quarterly scan. New vulnerabilities are disclosed every day (the NVD processes 70–100 new CVEs daily), your software inventory changes, and threat actors are constantly probing for unpatched systems. An effective VM programme runs as an ongoing operational function.
The VM Lifecycle
Vulnerability management follows a repeating cycle. No phase is "done" — the process loops continuously as new assets are discovered and new CVEs are published.
Phase 1: Asset Discovery and Scanning
You cannot manage vulnerabilities in assets you do not know exist. The first step is building and maintaining a comprehensive asset inventory — every server, workstation, network device, cloud instance, container, and application.
Types of Vulnerability Scans
| Scan Type | How it works | Best for |
|---|---|---|
| Unauthenticated (network) scan | Probes open ports and services remotely; identifies service versions and known CVEs via banner matching | Quick external exposure check; no agent needed |
| Authenticated (credentialed) scan | Logs into each host and reads installed software, patch levels, and configurations directly | Accurate, comprehensive internal scanning — far fewer false positives |
| Agent-based scan | Lightweight agent installed on each host continuously reports vulnerability data | Cloud and remote assets without network access; real-time visibility |
| DAST (dynamic application scan) | Tests running web applications for XSS, SQLi, and other web vulnerabilities | Web application vulnerability detection |
| SAST (static application scan) | Analyses source code or compiled binaries for coding weaknesses (CWEs) | Finding vulnerabilities during development, before deployment |
| SCA (software composition analysis) | Scans dependencies (npm, PyPI, Maven, etc.) against CVE databases | Open source library vulnerabilities; supply chain risk |
| Container scan | Scans Docker/OCI images for vulnerable OS packages and application libraries | Pre-deployment container security gates |
Phase 2: Risk-Based Prioritisation
A mid-sized organisation might have 50,000 open vulnerabilities at any given time. Patching everything immediately is impossible. Risk-based prioritisation separates what to fix now from what can wait.
Factors in Prioritisation
- CVSS Base Score — Starting point for severity. But CVSS alone is insufficient.
- CISA KEV — Is it on the Known Exploited Vulnerabilities list? If yes, it is being actively exploited and should jump to the top.
- Exploit availability — Is there a public exploit or Metasploit module? Exploitability dramatically increases risk.
- Asset criticality — A CVSS 6.0 vulnerability on a publicly accessible payment server is more urgent than a CVSS 9.0 on an air-gapped test system.
- Network exposure — Is the vulnerable service exposed to the internet, to the internal network, or isolated?
- Data sensitivity — Does the affected system store PII, financial data, or health records?
EPSS: Exploit Prediction Scoring System
The Exploit Prediction Scoring System (EPSS) is an open model that predicts the probability a given CVE will be exploited in the wild within the next 30 days, expressed as a 0–1 probability score. It is maintained by FIRST (Forum of Incident Response and Security Teams).
Research has shown that combining CVSS with EPSS dramatically reduces the volume of CVEs that need immediate attention. Approximately 6% of new CVEs have a CVSS of 9.0+, but only about 3% of all CVEs are ever actively exploited. EPSS helps identify which high-CVSS vulns are the ones actually being used by attackers.
Practical Priority Tiers
| Priority | Criteria | Target Remediation |
|---|---|---|
| P1 — Immediate | CISA KEV listed, or CVSS 9+ AND EPSS >0.5, or active exploitation observed internally | 24–72 hours |
| P2 — Critical | CVSS 9.0–10.0 on internet-facing or critical assets | 7–15 days |
| P3 — High | CVSS 7.0–8.9, or CVSS 9+ on non-critical internal assets | 30 days |
| P4 — Medium | CVSS 4.0–6.9 | 60–90 days |
| P5 — Low | CVSS below 4.0 or compensating controls in place | Next cycle or accept risk |
Phase 3: Remediation
Remediation is the most resource-intensive phase. The goal is to eliminate or reduce the risk of each vulnerability. Options include:
- Patch — Apply the vendor's security update. This is the preferred option when a patch is available and tested.
- Upgrade — Move to a non-vulnerable version of the software.
- Configuration change — Disable the vulnerable feature, restrict access, or change a setting to eliminate the attack surface.
- Virtual patching — Use a WAF, IPS, or network control to block exploitation of the vulnerability without patching the underlying software. A temporary measure when patching is not immediately possible.
- Compensating control — Implement an alternative security control (network segmentation, enhanced monitoring) when the vulnerability cannot be patched.
- Accept risk — For very low-risk vulnerabilities, document the decision and review periodically. Risk acceptance must be formally approved by a risk owner.
- Decommission — Remove end-of-life systems or services that cannot be patched and are no longer needed.
Phase 4: Verification
After remediation, rescan the affected asset to confirm the vulnerability is gone. Do not close a ticket based on a developer's confirmation alone — verify with the scanner. For critical vulnerabilities, consider a manual test or a targeted penetration test to confirm exploitability has been eliminated.
Track mean time to remediate (MTTR) — the average time between vulnerability discovery and verified fix. This is the primary KPI for a vulnerability management programme.
Vulnerability Management Tools
| Tool | Category | Key Feature |
|---|---|---|
| Tenable Nessus / Tenable.io | Infrastructure VM | Industry-standard network and host scanner; 100,000+ plugins |
| Qualys VMDR | Infrastructure VM (cloud) | Continuous scanning with asset inventory and patch orchestration |
| Rapid7 InsightVM | Infrastructure VM | Risk-based scoring with real-time threat intelligence |
| Microsoft Defender VM | Endpoint VM | Built into Microsoft 365 Defender; excellent Windows/Azure coverage |
| Snyk | Application + Container | Developer-friendly; deep open source and container scanning |
| Dependabot | SCA (open source) | Built into GitHub; auto-creates PRs for vulnerable dependencies |
| Trivy | Container + IaC | Open source; scans Docker images, Terraform, Kubernetes manifests |
| OpenVAS | Infrastructure VM | Open source alternative to commercial scanners |
| OWASP ZAP | DAST (web apps) | Free dynamic web application scanner |
VM and Compliance Frameworks
Vulnerability management is a mandatory control in most major compliance frameworks:
- PCI DSS — Requirement 6.3 (security vulnerabilities addressed), Requirement 11 (scanning and penetration testing). Internal scans quarterly; external scans by an ASV quarterly.
- ISO 27001 — Control 8.8 (Management of technical vulnerabilities). Requires a formal process for timely identification and remediation.
- NIST CSF — Identify function includes asset management and vulnerability assessment. Protect function includes timely patch management.
- SOC 2 — Common Criteria CC7.1 requires monitoring for vulnerabilities and maintaining a patch management process.
- HIPAA — Security Rule requires regular review and modification of security measures, which includes vulnerability scanning and patching.
- CISA BOD 19-02 — US federal agencies must remediate critical CVEs within 15 days, high within 30 days. The CISA KEV catalog has specific remediation deadlines per entry.