Vulnerability Management Template

Overview

Unpatched vulnerabilities remain one of the most common root causes of breaches — not because teams don’t scan, but because findings pile up without owners, deadlines, or follow-through. This template gives you a repeatable workflow: every CVE gets tracked, scored, assigned to a single owner, and closed within an SLA before it can slip into “we’ll patch it later” territory.

Use it alongside the dependency vulnerability triage template for per-CVE analysis and the patch management template for scheduling the rollout itself. For findings that come out of a penetration test, the penetration test template keeps the traceability from assessment to resolution.

When to Use

• A new CVE is disclosed that affects your technology stack
• You run automated vulnerability scans (container, dependency, infrastructure)
• You’re preparing for a security audit or compliance review
• You need to report security posture to leadership or customers
• You want to define patching SLAs by severity

Solution

# Vulnerability Management Tracker

## 1. Vulnerability Inventory

| CVE ID | Component | Version | Severity | CVSS | Discovered | Source |
|--------|-----------|---------|----------|------|------------|--------|
| CVE-2026-XXXX | log4j-core | 2.14.1 | Critical | 9.8 | 2026-01-15 | Dependabot |
| CVE-2026-YYYY | openssl | 1.1.1n | High | 7.5 | 2026-02-03 | Trivy scan |
| CVE-2026-ZZZZ | nginx | 1.18.0 | Medium | 5.3 | 2026-02-10 | Nessus |

## 2. Risk Assessment

| CVE ID | Exploitability | KEV/EPSS | Affected Systems | Data at Risk | Business Impact | Risk Score |
|--------|----------------|----------|------------------|--------------|-----------------|------------|
| CVE-2026-XXXX | Public exploit available | In CISA KEV | API cluster, workers | PII, auth tokens | Service downtime, data breach | Critical |
| CVE-2026-YYYY | Proof of concept | EPSS 34% | Edge proxies | Config secrets | Lateral movement | High |

## 3. Remediation Plan

| CVE ID | Owner | Fix Strategy | Target Date | Status | Verification |
|--------|-------|--------------|-------------|--------|--------------|
| CVE-2026-XXXX | @security-team | Upgrade to 2.17.1 | 2026-01-17 | Complete | Rescan clean |
| CVE-2026-YYYY | @devops-team | Patch and redeploy | 2026-02-10 | In Progress | Awaiting deploy window |

### Fix Strategies

- **Upgrade:** Update to patched version (preferred)
- **Patch:** Apply vendor hotfix
- **WAF rule:** Block exploitation vector at edge
- **Config change:** Disable vulnerable feature
- **Compensating control:** Monitoring + alerting if patch not feasible

## 4. Patching SLA

| Severity | CVSS Range | SLA (days) | Escalation Path |
|----------|------------|------------|-----------------|
| Critical | 9.0 - 10.0 | 24 - 48 hours | CISO + Engineering VP |
| High | 7.0 - 8.9 | 7 days | Security Lead + Team Manager |
| Medium | 4.0 - 6.9 | 30 days | Engineering Manager |
| Low | 0.1 - 3.9 | 90 days | Tech Lead |

## 5. Exception Process

When a patch can't be applied within SLA:

| CVE ID | Exception Reason | Compensating Control | Approved By | Review Date |
|--------|------------------|----------------------|-------------|-------------|
| CVE-2026-ZZZZ | Legacy dependency, breaking change | WAF rule + anomaly monitoring | CISO | 2026-04-01 |

## 6. Program Metrics (Monthly)

| Metric | Value | Target | Trend |
|--------|-------|--------|-------|
| Open CVEs by severity | 12 C / 34 H / 89 M / 45 L | — | ↑ M |
| % CVEs resolved within SLA | 82% | ≥90% | ↑ |
| Mean time to remediate (Critical) | 1.8 days | <2 days | → |
| Overdue CVEs | 1 | 0 | ↓ |
| New vs closed this month | 31 new / 35 closed | close ≥ new | ↑ |

## 7. Weekly Security Report

### Executive Summary

- **New vulnerabilities this week:** 3
- **Resolved this week:** 2
- **Past SLA:** 1 (CVE-2026-YYYY — awaiting deploy window)
- **Risk trend:** Improving

### Action Items

1. [ ] Complete OpenSSL upgrade on edge proxies by Feb 10
2. [ ] Review legacy dependency replacement plan with architecture team
3. [ ] Enable automated Trivy scanning on all CI pipelines

Explanation

The template keeps inventory, risk assessment, remediation, and reporting as separate sections on purpose — teams that jump straight to patching tend to fix the wrong things first. The SLA table is the accountability layer: each severity gets a hard deadline and a named escalation path, so “critical sits open for a month” stops being possible.

