Draft Secure-Fix Remediation Guidance Developers Will Actually Merge

Producing that fix is a writing problem as much as a security one, and it is where AI helps most cheaply: given the vulnerability and the code, it drafts a minimal patch, explains the exploit in the developer's own stack, and produces PR-ready wording. Because remediation guidance is lower-risk than a triage decision — a bad patch fails a test rather than silently shipping a hole — this is a Foundation-tier task. The discipline is still real: you verify the fix closes the vuln and introduces nothing new before it goes out under your name.

When to reach for this

• •
  You've confirmed a real vulnerability (from review, a scanner, or a pen test) and need to write it up for the owning team.
• •
  The fix is non-obvious to a developer who isn't a security specialist and needs the why, not just the what.
• •
  You're drafting many remediation tickets and want consistent, actionable wording instead of terse one-liners nobody acts on.

The workflow

1. 1.

   Assemble the confirmed finding. You need the vulnerable code, the exploit path you already verified, and the CWE/class. Do not draft remediation for an unconfirmed finding — fix the triage first.

2. 2.

   Prompt for a minimal fix plus developer-facing explanation:

   Copy

   You are writing remediation guidance for a confirmed vulnerability in
   code I own. Produce:
   1. A one-paragraph explanation of the exploit a developer can follow,
      including how an attacker triggers it.
   2. The MINIMAL code change that fixes it — smallest possible diff, no
      refactoring, no added abstractions.
   3. Why this fix works (what property it restores).
   4. What to watch for so the fix doesn't introduce a new bug.
   
   Keep it concrete and specific to this stack. Do not rewrite the whole
   file.
   
   VULNERABILITY: SQL injection (CWE-89) at services/report.py:42
   EXPLOIT PATH: `month` query param flows unsanitized into the query string
   CODE:
   <paste the function>
   

   Expected output: a reproducible exploit description, a tight diff (e.g., switching to a parameterized query), a plain statement of why parameterization breaks the injection, and a caveat (e.g., "confirm no other caller relies on the old string-concatenation behavior").

3. 3.

   Demand the diff be minimal. If the model returns a large rewrite, push back: "give me the smallest change that fixes only this, changing nothing else." Small diffs get reviewed and merged; large ones get parked.

4. 4.

   Draft the PR/ticket wording. Ask for a title, a body with the exploit-then-fix structure, and a testing note pointing at the regression test (see the regression-test playbook). This is the artifact the developer receives.

5. 5.

   Attach the proof. Include the failing-then-passing test or the before/after scanner result so the reviewer doesn't have to take the fix on faith.

Verify before you trust it

• Prove the fix closes the vulnerability. Run the exploit against the patched code — it should now fail. Re-run the SAST rule that flagged it; the finding should clear. A fix you haven't exercised is a hope.
• Confirm the fix introduces nothing new. Read the diff as an attacker: does the parameterization change behavior for a legitimate input? Does the added validation reject something valid? Does the "safe" library call have its own known issue? Run the test suite.
• Confirm the explanation is accurate. The model sometimes describes an exploit path slightly wrong (right conclusion, wrong mechanism). Since the developer will trust your explanation, make sure the mechanism you ship is the real one.
• Check the fix is idiomatic for the codebase. A technically-correct fix that fights the framework's conventions invites a worse reimplementation later.

Pitfalls

• Shipping the fix without running the exploit. The whole point is to close the hole; confirm it's closed.
• Whole-file rewrites. Large diffs stall in review. Insist on minimal patches.
• Confident-but-wrong exploit narratives. If your write-up misdescribes the mechanism, the developer may "fix" the wrong thing. Verify the mechanism.
• Over-validation. Models love to add belt-and-suspenders input checks that reject valid data or duplicate framework guarantees. Keep the fix scoped to the actual vuln.
• No proof attached. Guidance without a reproducible before/after invites a "works on my machine" dismissal. Always include the failing-to-passing evidence.

Tools

• Semgrepre-run the flagging rule after the patch to confirm the finding clears, and to generate the before/after evidence for the PR.
• An LLM coding assistant (Claude / Copilot-class)drafts the minimal patch, the exploit-then-fix explanation, and the PR wording in the developer's stack.
• GitHub Copilot (or an IDE assistant)convenient for applying and testing the small diff inline where the developer already works.

Client-safe variant

Remediation guidance quotes the client's vulnerable code and describes a real exploit against their system — both sensitive. Before prompting, redact real endpoints, credentials, and customer identifiers, and reduce the code to the security-relevant function. If the client's policy bars public tools, run a local model for the drafting and keep the scanner-based proof (which runs offline) as the evidence. Deliver the write-up in the client's own tracker, never paste working exploit payloads against production into an external tool, and confirm per-client tool approval before the first prompt.