Vulnerability Management

---
name: vulnerability-management
description: Run a full vulnerability management lifecycle — discovery, prioritization, remediation SLAs, and continuous measurement.
category: security
---

## Overview

Vulnerability management is the ongoing discipline of finding weaknesses across your estate, deciding which matter, getting them fixed on time, and proving it. It is not "run a scanner monthly" — it is a lifecycle: **discover → assess → prioritize → remediate → verify → report**. Done well, it is the highest-ROI security program most organizations run.

This skill covers building that lifecycle: asset coverage, risk-based prioritization, SLA design, exception handling, and metrics that show progress instead of scanner noise.

Vulnerability management is where security theory meets organizational reality: it succeeds or fails on asset ownership, engineering relationships, and the credibility of prioritization. The program's currency is trust — every false-priority escalation and every unactionable finding spends it. Spend it where the risk actually is.

## When to use

- Standing up or maturing a vuln-management program from ad-hoc scanning.
- Drowning in scanner findings and needing risk-based prioritization.
- Setting remediation SLAs and holding teams accountable without burning trust.
- Preparing for audits that ask for evidence of timely remediation.
- Responding to a critical CVE (Log4Shell-style) with a coordinated find-and-fix.

## Core concepts

- **You cannot scan what you cannot see:** asset inventory (including cloud, containers, SaaS, shadow IT) is step zero. Unscanned assets are unmeasured risk.
- **CVSS ≠ risk:** CVSS measures vulnerability severity in a vacuum. Real prioritization adds exploitability (is there a public exploit? CISA KEV?), asset criticality, and exposure (internet-facing?).
- **Risk-based prioritization:** a medium CVE with a public exploit on an internet-facing payment server beats a critical CVE with no exploit path on an isolated test box. Say this out loud, often.
- **SLAs by severity:** e.g., critical 7–15 days, high 30 days, medium 90 days. SLAs must be agreed with engineering, not imposed.
- **Exceptions with expiry:** accepted risks need an owner, a business justification, compensating controls, and an expiry date. Permanent exceptions are just ignored vulnerabilities.
- **Verify, don't trust:** closure requires re-scan or evidence of the fix, not a ticket marked "done."

- **Exposure windows.** Track time from CVE publication to remediation on internet-facing assets separately — that window is the attacker's opportunity and your key risk metric.
- **Compensating controls as first aid.** When patching is blocked, document the WAF rule, network isolation, or config change reducing exposure — with an expiry tied to the real fix.
- **Vulnerability intelligence sources.** Beyond scanners: vendor advisories, CISA KEV, and threat-intel feeds for your stack. Correlate, do not just aggregate.

## Practical workflow

1. **Inventory and coverage:** enumerate assets (hosts, cloud accounts, containers, apps, network gear). Map each to a scan source: agent-based, network scans, cloud posture, container registry, DAST/SAST for apps.
2. **Scan on cadence:** authenticated scans where possible (far richer results), plus continuous scanning for critical segments. Track scan coverage % as a KPI.
3. **Enrich and deduplicate:** merge findings across tools, attach asset context (owner, criticality, exposure), tag CISA KEV / exploited-in-the-wild items for fast-track.
4. **Prioritize:** sort by risk = severity × exploitability × exposure × asset criticality. Publish a weekly "top N that actually matter" list, not a 10,000-row CSV.
5. **Assign with SLAs:** route to asset owners with clear severity, evidence, remediation guidance, and due date. Provide the fix, not just the finding.
6. **Track and verify:** dashboard of SLA compliance, aging, and exceptions. Re-scan on closure. Escalate breaches of SLA through management, with data.
7. **Report trends:** mean time to remediate, % criticals within SLA, repeat offenders, coverage. Report risk reduction, not raw counts.

### Prioritization quick rubric

- **P0 / Emergency:** CISA KEV or actively exploited + internet-facing + critical asset → hours to days.
- **Critical:** CVSS 9+ on exposed critical asset → 7–15 days.
- **High:** exploitable path exists → 30 days.
- **Medium/Low:** defense-in-depth items → 90 days / next cycle.

### Sustaining the practice

- Publish the weekly risk-burn-down to engineering leadership — visibility drives action
- Review scanner coverage and credential health monthly
- Re-validate prioritization logic quarterly against actual exploitation trends
- Celebrate teams with strong remediation records; make security a team sport

### Metrics that prove it works

- SLA compliance % by severity band, trended monthly
- Mean time to remediate critical/high findings
- Scan coverage % of the asset inventory (authenticated coverage separately)
- Exception count and average exception age

## Common pitfalls

- **Scanning without authentication.** Unauthenticated scans miss most host findings. Authenticated scanning is worth the credential-management effort.
- **CVSS-only prioritization.** Teams fix easy 9.8s on test boxes while exploited 7.5s on prod burn. Add exploit intel and exposure.
- **No asset owners.** Findings with no owner rot. Every asset needs a named accountable owner.
- **SLAs nobody agreed to.** Imposed deadlines get ignored. Negotiate, publish, then enforce evenly.
- **Counting findings instead of risk.** "We closed 5,000 findings" means little if the top 20 risks are untouched. Report risk burned down.
- **Ignoring the exception graveyard.** Review exceptions quarterly; expired or unjustified ones go back into the queue.
- **Accepting unauthenticated scans as coverage.** They miss the majority of host findings. Authenticated scanning is worth the credential-management overhead.
- **Patch delays without formal risk acceptance.** "Waiting for the maintenance window" repeated for six months is an undocumented exception. Formalize it or fix it.
- **Scanning production aggressively without coordination.** Unthrottled scans can degrade fragile services. Schedule, throttle, and coordinate with service owners.
- **Counting scanner plugins instead of risk.** 'We run 100k checks' impresses nobody if the top risks age past SLA. Report risk reduced, not checks run.