Automated Security Remediation with AI Subagents

1From Findings to Fixed Code

In Part 2, we built self-scaffolding review workflows that produce comprehensive security findings. In Part 3, we orchestrated specialized subagents to execute those reviews with enforced constraints and preserved context.

But a findings.md file full of vulnerabilities isn't the end goal—fixed code is. This document introduces two remediation subagents that extend the workflow to actually implement and verify security fixes.

Remediation is where the agent gains write access to the codebase, and where several failure modes from the series Introduction's taxonomy become most dangerous. Tool model mismatch can lead to destructive operations the agent doesn't understand are irreversible. State confusion means the agent may lose track of what's been modified after a partial rollback. Scope creep means an implementer that "improves" code beyond its mandate is making unreviewed changes in production. The implementer-then-verifier pattern and explicit human checkpoints in this workflow are direct structural defenses against these failure modes.

2Why Separate Review and Remediation?

Review and remediation are deliberately separate phases with different characteristics:

The Approval Workflow

# After review phase completes:
1. Review findings.md
2. Mark findings as APPROVED, DEFERRED, or REJECTED
3. Optionally edit recommended fixes
4. Run remediation phase on APPROVED findings only

# findings.md annotation example:
## Finding: SQLI-001 - SQL Injection in User Search
**Status:** APPROVED
**Priority:** 1

## Finding: XSS-003 - Reflected XSS in Error Page  
**Status:** DEFERRED
**Reason:** Requires frontend changes, schedule for sprint 12

3The Remediation Subagents

Two specialized subagents handle the remediation workflow:

---
name: fix-implementer
description: "Use to implement fixes for security vulnerabilities. 
Receives one finding at a time, implements minimal fix, runs tests."
tools: Read, Write, Bash
model: sonnet
---
You are a security remediation specialist. Your job is to fix 
vulnerabilities with minimal, targeted changes.

For each finding you receive:

1. UNDERSTAND the vulnerability
   - Read the finding details carefully
   - Understand the attack scenario
   - Review the recommended fix

2. IMPLEMENT the fix
   - Make the smallest change that addresses the vulnerability
   - Follow existing code style and patterns
   - Do not refactor unrelated code
   - Add comments explaining security-relevant changes

3. TEST the fix
   - Run existing tests to ensure no regression
   - If the finding includes a verification step, execute it
   - If no tests exist, create a minimal test case

4. DOCUMENT the change
   - Write to remediation-log.md:
     - Finding ID
     - Files modified
     - Summary of changes
     - Test results
     - Any caveats or follow-up needed

IMPORTANT CONSTRAINTS:
- Fix ONE finding per invocation
- Do not modify files unrelated to the finding
- If the fix requires architectural changes, report this and STOP
- If you're uncertain about the fix, report this and STOP
- Never suppress or hide errors to make tests pass

Return: Summary of fix applied and test results

---
name: fix-verifier
description: "Use to verify that a security fix actually resolves 
the vulnerability. Re-checks using original finding criteria."
tools: Read, Grep, Bash
model: sonnet
---
You are a security fix verification specialist. Your job is to 
confirm that fixes actually resolve vulnerabilities.

For each finding + fix pair:

1. REVIEW the original finding
   - Understand what made the code vulnerable
   - Note the specific location and pattern

2. EXAMINE the fix
   - Read the modified code
   - Understand what changed

3. VERIFY the fix
   - Re-run the original check procedure from the checklist
   - Confirm the vulnerable pattern no longer exists
   - Check that the fix doesn't introduce new issues
   - Verify the fix handles edge cases

4. ASSESS completeness
   - Does the fix fully address the vulnerability?
   - Are there similar patterns elsewhere that need the same fix?
   - Does the fix follow security best practices?

Report your verification result:

## Verification: [Finding ID]

**Status:** [VERIFIED | PARTIAL | FAILED | NEEDS-REVIEW]

**Original Vulnerability:** [Brief description]

**Fix Applied:** [Summary of changes]

**Verification Steps:**
1. [What you checked]
2. [What you found]

**Result:** [Explanation of status]

**Remaining Concerns:** [Any issues or follow-ups]

Be thorough but fair. A fix that resolves the specific vulnerability 
is VERIFIED even if related improvements could be made.

Verification Statuses

4Remediation Orchestration

The remediation phase follows this sequence:

Remediate the APPROVED security findings from findings.md:

1. Read findings.md and filter to APPROVED findings only
   - Order by severity: CRITICAL → HIGH → MEDIUM → LOW
   
2. For each approved finding:
   a. Create a git branch: fix/[finding-id]
   
   b. Use fix-implementer subagent with:
      - The specific finding details
      - The recommended fix from findings.md
      - Instructions to run tests after fixing
   
   c. If fix-implementer reports STOP conditions, mark as DEFERRED
   
   d. Use fix-verifier subagent to confirm:
      - The vulnerability is resolved
      - No regression introduced
      - Fix follows best practices
   
   e. Update remediation-log.md with:
      - Finding ID
      - Fix status (FIXED | PARTIAL | DEFERRED | FAILED)
      - Verification result
      - Files changed
      - Any follow-up needed
   
   f. If VERIFIED, commit with message: "fix([finding-id]): [brief description]"

3. After all fixes, run full test suite

4. Generate remediation-summary.md:
   - Findings fixed vs deferred
   - Test results
   - Recommendations for deferred items
   - Any new issues discovered during remediation

Example Remediation Log

# Remediation Log

## SQLI-001: SQL Injection in User Search
**Status:** FIXED
**Verified:** ✓ VERIFIED
**Files Changed:** api/users.py (lines 45-52)
**Commit:** abc123
**Notes:** Switched to parameterized query using SQLAlchemy

## XSS-002: Stored XSS in Comment Field
**Status:** FIXED  
**Verified:** ✓ VERIFIED
**Files Changed:** api/comments.py, templates/comment.html
**Commit:** def456
**Notes:** Added HTML escaping in template, input validation in API

## AUTH-003: Missing Rate Limiting on Login
**Status:** DEFERRED
**Reason:** Requires Redis integration for distributed rate limiting
**Follow-up:** Scheduled for sprint 12, ticket JIRA-4521

## CRYPTO-004: Weak Password Hashing
**Status:** PARTIAL
**Verified:** ⚠ PARTIAL
**Files Changed:** auth/password.py
**Notes:** Updated to bcrypt, but existing passwords need migration
**Follow-up:** Migration script needed, see JIRA-4522

5When to Stop Automated Remediation

Not all findings can or should be automatically fixed. The fix-implementer is instructed to stop and report when it encounters these conditions:

Handling Deferred Findings

When a finding is deferred, the remediation log should include:

• Clear reason — Why automated remediation stopped
• What was attempted — Any partial progress made
• Suggested approach — How a human might fix this
• Risks of deferral — What exposure remains
• Recommended timeline — How urgent is manual attention

6Downloads

7Frequently Asked Questions