Decision Tree: I Found a Vulnerability¶
Category: Security Response Starting Question: "I found a security vulnerability — what do I do?" Estimated traversal: 2-5 minutes Domains: security, compliance, incident-response, devops
The Tree¶
I found a security vulnerability — what do I do?
│
├── Is this in our own code/system, or a third-party dependency?
│ │
│ ├── Third-party dependency → see dependency-cve.md for triage
│ │ └── (Return here after triage if exploit is actively used against us)
│ │
│ └── Our own code/system — continue below
│ │
│ ├── Is it currently exploitable?
│ │ (Attack vector is accessible — network-reachable, no auth bypass needed,
│ │ or unauthenticated endpoint directly exposed)
│ │ │
│ │ ├── YES — exploitable
│ │ │ │
│ │ │ ├── Is there evidence of active exploitation?
│ │ │ │ Check: SIEM alerts, WAF logs, anomalous traffic, unusual process
│ │ │ │ `grep -i "exploit\|attack\|injection\|traversal" /var/log/nginx/access.log | tail -200`
│ │ │ │ `kubectl logs -l app=<svc> --tail=500 | grep -E "4[0-9]{2}|error|exception"`
│ │ │ │ │
│ │ │ │ ├── YES — actively being exploited
│ │ │ │ │ └── ✅ ACTION: Emergency Patch + Declare Incident
│ │ │ │ │ (Do not wait for CVSS — contain first, score later)
│ │ │ │ │
│ │ │ │ └── NO — no exploitation evidence yet
│ │ │ │ │
│ │ │ │ ├── What is the CVSS score?
│ │ │ │ │ │
│ │ │ │ │ ├── Critical (≥ 9.0)
│ │ │ │ │ │ └── ✅ ACTION: Emergency Patch within 4h
│ │ │ │ │ │ Notify security team immediately
│ │ │ │ │ │
│ │ │ │ │ ├── High (7.0–8.9)
│ │ │ │ │ │ └── ✅ ACTION: Patch within 24h
│ │ │ │ │ │ Schedule emergency window tonight
│ │ │ │ │ │
│ │ │ │ │ └── Medium (4.0–6.9)
│ │ │ │ │ └── ✅ ACTION: Patch within 7 days
│ │ │ │ │ Create tracked ticket now
│ │ │ │ │
│ │ │ │ └── What is the blast radius?
│ │ │ │ │
│ │ │ │ ├── Public-facing endpoint or PII exposure possible
│ │ │ │ │ └── ⚠️ ESCALATION: Notify security team + legal NOW
│ │ │ │ │ Regulatory notification may be required
│ │ │ │ │
│ │ │ │ └── Internal-only, no PII
│ │ │ │ └── Proceed with scheduled patch timeline above
│ │ │ │
│ │ │ └── Is a patch available?
│ │ │ │
│ │ │ ├── YES — apply immediately (see patch actions below)
│ │ │ │
│ │ │ └── NO — no patch yet
│ │ │ │
│ │ │ ├── Apply mitigating controls NOW
│ │ │ │ (WAF rule, network ACL, feature flag disable, auth layer)
│ │ │ │
│ │ │ └── ✅ ACTION: Track + Monitor until patch available
│ │ │ Set alert on exploitation indicators
│ │ │
│ │ └── NO — not currently exploitable
│ │ (Requires physical access, internal privilege, non-production only,
│ │ or behind multiple auth layers)
│ │ │
│ │ ├── CVSS score?
│ │ │ │
│ │ │ ├── Critical (≥ 9.0) or High (7.0–8.9)
│ │ │ │ └── ✅ ACTION: Patch within 7 days
│ │ │ │ Even unexploitable criticals need fast remediation
│ │ │ │
│ │ │ ├── Medium (4.0–6.9)
│ │ │ │ └── ✅ ACTION: Add to security backlog — 30-day SLA
│ │ │ │
│ │ │ └── Low (< 4.0)
│ │ │ └── ✅ ACTION: Track in security backlog — best-effort
│ │ │
│ │ └── Is a CVE already published (public knowledge)?
│ │ │
│ │ ├── YES — CVE assigned, public
│ │ │ └── Attackers know — re-evaluate exploitability rating above
│ │ │ A "not exploitable" assessment may change if exploit PoC drops
│ │ │
│ │ └── NO — not yet public
│ │ └── ✅ ACTION: Responsible Disclosure
│ │ Notify affected vendor before publishing
│
└── Cross-cutting: Does this trigger regulatory notification?
(GDPR, HIPAA, PCI-DSS, SOC 2 obligations — applies regardless of branch above)
│
├── PII, PHI, or cardholder data potentially exposed
│ └── ⚠️ ESCALATION: Security + Legal within 1 hour
│ Notification windows are short (72h for GDPR)
│
└── No regulated data involved
└── No mandatory notification — document decision + rationale
Node Details¶
Check 1: Is it exploitable?¶
Command/method: Map the attack path manually: what is the entry point? Is it network-reachable? Does it require authentication? Is the vulnerable component exposed via a public endpoint?
# Check what's publicly exposed
kubectl get ingress --all-namespaces
kubectl get svc --all-namespaces | grep LoadBalancer
# Check auth on the endpoint
curl -s -o /dev/null -w "%{http_code}" https://<endpoint>/vulnerable-path
Check 2: Evidence of active exploitation¶
Command/method:
# Check WAF/nginx for suspicious patterns
grep -E "union.*select|<script>|\.\.\/|%2e%2e|cmd=|exec\(" /var/log/nginx/access.log | tail -100
# Check for anomalous response sizes (data exfiltration)
awk '{print $10}' /var/log/nginx/access.log | sort -n | tail -20
# Check SIEM/Datadog/Splunk for the specific vulnerability pattern
# Application logs
kubectl logs deploy/<app> --tail=1000 | grep -iE "exception|unauthorized|forbidden|error"
Check 3: CVSS score¶
Command/method: If no CVE exists yet, score it manually at https://www.first.org/cvss/calculator/3.1. Key vectors: Attack Vector (Network=worst), Attack Complexity, Privileges Required, User Interaction, Confidentiality/Integrity/Availability Impact. What you're looking for: A score that drives the SLA: Critical ≥ 9.0 (4h response), High 7.0–8.9 (24h), Medium 4.0–6.9 (7 days), Low < 4.0 (backlog). Common pitfall: The base CVSS score assumes a worst-case deployment. Your temporal and environmental score can legitimately lower it — but document the reasoning. "We scored it lower" without documentation looks like downplaying.
Check 4: Blast radius¶
Command/method:
# What data does this service access?
kubectl get secrets -n <namespace> | grep -E "db|rds|postgres|mysql|redis"
# What does this service talk to?
kubectl get networkpolicy -n <namespace> -o yaml
# Check if PII flows through this service (look at data models / API contracts)
grep -r "email\|ssn\|dob\|password\|phone\|address" app/ --include="*.py" -l
Check 5: Regulatory notification triggers¶
Command/method: This is a legal/compliance check, not a technical one. Ask: Does the vulnerability expose (or could have exposed) personal data of EU residents (GDPR), US healthcare data (HIPAA), or payment card data (PCI-DSS)? What you're looking for: Any breach of confidentiality of regulated data, even if it hasn't been accessed yet. GDPR Article 33 requires notification within 72 hours of "becoming aware." Common pitfall: "We patched it, so no notification needed." Wrong — under GDPR, the obligation triggers on awareness of the potential breach, not on confirmed exfiltration. Consult legal.
Terminal Actions¶
✅ Action: Emergency Patch + Declare Incident¶
Do:
1. Declare incident in PagerDuty / incident.io — assign incident commander
2. Immediately apply mitigating control while patch is prepared: WAF rule, network ACL, or disable the feature (kubectl set env deployment/<name> FEATURE_FLAG_VULN=false)
3. Prepare and test the patch in staging: helm upgrade --install <release> . -f values-staging.yaml
4. Deploy to production with fast-track approval: helm upgrade <release> . -f values-prod.yaml --timeout=300s
5. Verify deployment: kubectl rollout status deployment/<name>
6. Confirm the vulnerability is no longer exploitable (re-run the test case that found it)
Verify: Repeat the exploit attempt — confirm it fails. Check error rate returns to baseline. Review access logs for 30 min post-patch for residual exploitation attempts.
✅ Action: Patch within 24h¶
Do:
1. Create P1 security ticket with full details (vulnerability description, affected component, CVSS, patch plan)
2. Notify security team lead via direct message (not just ticket)
3. Schedule emergency maintenance window (off-peak hours, tonight if possible)
4. Prepare patch branch, run full test suite: make test-all
5. Deploy during window with rollback plan documented
Verify: Deployment succeeds, tests pass, vulnerability confirmed closed. Update ticket with post-patch confirmation.
✅ Action: Patch within 7 Days¶
Do: 1. Create tracked security ticket with severity label and SLA due date 2. Assign to owning team — do not leave unassigned 3. Add to next sprint planning if within window 4. Daily check-in on ticket until patch is deployed Verify: Ticket moves to Done within 7 calendar days. Security team confirms closure.
✅ Action: Responsible Disclosure to Vendor¶
Do: 1. Document the vulnerability in full (steps to reproduce, affected versions, impact assessment) 2. Find vendor's security disclosure contact (security.txt, HackerOne, bug bounty program, or security@vendor.com) 3. Send encrypted disclosure email — include: description, CVSS assessment, proof-of-concept steps, your proposed disclosure timeline (typically 90 days) 4. Log disclosure date and expected response window 5. Do NOT publish or discuss publicly until vendor confirms patch is available or timeline expires Verify: Vendor acknowledges receipt within 5 business days. If no response, escalate via secondary contact or disclosure coordinator (CERT/CC).
✅ Action: Track in Security Backlog¶
Do:
1. Create ticket with label security and low-severity
2. Include: component, vulnerability description, CVSS score, why it's low risk, mitigation in place
3. Review during quarterly security review cadence
Verify: Ticket exists, is labeled, and has an assignee or team owner. Don't let it sit unowned.
⚠️ Escalation: Security Team + Legal (Regulatory Trigger)¶
When: Any possibility of regulated data (PII, PHI, PAN) exposure, regardless of CVSS score or exploitability. Who: CISO or security team lead (immediate), Legal/Compliance team (within 1 hour), DPO if GDPR-applicable Include in page: Affected service, data types potentially exposed, time window of exposure, whether the vulnerability is now closed, and current evidence of exploitation (none / suspected / confirmed)
Edge Cases¶
- You found it in a pentest report from 6 months ago that was never actioned: Treat it as newly found — start the SLA clock now. Document that it was previously identified but missed; this is a process failure worth a retrospective.
- The patch breaks functionality and cannot be deployed immediately: Apply the strongest available mitigating control (WAF rule, IP allowlist, feature disable). Document the control as a temporary measure and set a hard deadline for the real fix.
- You found it in a service owned by another team: File the ticket in their backlog AND notify their security champion directly. You are responsible for the handoff, they are responsible for the fix. Follow up.
- The vulnerability is in a decommissioned service that is still running: Treat as active. "Decommissioned" services that still receive traffic are still attack surface.
- CVSS score is disputed between teams: Use the higher score until there is documented evidence supporting a lower environmental score. Optimism is a risk.
Cross-References¶
- Topic Packs: security, incident-response
- Related trees: secret-exposed.md, suspicious-activity.md, dependency-cve.md
- Runbooks: incident_response.md