# Vulnerability Management
Vulnerability management is the continuous operational cycle of identifying, prioritizing, remediating, and verifying security vulnerabilities across an organization's technology environment. It encompasses vulnerability scanning, risk-based prioritization, remediation tracking, patch management, and verification testing.
Vulnerability management is not vulnerability scanning. Scanning is one input. Management is the discipline that converts scan findings into reduced risk. An organization that scans weekly and produces reports but does not prioritize, remediate, or verify has a scanning program. An organization that scans, prioritizes by exploitability and business impact, routes findings to responsible teams with defined SLAs, tracks remediation to completion, and verifies through rescanning has a management program. The former produces paper. The latter produces security.
The distinction matters operationally. CISA's Known Exploited Vulnerabilities (KEV) catalog documents vulnerabilities that are actively exploited in the wild. As of 2024, the catalog contains over 1,000 entries. Every one of those vulnerabilities was known (it had a CVE), scannable (vulnerability scanners detect them), and patchable (vendor patches exist). They were exploited because organizations identified them and did not remediate them in time. The gap between identification and remediation is where breaches live.
The cycle operates in five continuous phases:
Discovery. Identify every asset in the environment that could have vulnerabilities: servers, workstations, network devices, cloud instances, containers, applications, APIs, IoT devices. Discovery is a prerequisite because you cannot scan what you have not found. Discovery should integrate with the asset inventory (SPH) and attack surface management (VSD-R01) to ensure completeness.
Scanning. Run vulnerability scans against discovered assets. Authenticated scans (using valid credentials to log into systems) produce significantly more accurate results than unauthenticated scans (probing from the outside). Scan frequency should match the environment's change rate: weekly for most environments, daily for internet-facing systems, and continuous for critical infrastructure.
Scanning tools fall into two categories: network vulnerability scanners (Qualys, Tenable/Nessus, Rapid7 InsightVM) that scan infrastructure for known CVEs and misconfigurations, and application security scanners (DAST tools like Burp Suite, OWASP ZAP) that scan web applications for application-layer vulnerabilities. Both are needed. A network scan that misses a SQL injection vulnerability in a web application leaves a critical gap. An application scan that misses an unpatched operating system leaves a critical gap. Coverage requires both.
Prioritization. Not all vulnerabilities are equal. A scan of a mid-size environment may produce 5,000 to 50,000 findings. Remediating all of them simultaneously is impossible. Prioritization determines what gets fixed first.
The traditional approach (prioritize by CVSS score: Critical first, then High, then Medium) is inadequate because CVSS measures inherent severity, not operational risk. A CVSS 9.8 vulnerability on an internet-facing production system with a known public exploit and active exploitation in the wild is an emergency. The same CVSS 9.8 on an air-gapped development server behind three layers of segmentation with no known exploit is a scheduled maintenance item. CVSS does not distinguish between these scenarios.
Risk-based prioritization considers multiple factors:
CVSS score (inherent severity). Exploitability (does a public exploit exist? is it being actively exploited? check CISA KEV and EPSS). Asset criticality (is this an internet-facing production system or an internal development workstation?). Compensating controls (is the vulnerability mitigated by network segmentation, WAF rules, or other controls that reduce exploitability?). Business impact (what data or function does this system support?).
CDA's VSD-H01 mission (Advanced Vulnerability Prioritization, 20 hours) upgrades organizations from CVSS-only prioritization to this context-aware model. The result: fewer vulnerabilities get the "critical" label, but the ones that do are genuinely critical. Remediation effort is focused where it produces the greatest risk reduction.
Remediation. Fix the vulnerability. Remediation takes three forms:
Patching: applying vendor-supplied patches that fix the vulnerability. The most common and preferred remediation for software vulnerabilities. Patch management (VSD-B02, 40 hours) automates patch deployment across the environment.
Configuration change: modifying system configurations to eliminate the vulnerability. Disabling an unnecessary service, removing a default account, restricting a network port. Configuration remediation addresses misconfigurations that patches cannot fix.
Compensating control: applying a control that mitigates the vulnerability without patching it. A WAF rule that blocks exploitation of a web application vulnerability provides protection while the development team works on a code fix. Compensating controls are temporary measures, not permanent remediation. Every compensating control should have a defined expiration and a plan for permanent remediation.
Remediation must operate within defined SLAs:
| Severity | Internet-Facing SLA | Internal SLA | |----------|---------------------|-------------| | Critical (actively exploited) | 48 hours | 7 days | | Critical (exploit available) | 7 days | 14 days | | High | 14 days | 30 days | | Medium | 30 days | 60 days | | Low | 90 days | 90 days |
These SLAs are aggressive by industry standards. Many organizations operate with 30-day SLAs for critical vulnerabilities and 90 days for high. CDA's position: if a vulnerability is actively exploited and internet-facing, 30 days is 28 days too many. The attacker does not wait for your change management process.
Verification. Confirm that the remediation was effective. Rescan the system after remediation to verify the vulnerability no longer appears. A patch that was applied but did not take effect (service not restarted, configuration not reloaded, patch incompatible with the environment) is not remediation. It is the appearance of remediation. Verification closes the loop.
Vulnerability management programs should track these operational metrics:
Vulnerability density. Number of open vulnerabilities per asset, segmented by severity. Tracks the overall hygiene of the environment. Trend matters more than absolute number: is density increasing (deteriorating) or decreasing (improving)?
Mean time to remediate (MTTR). Average time from vulnerability identification to verified remediation, segmented by severity. MTTR directly measures the operational efficiency of the remediation pipeline. Industry benchmarks: 60 days for critical vulnerabilities is average. CDA targets under 14 days for critical, under 7 for actively exploited.
SLA compliance rate. Percentage of vulnerabilities remediated within the defined SLA window, segmented by severity. A 95% SLA compliance rate for critical vulnerabilities means 5% are exceeding the window. Those 5% are the highest-risk items in the environment.
Remediation velocity. The rate at which new vulnerabilities are remediated compared to the rate at which new vulnerabilities are discovered. If the organization discovers 100 new vulnerabilities per week and remediates 80, the backlog grows by 20 per week. Remediation velocity must exceed discovery velocity for the vulnerability posture to improve.
CISA KEV coverage. Of the vulnerabilities on CISA's Known Exploited Vulnerabilities catalog that affect the organization's technology stack, how many are remediated? KEV compliance should be 100% within the mandated timeline (federal agencies: per CISA BOD 22-01 deadlines; private sector: as fast as operationally possible). Any KEV vulnerability present in the environment is a vulnerability that is confirmed to be actively exploited by threat actors.
Every vulnerability has an exploitation window: the time between vulnerability disclosure (or exploit publication) and the organization's remediation. During this window, the vulnerability is known, exploitable, and unpatched in the organization's environment. Attackers operate within this window. Reducing it is the primary objective of vulnerability management.
The exploitation timeline has compressed dramatically. In the early 2000s, months could pass between disclosure and widespread exploitation. Today, exploitation of high-profile vulnerabilities (Log4Shell, MOVEit, Citrix Bleed) begins within hours to days of disclosure. Some vulnerabilities are exploited before disclosure (zero-days). The operational implication: remediation timelines measured in months are no longer viable for critical, internet-facing vulnerabilities.
Vulnerability management is required by every major compliance framework. PCI DSS Requirement 6 mandates vulnerability management processes including patching and quarterly vulnerability scanning. NIST CSF 2.0 ID.RA (Risk Assessment) and PR.IP (Information Protection Processes and Procedures) include vulnerability management. ISO 27001 A.8.8 (Management of Technical Vulnerabilities) requires timely identification and remediation. CMMC 2.0 includes multiple practices related to vulnerability scanning and remediation.
Auditors evaluate not just whether scans are conducted but whether findings are prioritized, remediated within defined SLAs, and verified through rescanning. An organization that scans quarterly but remediates annually will fail any serious compliance audit.
Unresolved vulnerabilities compound. Each scan cycle that identifies new vulnerabilities without fully remediating the previous cycle's findings adds to a growing backlog. Over time, the backlog becomes unmanageable: thousands of open findings across hundreds of systems, each representing a potential entry point for an attacker. The compound effect is why velocity matters: remediation must outpace discovery or the posture degrades continuously.
Vulnerability management is the core operational discipline within the VSD (Vulnerability and Surface Defense) domain of the Planetary Defense Model. VSD is the ocean layer: the coastline where adversaries probe and breach. Vulnerability management maps that coastline, identifies the weak points, and remediates them before the attacker lands.
CDA's Continuous Surface Reduction (CSR) methodology governs vulnerability management. "Every surface you expose is a surface we eliminate." Vulnerabilities are exposed surfaces. CSR eliminates them through the continuous cycle of discovery, prioritization, remediation, and verification.
Four TOP missions connect directly to vulnerability management:
CDA approaches vulnerability management differently from conventional scanning vendors in one specific way: we measure program effectiveness by remediation velocity and MTTR, not by scan frequency or finding count. A vendor that sells scanning licenses measures success by scan completion rates. CDA measures success by how fast vulnerabilities close and whether they stay closed. Scanning finds problems. Management solves them.
Word count: 2,028