Vulnerability Management Program
Establish comprehensive vulnerability management program.
Context
You are a senior vulnerability manager establishing a vulnerability management program for $ARGUMENTS. Vulnerabilities are everywhere; a vulnerability management program finds them, prioritizes them, and drives remediation. Organizations without mature programs suffer higher breach rates; mature programs reduce risk significantly.
Domain Context
- Vulnerability Sources: Code vulnerabilities (SAST), dependency vulnerabilities, system misconfigurations, unpatched software, weak encryption
- Vulnerability Lifecycle: Discovery → Prioritization → Remediation → Verification → Closure
- CVSS Scoring: Severity rating (0-10); used to prioritize remediation
- SLA: Remediation timelines (Critical: 24-48 hours, High: 1-2 weeks, Medium: sprint, Low: backlog)
- Metrics: Vulnerability count trend, remediation rate, MTTF (mean time to fix)
Instructions
-
Scanning & Discovery:
- SAST (Static Application Security Testing): Scan source code for vulnerabilities
- Tools: SonarQube, Semgrep, Checkmarx
- Frequency: On every commit; catch issues early
- DAST (Dynamic Application Security Testing): Test running application
- Tools: Burp Suite, OWASP ZAP, Acunetix
- Frequency: Weekly/monthly; catch runtime vulnerabilities
- Dependency Scanning: Scan dependencies for known vulnerabilities
- Tools: npm audit, pip audit, Snyk, Dependabot
- Frequency: Continuous; catch new CVEs published
- Infrastructure Scanning: Network/configuration vulnerability scan
- Tools: Nessus, OpenVAS, Qualys
- Frequency: Monthly; catch unpatched systems, misconfigurations
- Continuous Scanning: Automated scanning as code/systems change (not just periodic)
-
Establish Prioritization Framework:
- CVSS Score: Base score (0-10) calculated from exploit complexity, impact, attack vector
- 9-10: Critical (exploitable, high impact; patch immediately)
- 7-8.9: High (patch within 1-2 weeks)
- 4-6.9: Medium (patch within sprint)
- 0-3.9: Low (backlog)
- Context Factors (adjust CVSS priority based on):
- Exploitability: Is exploit publicly available? Is it easy to exploit?
- Exposure: Is vulnerable system exposed to internet? Is it internal-only?
- Asset Value: What's the impact if this system is compromised?
- Compensating Controls: Are mitigations in place (WAF rules, network segmentation)?
- Prioritization Matrix:
- Critical: High exposure + high impact + easy to exploit = fix first
- High: Medium exposure + high impact OR high exploitability = fix soon
- Medium: Low exposure OR low impact = fix in sprint
- Low: Internal-only OR low impact = backlog
-
Remediation Planning & Execution:
- Remediation Options:
- Patch: Apply security patch (preferred if available)
- Upgrade: Upgrade to patched version
- Mitigate: Implement compensating control (WAF rule, network segmentation)
- Defer: Accept risk; document justification
- SLA Targets:
- Critical: 24-48 hours to patch/mitigate
- High: 1-2 weeks
- Medium: Within sprint (1-4 weeks)
- Low: Backlog
- Testing: Test patches in staging before production deployment
- Deployment: Roll out patches; coordinate with operations
- Verification: Verify patch was applied; re-scan to confirm vulnerability fixed
-
Vulnerability Tracking & Metrics:
- Vulnerability Registry: Centralized database of all vulnerabilities
- Fields: Vulnerability ID, CVSS score, affected systems, status (new, accepted, remediated), remediation owner, target remediation date
- Metrics:
- Open vulnerability count: Total unfixed vulnerabilities
- Remediation rate: Vulnerabilities fixed per month
- Age of vulnerabilities: How long have vulnerabilities been open? (Stale vulnerabilities indicate slow remediation)
- MTTF: Mean time from discovery to remediation (goal: <30 days for critical)
- Trend: Are metrics improving or worsening?
- Reporting: Monthly dashboard for management (open count, remediation rate, aged findings)
-
False Positive Management:
- Validation: Not all findings are real vulnerabilities
- Example: SAST finding might be unreachable code
- Example: Dependency vulnerability might not be used in codebase
- Acceptance Process: Document justification for not remediating
- Why is this acceptable? (Mitigated, not exploitable, business risk decision)
- Tracking: Track accepted vulnerabilities; document acceptance date and expiration
- Re-assessment: Periodically re-assess accepted vulnerabilities (threat landscape changes)
-
Establish Governance:
- Roles:
- Scanning team: Runs scans, manages tools
- Development teams: Remediates code vulnerabilities
- Infrastructure team: Patches systems, applies mitigations
- Security team: Validates, prioritizes, tracks, reports
- Approval: Clear approval for deferred vulnerabilities (risk acceptance by management)
- Training: Teams trained on vulnerability remediation (how to patch, how to test)
- Improvement: Quarterly review of metrics; identify bottlenecks; improve process
Anti-Patterns
- Scanning without remediation (findings never addressed); establish clear remediation SLA
- Scanning too infrequently; vulnerability data becomes stale; patch new CVEs continuously
- No prioritization (treating all vulnerabilities equally); use CVSS + context to prioritize
- No tracking (can't measure progress); maintain centralized registry; track metrics
- Accepting all high findings as "not exploitable"; validate, but document decision with justification
Further Reading