Walk through responding to a critical finding reported by Semgrep in production.
Quick Answer
Confirm the finding is real and reachable, assess blast radius, contain (rotate, patch, isolate or roll back), then fix forward and add a pipeline check so the same class of issue cannot reach production again.
Detailed Answer
Start with verification: a Critical rating is a claim, not a fact. Confirm the affected version or resource is actually deployed and that the vulnerable path is reachable from untrusted input.
Then contain according to the finding class. A leaked credential is rotated first and only then removed from history — deleting the commit does nothing if the key is already public. A vulnerable dependency is patched or the affected feature disabled. A compromised host is isolated for forensics before termination, since terminating destroys the evidence. A misconfigured policy is corrected and audited for other resources sharing it.
Close the loop in the pipeline. The point of DevSecOps is that the same class of issue should be caught earlier next time: add or tighten the rule, lower the threshold, or add a policy at admission. For Semgrep, that usually means blocking a merge when a rule matches on changed lines.
Finish with the blameless review — how long the exposure lasted, why the existing gates missed it, and what detection you added.
Code Example
# Incident flow for a Critical Semgrep finding # verify: is the affected version actually deployed and reachable? # contain: rotate credentials / patch / isolate host / roll back release # NOTE: rotate a leaked key BEFORE rewriting git history # NOTE: isolate a suspect host BEFORE terminating it (preserve evidence) # fix: patch forward, redeploy, confirm the finding clears # prevent: tighten the gate so this class is caught pre-production
Interview Tip
Order matters: rotate before rewriting history, isolate before terminating. Getting the order right shows you have done this.