graphgrc

Vulnerability Management Process

Process for identifying, triaging, and remediating security vulnerabilities.

Roles and Responsibilities

• Security Team: Coordinates scanning, triages findings, tracks remediation
• Engineering Team: Remediates application and dependency vulnerabilities
• Infrastructure Team: Remediates infrastructure and OS vulnerabilities

Prerequisites

• Vulnerability scanning tools configured (Dependabot, Snyk, AWS Inspector, etc.)
• SLA defined for each severity level (see vulnerability-management-standard.md)
• Vulnerability tracking system (Jira, GitHub Issues, etc.)

Process Steps

Step 1: Automated Scanning

Vulnerability scanners run automatically on schedule or per event.

Scanning types:

• Dependency scanning: On every PR (Dependabot, Snyk)
• Container scanning: On every image push (ECR scan, Trivy)
• Infrastructure scanning: Weekly (Prowler, AWS Inspector)
• Web application scanning: Quarterly (OWASP ZAP)
• External attack surface: Monthly (Shodan, Censys)

Owner: Automated systems Duration: Continuous

Step 2: Alert and Notification

Vulnerabilities detected trigger alerts to appropriate teams.

Notification routing:

• Critical/High: Slack #security-alerts + email to security team
• Medium: Daily digest to security team
• Low: Weekly report

Alert includes:

• CVE ID and description
• CVSS score and severity
• Affected system/component
• Remediation guidance (patch version, configuration change)

Owner: Automated systems Duration: Real-time or batched

Step 3: Triage and Prioritization

Security team reviews findings and prioritizes based on risk.

Triage criteria:

• CVSS score (Critical, High, Medium, Low)
• Exploitability (is exploit public? Is it being actively exploited?)
• Exposure (is system public-facing or internal?)
• Data sensitivity (does system handle Confidential/Restricted data?)
• Business criticality

Actions:

• Assign severity (may escalate from scanner severity based on context)
• Create remediation ticket
• Assign to owning team
• Set due date based on SLA

Owner: Security Team Duration: Within 48 hours of detection

Step 4: Risk Assessment (for exceptions)

If remediation is not feasible, team requests risk exception.

Exception scenarios:

• No patch available yet
• Patch breaks functionality (requires testing)
• Compensating controls in place (WAF rule, network isolation)
• False positive

Process:

• Team documents justification in ticket
• Security team reviews and approves/denies
• If approved: Document compensating controls, set re-review date

Owner: Owning team (request), Security team (approval) Duration: Within 5 business days

Step 5: Remediation

Owning team fixes vulnerability within SLA.

Remediation actions:

• Update dependency to patched version
• Apply OS/software patch
• Change configuration (disable vulnerable feature)
• Implement compensating control

Best practices:

• Test patch in staging before production
• Automated dependency updates via Dependabot/Renovate where possible
• Document changes in ticket

Owner: Engineering Team or Infrastructure Team Duration: Based on severity SLA (see vulnerability-management-standard.md)

Step 6: Verification

Security team verifies remediation is complete.

Verification methods:

• Re-run vulnerability scan
• Check software version/configuration
• Review audit logs for successful patch deployment

Actions:

• If fixed: Close ticket
• If not fixed or introduces new issues: Reopen ticket, work with team on alternative

Owner: Security Team Duration: Within 48 hours of remediation claim

Step 7: Metrics and Reporting

Security team tracks vulnerability management metrics.

Metrics:

• Mean Time to Remediate (MTTR) by severity
• Number of open vulnerabilities by severity
• SLA compliance rate
• Number of exceptions granted
• Vulnerabilities introduced vs. resolved (trend)

Reporting: Monthly report to leadership, quarterly deep dive

Owner: Security Team Duration: Monthly

SLA Tracking

Automated alerts for vulnerabilities approaching SLA deadline:

• 50% of SLA time elapsed: Warning notification
• 75% of SLA time elapsed: Escalate to team lead
• 100% of SLA time elapsed: Escalate to engineering manager

Exception Reviews

All risk exceptions reviewed quarterly:

• Has patch become available?
• Are compensating controls still in place?
• Should exception be extended or vulnerability fixed?

Validation and Evidence

• Vulnerability scan reports
• Remediation tickets with timestamps
• Risk exception approvals
• Re-scan verification results
• MTTR metrics dashboard

References

• Related controls: OPS-02, END-03
• Related standards: vulnerability-management-standard.md
• CVSS Calculator: https://www.first.org/cvss/calculator/3.1

Control Mapping

• OPS-02: Vulnerability Management ^[7-step process: scanning, alerting, triage, risk assessment, remediation, verification, metrics]
• END-03: Software Updates ^[Dependency updates via Dependabot/Renovate, OS patching with SSM Patch Manager]

---

Referenced By

This section is automatically generated by make generate-backlinks. Do not edit manually.

This site is open source. Improve this page.