Vulnerability Management

Vulnerability management is the continuous cycle of finding weaknesses in your systems, deciding which ones matter most, fixing or mitigating them, and verifying the fix. The weaknesses come from everywhere: operating system packages, open-source dependencies, container images, cloud misconfigurations, network exposure, and your own code.

The hard part is not finding vulnerabilities — scanners produce thousands — but prioritizing them. Most published vulnerabilities are never exploited in the wild, while a small fraction are exploited within days of disclosure. Teams that treat every "critical" score as an emergency burn out and still miss the vulnerability that matters; teams that prioritize by real-world exploitation and exposure fix less and reduce more risk.

TL;DR

Quick Example

Risk-based prioritization of scanner findings: known exploitation and exposure first, CVSS last.

The CVSS 9.8 finding ranks third: it is serious in theory, but nothing suggests it is being exploited and the asset is not exposed. The 7.5 is being exploited right now on an internet-facing gateway.

Core Concepts

The Vulnerability Management Cycle

CVE, CVSS, EPSS, and KEV

CVSS answers "how severe if exploited?"; EPSS and KEV answer "how likely, or already happening?". Risk needs both, plus your context.

Sources of Vulnerabilities

SBOM and VEX

A software bill of materials (SBOM) lists the components inside a piece of software, so a newly disclosed CVE can be matched to affected products in minutes rather than days. VEX (Vulnerability Exploitability eXchange) statements record whether a product is actually affected by a CVE in a component — for example, "not affected: the vulnerable function is never called" — which removes noise for downstream consumers. See Software Supply Chain Security.

Prioritizing by Risk

Combine four factors:

  1. Exploitation evidence — listed in KEV, public exploit code, vendor or threat-intelligence reports.
  2. Exploit likelihood — EPSS score, ease of exploitation, attacker interest.
  3. Exposure — reachable from the internet, from all employees, or only from an isolated network; whether the vulnerable code path is actually reachable.
  4. Asset criticality — the data and functions the asset touches and the damage its compromise would cause.

Remediation SLAs

Publish the SLAs, measure compliance, and review misses — a consistently missed SLA usually reveals a process problem, such as no owner or no safe way to deploy patches.

Remediation in Practice

Automate the Routine Path

Most fixes are version bumps. Dependency bots (Dependabot, Renovate) open update pull requests automatically; base images rebuild nightly; operating systems apply security updates on a schedule. Good test coverage and safe deployment practices are what make fast patching possible.

Mitigate When You Cannot Patch

When no fix exists or patching must wait, reduce exposure: disable the vulnerable feature, block the attack path with a web application firewall rule or network control, restrict access, or add detection for exploitation attempts. Record the mitigation and keep the finding open until the real fix lands.

Exceptions With Expiry

Some findings will be accepted — false positives, unreachable code, systems scheduled for retirement. Every exception needs a justification, an owner, compensating controls where relevant, and an expiry date that forces review.

Best Practices

Assign an Owner to Every Asset

A finding without an owner is a finding that never gets fixed. Tie assets to teams through tags, service catalogs, or the asset inventory, and route findings to those owners automatically.

Scan Where Changes Happen

Scan dependencies and images in pull requests and CI, so new vulnerabilities are caught before deployment, and rescan deployed assets continuously, because new CVEs are disclosed against software that has not changed.

Measure Outcomes, Not Scan Counts

Track mean time to remediate by priority, SLA compliance, the age of the oldest open critical finding, and the number of KEV-listed vulnerabilities currently exposed. "Findings closed" alone rewards fixing easy, unimportant issues.

Verify Fixes

Close findings only after a rescan or test confirms the fix in the running system — not when a ticket is marked done.

Common Mistakes

Prioritizing by CVSS Alone

Ignoring Transitive Dependencies

Permanent "Accepted Risk"

FAQ

What is the difference between vulnerability management and patch management?

Patch management is the operational process of applying updates. Vulnerability management is broader: it finds weaknesses across all asset types — including misconfigurations and code flaws that no patch fixes — decides which matter most, and verifies that risk actually went down.

What is the difference between CVSS and EPSS?

CVSS rates how severe a vulnerability would be if exploited, on a 0–10 scale. EPSS estimates the probability that it will be exploited in the next 30 days, based on observed attacker activity. A high CVSS with a very low EPSS is often less urgent than a moderate CVSS with a high EPSS.

What is the CISA KEV catalog?

The Known Exploited Vulnerabilities catalog, maintained by the US Cybersecurity and Infrastructure Security Agency, lists vulnerabilities with reliable evidence of active exploitation. US federal agencies must remediate them within set deadlines, and many organizations use the catalog as their highest-priority list.

How quickly should we patch?

Known exploited vulnerabilities on internet-facing systems should be fixed or mitigated within days, ideally 24–72 hours. Less urgent findings can follow 7-, 30-, or 90-day targets. The right SLAs depend on your exposure and deployment capability; publish them and measure against them.

What is an SBOM used for?

An SBOM lists the components and versions inside your software. When a new vulnerability is announced, you can immediately determine which products and deployments contain the affected component, instead of searching manually.

Related Topics

References