Vulnerability Management

Vulnerability management is the operational discipline of finding, prioritizing, and fixing security weaknesses. It's repetitive work that never ends — new vulnerabilities are disclosed continuously.

This page covers the practices that make it sustainable.

The cycle

The vulnerability management lifecycle:

  1. Discover: scan; intake from disclosures
  2. Prioritize: which matter most
  3. Remediate: fix or mitigate
  4. Verify: confirm fixes
  5. Report: track progress; demonstrate compliance

Each step has its own tooling and process.

Discovery

Internal scanning

Scan your own systems regularly:

Different scans find different things. A mature program runs several.

External notifications

Asset inventory

You can't scan what you don't know about. Maintain:

Without inventory, scans miss things; remediation has no owner.

Prioritization

Discovered vulnerabilities almost always exceed remediation capacity. Prioritize.

CVSS scores

Common Vulnerability Scoring System. 0-10 scale; CVSS 9+ = critical; CVSS 7+ = high.

CVSS is a starting point. Real prioritization considers:

Exploitability

Known to be exploited in the wild? CISA's KEV catalog tracks this.

A CVSS 7 actively exploited > a CVSS 9 not yet exploited.

Reachability

The vulnerability is in code/system that's actually exposed? An RCE in a service behind a VPN is different from an RCE on the public internet.

Affected systems

How many systems? Critical paths or backend?

Exploit availability

Public exploit code makes the vulnerability much higher priority.

A reasonable framework:

Remediation

Patch

Apply the vendor's update. Most vulnerabilities have patches.

For library vulnerabilities, update the library. For OS vulnerabilities, OS update.

Mitigate

Sometimes patching isn't possible quickly. Mitigations:

Mitigations buy time until patches deploy.

Accept the risk

Sometimes the cost of remediation exceeds the risk. Document; review periodically; revisit when context changes.

This requires accountability — risk owners, formal acceptance, periodic review. Not "we won't fix it because it's hard."

Verification

After remediation, verify:

Without verification, you don't actually know the vulnerability is fixed. The patching script ran; that's not the same as the vulnerability being gone.

Reporting

Vulnerability management metrics:

Reports for:

Specific patterns

Automate easy patches

Dependabot auto-merges minor updates after CI passes. Reduces manual work for low-risk updates.

Owner per service

Every service has an owner who's accountable for vulnerabilities. Without ownership, fixes don't happen.

SLAs by severity

Critical: 7 days. High: 30 days. Medium: 90 days. Low: 180 days. Vary based on org's risk tolerance.

Continuous scanning

Don't wait for the quarterly scan. Continuous scanning catches issues quickly.

Exception process

For risk acceptance: documented; risk-owner-approved; time-bounded; reviewed.

Disclosure process

If you find a vulnerability in someone else's software, disclose responsibly. Coordinated disclosure: tell the vendor; give time to fix; publish after.

Bug bounty / VDP

Vulnerability Disclosure Program: how external researchers report vulnerabilities to you. Even if no bounty, having a process matters.

Common failure patterns

A reasonable starter

For organizations starting vulnerability management:

  1. Inventory: know what you have
  2. Continuous scanning: at least dependencies and containers
  3. Severity-based SLAs: with realistic targets
  4. Owner accountability: each service has someone responsible
  5. Track and report: visible metrics
  6. Iterate: improve coverage and speed over time

The goal isn't zero vulnerabilities (impossible); it's sustainable management of the ones that matter.

Further Reading