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

• For alternatives, see CI/CD Security: Harden Your Pipelines and Prevent Supply.

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.

Vulnerability Management Pipeline

=== CVE Lifecycle Flow ===

1. DISCOVERY
   - Automated scanner detects CVE in dependency or container
   - Manual scan or researcher report identifies vulnerability
   - CVE imported into vulnerability tracker automatically

2. ASSESSMENT
   - Security team validates the CVE (reproduce if possible)
   - Severity assigned: Critical / High / Medium / Low
   - Exploitability evaluated: is there a public exploit? a PoC?
   - Business impact evaluated: what data? what services?
   - Owner assigned: responsible team or engineer

3. PLANNING
   - SLA assigned based on severity (see SLA table)
   - Exception documented if no patch is available
   - Compensating controls identified if patching is not immediate
   - Priority adjusted based on business context

4. REMEDIATION
   - Patch applied in a feature branch
   - Tests run to verify the patch does not break functionality
   - Patch deployed to staging for validation
   - Patch deployed to production

5. VERIFICATION
   - Rescan confirms the CVE is resolved
   - Evidence captured: scanner output, deploy logs
   - CVE closed only after successful verification
   - If verification fails, CVE reopens with new SLA

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

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. 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.

Troubleshooting

• Authentication bypass in tests: ensure test users cannot reach production endpoints.
• False positives in scanning tools: tune rules against the risk profile. Distinguish between reachable vulnerabilities and theoretical issues.
• Secrets appear in logs: configure log filters to redact tokens, passwords, and keys. Audit log sinks for sensitive patterns.
• CSP breaks legitimate functionality: use report-only mode first, then enforce. Iterate on allowed sources based on real violations.
• Incident response stalls: run tabletop exercises.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply vulnerability management template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.