dag: Security Vulnerability Triage
version: 1.0.0
image: https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1200&q=80
description: Not every CVE is an emergency, and treating them all as one burns out security teams while real risks go unaddressed. This tree applies a consistent, risk-based triage framework — CVSS score, exploit availability, data exposure, and attack surface — to assign each vulnerability to the right response timeline so effort is proportional to actual risk.
tags: security, vulnerability management, devops, compliance, sre
entry: Q1

Q1: What is the CVSS v3 base score for this vulnerability?
  hint: Find the score in your scanner output (Snyk, Dependabot, Trivy, Qualys), the NVD entry at nvd.nist.gov, or the vendor's security advisory. Use the base score, not the environmental or temporal score. If the vulnerability has no published CVSS score, treat it as High until more information is available.
  A: Critical — 9.0 or above -> [EMERGENCY]
  B: High — 7.0 to 8.9 -> Q2
  C: Medium — 4.0 to 6.9 -> Q3
  D: Low — below 4.0 -> [ACCEPT-LOW]

Q2: Is there a known public exploit for this vulnerability, or is it listed in the CISA Known Exploited Vulnerabilities catalogue?
  hint: Check the NVD entry for exploitability notes, search the CISA KEV catalogue at cisa.gov/known-exploited-vulnerabilities-catalog, and check vendor security advisories for "actively exploited" flags. A high CVSS score with a public proof-of-concept exploit in the wild is effectively Critical regardless of the base score.
  yes -> [EMERGENCY]
  no  -> Q4

Q3: Could exploitation of this vulnerability result in sensitive data exposure, privilege escalation, remote code execution, or denial of service affecting production?
  hint: Assess the worst-case impact in your specific environment. A SQL injection in a read-only reporting database is less severe than one in a user-facing API. A path traversal in an internal admin tool is less severe than one in a publicly accessible service. Consider your actual data classification and who can trigger the vulnerability.
  yes -> Q4
  no  -> [ACCEPT-LOW]

Q4: Is the affected component internet-facing or reachable by unauthenticated users?
  hint: Attack surface dramatically changes risk. A vulnerability in a library used only by an internal backend service behind authentication is significantly harder to exploit than the same vulnerability in a public-facing API endpoint or a dependency of your login flow. Consider network path, authentication requirements, and whether an attacker would need prior access to trigger the issue.
  yes -> [EXPEDITED]
  no  -> [SCHEDULED]

[EMERGENCY]: Emergency Patch — Act Within 24 Hours
  color: #C0392B
  description: This vulnerability requires immediate action — escalate to the on-call engineering lead and security team now. A Critical CVSS score, an active exploit in the wild, or both indicate that the time between disclosure and active exploitation is measured in hours to days, not weeks. Immediate steps: (1) Assess whether the vulnerability is currently being exploited against your systems by checking WAF logs, anomaly detection alerts, and IDS signatures; (2) Implement a temporary mitigation — WAF rule, network ACL, feature flag to disable the vulnerable endpoint, or rate limiting — to reduce exposure while the patch is prepared; (3) Apply the vendor patch or upgrade to a fixed version in a staging environment and fast-track through to production, bypassing the normal change management window if necessary; (4) If no patch exists, evaluate whether the component can be isolated, disabled, or replaced. Document the incident timeline and your response actions from the moment of discovery.
  code: VULN_EMERGENCY

[EXPEDITED]: Expedited Patch — Remediate Within 7 Days
  color: #E67E22
  description: This vulnerability is high severity with a meaningful attack surface — it requires faster remediation than the normal sprint cycle but does not warrant a drop-everything emergency response. Target remediation within 7 days, meaning the fix must be in production (not just merged) by that deadline. Steps: (1) Assign ownership to a specific engineer today — unowned vulnerabilities drift; (2) Identify the fix: upgrade the affected package, apply the vendor patch, or implement a compensating control; (3) Schedule deployment to production within 3–5 business days, coordinating with your change management process if one exists; (4) If the patch introduces breaking changes or requires significant testing, consider a temporary compensating control (WAF rule, feature flag, access restriction) to reduce exposure while the full fix is prepared; (5) Verify the fix in production using your scanner and confirm the CVE no longer appears in your next scheduled scan. Report closure to your security register.
  code: VULN_EXPEDITED

[SCHEDULED]: Scheduled Patch — Next Sprint or Maintenance Window
  color: #F1C40F
  description: This vulnerability is real but does not require disrupting current work — it belongs in your normal vulnerability management backlog and should be addressed in the next sprint cycle or scheduled maintenance window, typically within 2–4 weeks. Create a tracked ticket with the CVE identifier, affected component, recommended fix version, and severity classification. Include it in sprint planning as a non-negotiable item rather than a "nice to have" — vulnerabilities scheduled for "next sprint" have a tendency to drift indefinitely without explicit prioritisation. At the time of remediation, verify the fix resolves the specific CVE using your scanner (not just that the package version was bumped), and update your vulnerability register with the remediation date. If the vulnerability remains unresolved after two sprint cycles, re-triage it — the risk environment may have changed.
  code: VULN_SCHEDULED

[ACCEPT-LOW]: Accept or Defer — Low Priority
  color: #27AE60
  description: This vulnerability carries low inherent risk given its CVSS score and your specific environment. It can be acknowledged and deferred without immediate action, provided you record the decision. Steps: (1) Log the vulnerability in your security register with the acceptance rationale — low CVSS score, not exploitable in your environment, or compensating controls already in place; (2) Set a review date (typically 90 days or your next scheduled vulnerability review cycle) to re-evaluate if the threat landscape changes — a new public exploit or changed attack surface can elevate a low-severity finding overnight; (3) Consider batching low-severity vulnerabilities into a dedicated dependency hygiene sprint every 4–6 weeks, where you address them in bulk rather than one by one. Vulnerability acceptance is a legitimate risk management decision, not a deferral of responsibility — document who accepted it, why, and when it will be re-assessed.
  code: VULN_ACCEPT_LOW