Two scoring fields deserve attention beyond CVSS. If a CVE is in CISA’s Known Exploited Vulnerabilities catalog, treat it as critical regardless of its score — someone is already using it. EPSS gives you the probability of exploitation in the next 30 days, which beats raw severity for sequencing work when the backlog is large. In practice: an EPSS above ~0.5 means “likely to be exploited soon” and above ~0.1 deserves attention on internet-facing assets. KEV membership plus high EPSS plus a public service is your real priority queue; everything else schedules around it.

The exception process isn’t a loophole — it’s the documentation that keeps an unpatched system visible. A documented exception with compensating controls and a review date is always better than an undocumented unpatched vulnerability. It also doubles as audit evidence: SOC 2 and ISO 27001 reviewers ask for exactly this record — the risk acceptance, the compensating control, the approver, and the expiry.

From Triage to Remediation

Most CVEs don’t die in the scanner — they die in the handoff between the security team that triages and the engineering team that patches. The tracker only works if the ticket that crosses that boundary is complete: affected component and version, whether the service is internet-exposed, the fix strategy, and a target date tied to the SLA. Anything missing becomes a negotiation, and negotiations don’t patch systems.

Critical fixes shouldn’t wait for the next sprint, but they shouldn’t skip staging either — that’s how a rushed OpenSSL upgrade takes down the edge proxies it was meant to protect. The pattern that works: security owns the severity call and the deadline, engineering owns the fix and the deploy window, and the tracker is where both sides see the same clock.

Metrics That Drive the Program

The health of a vulnerability program shows up in two numbers: the percentage of CVEs resolved within SLA and the mean time to remediate criticals. If the SLA percentage drops below ~80%, you don’t have a scanning problem — you’ve got a throughput problem: either too much incoming volume for the team, or remediation work isn’t getting scheduled. The fix is process, not more scanning.

The overdue count is the number leadership should see every month. Zero is the target, and anything above it needs a named owner and an exception review — not a bullet point in a report nobody reads.

Report on three cadences. Weekly is operational: what opened, what closed, what’s past SLA. Monthly is programmatic: the metrics table — open by severity, SLA percentage, MTTR on criticals, overdue count, and the trend. Quarterly is governance: exception review and SLA recalibration against actual capacity. Same data, three audiences, three formats — the tracker feeds all of them.

Vulnerability Management Pipeline

Each stage has a defined exit criterion: discovery ends with the CVE in the tracker, assessment ends with a named owner, planning ends with a date and an SLA, remediation ends with a deploy, and verification ends with a clean rescan. Anything that fails verification goes back to planning with a fresh SLA — it doesn’t silently linger.

Variants

Context	Approach	Notes
Startup	Spreadsheet + manual scans	Focus on critical and high CVEs only
Mid-size	Jira + automated scanner integration	Track SLA compliance weekly
Enterprise	Vuln management platform (Rapid7, Tenable)	Full lifecycle with RBAC and audit trails
Container/K8s environment	Image scanning at build + runtime (Trivy, Falco)	Track image-to-CVE mapping per deployment

What Works

1. Scan early, scan often. Integrate dependency and container scanning into CI/CD so vulnerabilities are caught before deployment.
2. Prioritize by exploitability, not just CVSS. Check CISA KEV first; a medium CVE with a public exploit beats a high one that requires local access.
3. Assign a single owner per CVE. Shared ownership becomes no ownership.
4. Automate where possible. Dependabot, Snyk, and Trivy can auto-create tickets and PRs for patchable issues.
5. Tune out false positives deliberately. Distinguish reachable vulnerabilities from theoretical ones — a scanner that cries wolf gets ignored.
6. Report weekly to leadership. Visibility drives prioritization and resource allocation.

Common Mistakes

1. Relying solely on CVSS for prioritization. A CVSS 7.5 in an internal admin tool is less urgent than a CVSS 6.5 in a public-facing API.
2. Not tracking exceptions. “We’ll patch it later” without a date becomes “we forgot about it.”
3. Patching without testing. Emergency patches deployed straight to production cause outages worse than the vulnerability.
4. Ignoring transitive dependencies. The vulnerable library might be three levels deep in your dependency tree.
5. Failing to verify after patching. Always rescan to confirm the fix actually resolved the CVE.

See Also

• Companion repository: the fillable tracker and the filled example as standalone markdown files.
• CISA Known Exploited Vulnerabilities Catalog: the authoritative list of CVEs under active exploitation — check it before prioritizing.
• NIST National Vulnerability Database: canonical CVE data with CVSS scores and references.
• FIRST EPSS: Exploit Prediction Scoring System for estimating exploitation probability over the next 30 days.
• NIST SP 800-40r4: the reference guide for enterprise patch and vulnerability management processes.
• Security Audit Checklist Template: the periodic review counterpart to this day-to-day tracker.
• Complete Guide to Supply Chain Security: SBOMs and dependency scanning — where most of the CVEs you’ll triage originate.