CVE Triage & Remediation SLA¶
Asset: I7 (process half). The companion live view is the vuln-triage Grafana dashboard (
snowops-vuln-triage.json). This runbook governs how a CVE or security finding from any SnowOps scanner is triaged, assigned an SLA, tracked, and closed (or waived).
Inputs — where findings come from¶
| Source | Asset | Finding type |
|---|---|---|
| Container image scan | I1 | OS + library CVEs in images |
| Dependency scan | I2 | Vulnerable app dependencies |
| SAST | I3 | Code-level weaknesses |
| DAST | I4 | Runtime web-app vulnerabilities |
| Defender for Cloud | I5 | Cloud + VM vulnerability assessments |
| Patch compliance | I6 | Missing OS security/critical updates |
All roll up to one triage queue. Defender findings are the canonical SLA-tracked set on the dashboard (they carry severity + a first-seen timestamp).
Step 1 — Triage to a severity¶
Use the source's severity if present (Defender/Trivy/CodeQL all emit one). Otherwise score with CVSS v3.1 base and band: Critical ≥ 9.0 · High 7.0–8.9 · Medium 4.0–6.9 · Low < 4.0. Escalate one band when all hold: known exploited (CISA KEV), internet-exposed, and no compensating control.
Step 2 — Assign the remediation SLA¶
The clock starts at first detection (the dashboard's FirstSeen).
| Severity | Remediation SLA | Dashboard SLA band |
|---|---|---|
| Critical | 7 days | SlaDays default for Critical/High |
| High | 30 days | High → 30d (after Critical fast-track) |
| Medium | 90 days | Medium → 90d |
| Low | Best effort (next maintenance window) | not SLA-tracked |
The dashboard's panel 4 query encodes the same bands; keep them in sync if the SLA policy changes.
Step 3 — Assign an owner & open a tracking ticket¶
Route to the owning team (workload owner for infra/patch findings; the app team for dependency/SAST/DAST). Open/Update a tracking ticket via E7 (I5 already does this automatically for Defender findings) so remediation work is visible and deduplicated. Tag with severity + the SLA due date.
Step 4 — Remediate, waive, or accept¶
- Remediate before the SLA: patch (I6), bump the dependency (I2), fix the code (I3), or reconfigure (Defender recommendation). Confirm the finding flips to Healthy / disappears from the dashboard.
- Waive when remediation can't land in SLA: file a time-boxed, approved
exception in
waivers/(D5) with justification + a review/expiry date. The D5 CI gate enforces expiry; a waived finding is excluded from SLA-breach counts but stays visible. - Accept (Low / false positive): mark in the source tool and note the rationale on the ticket.
Step 5 — Verify SLA on the dashboard¶
On the vuln-triage dashboard: panel 1 (open by severity) should trend down; panel 3 (oldest open recommendations) and panel 4 (SLA-breaching findings) should show zero items past their band. Any breach is an on-call/secops escalation — re-triage and either expedite or waive with sign-off.
Cadence¶
- Continuous: I5 tickets Defender findings as they appear.
- Weekly: secops reviews the dashboard — new Criticals, anything approaching SLA, breaches.
- Monthly: patch-compliance (I6) report + dependency digest (I2) reviewed for trends; stale waivers re-justified or closed.