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:

- **Network scans**: Nessus, Qualys, OpenVAS — find network-level issues

- **Web app scans**: OWASP ZAP, Burp Suite — find web vulnerabilities

- **Container scans**: Trivy, Grype — find image vulnerabilities

- **Dependency scans**: Dependabot, Snyk — find library vulnerabilities

- **Cloud config scans**: AWS Inspector, Prisma Cloud — find misconfigurations

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

External notifications

- **CVE databases**: NIST NVD, CISA KEV (Known Exploited Vulnerabilities)

- **Vendor disclosures**: cloud providers, OS vendors

- **Bug bounty programs**: external researchers

- **Threat intelligence**: paid services

Asset inventory

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

- Inventory of services, hosts, containers

- Owners per service

- Dependencies and contact for each

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:

- **Critical and exploitable and exposed**: fix in days

- **Critical or actively exploited**: fix in days/weeks

- **High severity**: fix in weeks

- **Medium**: fix in months

- **Low**: when convenient

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:

- Network controls (block at firewall)

- Configuration changes (disable feature)

- WAF rules (block specific patterns)

- Compensating controls (additional monitoring)

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:

- Re-scan to confirm vulnerability is gone

- Test the fix actually works

- Document the verification

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:

- **MTTR (Mean Time To Remediate)**: by severity

- **Vulnerability backlog**: open vulnerabilities by age, severity

- **Trend**: improving or worsening?

- **SLA compliance**: vulnerabilities fixed within targets?

Reports for:

- Engineering teams (their work)

- Security team (overall posture)

- Leadership (risk picture)

- Compliance auditors

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

- **No prioritization.** All vulnerabilities treated as critical; nothing gets done.

- **Slow patching of critical CVEs.** Time-to-patch is a key metric.

- **No ownership.** Vulnerabilities found; nobody owns the fix.

- **No verification.** Patched but not verified.

- **Risk acceptance without governance.** "We won't fix it"; no review.

- **No asset inventory.** Scan misses things.

- **Compliance theater.** Scan reports filed; vulnerabilities unfixed.

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.