Vulnerability Management Template

Overview

Unpatched vulnerabilities are one of the most common root causes of security breaches. A structured vulnerability management process ensures that every CVE is tracked, prioritized, assigned, and resolved within a defined timeline. This template provides a repeatable workflow for security teams, DevOps engineers, and engineering managers to manage vulnerabilities across applications and infrastructure.

When to Use

Use this resource when:

• A new CVE is disclosed that affects your technology stack
• Running automated vulnerability scans (container, dependency, infrastructure)
• Preparing for a security audit or compliance review
• Reporting security posture to leadership or customers
• Defining SLAs for patching based on severity

Solution

# Vulnerability Management Tracker

## 1. Vulnerability Inventory

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

## 2. Risk Assessment

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

## 3. Remediation Plan

| CVE ID | Owner | Fix Strategy | Target Date | Status | Verification |
|--------|-------|--------------|-------------|--------|--------------|
| CVE-2024-XXXX | @security-team | Upgrade to 2.17.1 | 2024-01-17 | Complete | Rescan clean |
| CVE-2024-YYYY | @devops-team | Patch and redeploy | 2024-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 cannot be applied within SLA:

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

## 6. Weekly Security Report

### Executive Summary
- **New vulnerabilities this week:** 3
- **Resolved this week:** 2
- **Past SLA:** 1 (CVE-2024-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 separates inventory, risk assessment, remediation, and reporting into distinct sections. This prevents teams from jumping straight to patching without understanding which systems are affected and what data is at risk. The SLA table creates accountability by defining exactly how long each severity level can remain open before escalation.

The exception process is critical for legacy systems where patches are not immediately feasible. A documented exception with compensating controls is always preferable to an undocumented unpatched vulnerability.

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

Best Practices

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. A medium CVE with a public exploit is more urgent than a high CVSS that requires local access.
3. Assign a single owner per CVE. Shared ownership becomes no ownership.
4. Automate where possible. Use tools like Dependabot, Snyk, or Trivy to auto-create tickets and PRs for patchable issues.
5. 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 will patch it later” without a date becomes “we forgot about it.”
3. Patching without testing. Emergency patches deployed directly to production can 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 resolved the CVE.

Frequently Asked Questions

How do I handle a CVE with no available patch?

Document the exception, implement compensating controls (WAF rules, access restrictions, monitoring), and subscribe to vendor security advisories for the patch release date. Reassess risk weekly.

Should I patch low-severity vulnerabilities?

Yes, within the defined SLA. Attackers often chain low-severity vulnerabilities together to achieve a high-impact exploit. Low-severity items are also a signal of maintenance hygiene.

What tools integrate well with this template?

• Scanners: Trivy, Snyk, Nessus, Qualys, OWASP DC
• Ticketing: Jira, GitHub Issues, Linear
• Reporting: Grafana, Tableau, Google Sheets
• SOAR: Splunk SOAR, Palo Alto XSOAR for automated response

How do I communicate patching timelines to non-technical stakeholders?

Translate severity into business risk: “This critical vulnerability could allow unauthorized access to customer data within 48 hours if exploited. We are patching within 24 hours.” Use the risk assessment table to justify timelines.