4 Vulnerability Management

Understand the continuous process

Vulnerability management is a continuous process: find security weaknesses, decide which ones matter most, reduce the risk they pose, and check that the response worked. It is not a one-time scan because new assets, software, and threat information continually change an organization’s exposure.

A reliable program connects findings to an accurate asset inventory, accountable owners, and a tracked remediation process. Discovery should begin with knowing what the organization operates, including hardware, operating systems, applications, cloud resources, internet-facing services, and software components.

Discover and confirm vulnerabilities

Use complementary methods to discover weaknesses. A vulnerability scanner compares observed systems and configurations with known weaknesses. Credentialed scans can inspect more system details than unauthenticated scans, while external scans show what an outside observer can reach.

Software composition analysis (SCA) identifies vulnerable third-party libraries and packages, including dependencies that may not be visible in a network scan. Cloud and configuration assessments check for insecure settings as well as known software flaws.

Security advisories, vendor notices, threat intelligence, penetration tests, and responsible vulnerability reports can reveal issues that automated tools miss. Keep detection tools and vulnerability data current, and repeat discovery regularly and after significant changes.

A scanner finding is a lead, not always proof. Confirm that the affected product and version are present, check whether the vulnerable feature is enabled or reachable where relevant, and determine whether the result is a false positive.

Prioritize findings by risk

A list sorted only by severity can misdirect limited remediation time. CVSS describes technical severity, but it does not by itself determine the risk to a particular organization. Consider each finding in context:

• Exploit evidence: Check whether the vulnerability is listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog or whether exploitation is otherwise observed.

• Likelihood: Consider whether exploit code is available and what threat intelligence indicates. FIRST’s EPSS estimates the probability that a publicly disclosed vulnerability will be exploited in the wild within 30 days; it is a likelihood signal, not a complete risk score.

• Asset context: Consider whether the affected system is internet-facing, business-critical, sensitive, or a path to other systems.

• Exposure and controls: Check whether the vulnerable component is reachable and enabled, and whether segmentation or other safeguards reduce exposure.

• Potential impact and urgency: Consider whether exploitation could threaten safety, confidentiality, integrity, or essential operations.

A remotely exploitable flaw on an exposed, business-critical server—especially one already listed in KEV—will usually deserve faster attention than a higher-severity flaw on an isolated test system with the vulnerable feature disabled. Record the prioritization rationale, owner, deadline, and any temporary safeguards.

Remediate, mitigate, or accept risk

Choose a response that fits the risk and operational constraints:

• Remediate: Install a security patch, upgrade or replace affected software, or correct vulnerable code or configuration.

• Mitigate temporarily: If a safe fix is unavailable or cannot yet be deployed, reduce exposure by disabling the affected feature, restricting access, or isolating the system. Track the mitigation and plan a permanent fix where feasible.

• Accept the risk: If an authorized decision-maker determines that remediation is not warranted or cannot be completed in time, document the rationale, residual risk, approval, safeguards, and review date. Risk acceptance is not the same as fixing the flaw.

Use a controlled workflow: assign the finding to an accountable owner, test changes where practical, schedule deployment, consider service availability and rollback, and record completion. Enterprise patch management includes identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades.

Validate responses and improve the process

Do not close a finding solely because a change was requested or installed. Validate the response by rescanning or retesting the affected asset, checking its software version or configuration, and confirming that the vulnerable component is no longer exposed. If mitigation was used, test that it works and document the risk that remains.

If a finding persists, investigate possible incomplete deployment, an incorrect asset match, a required restart, or a false positive before deciding what to do next.

Track measures that show whether the process is effective, such as asset coverage, time to remediate high-risk findings, overdue items, repeat findings, and the proportion of fixes validated. Use these results to improve scanning, ownership, prioritization, and patch deployment.

• Validation