Patch application vulnerabilities with evidence

Learning objective

Use a coding agent to patch an application-layer vulnerability through an inspect–change–verify workflow. Produce evidence that the exploit no longer works and intended behavior still does. This lesson does not cover sandbox selection or agent access controls.

Core idea

Treat a vulnerability report as a hypothesis, a patch as a proposed control, and verification as the evidence that connects them. The mental model is prove the path, break the path, prove the break:

1. Inspect: reproduce the unsafe behavior and trace its root cause.
2. Change: enforce the missing security invariant at the correct boundary.
3. Verify: show that the original attack fails, valid behavior passes, and the patch causes no unacceptable regression.

A scanner alert disappearing is not the same as a vulnerability being fixed. The change might suppress the alert or block only one payload. Google DeepMind applies the same standard to CodeMender: a high-quality patch fixes the root cause, remains functionally correct, causes no regression, and receives human review (Introducing CodeMender).

How it works

Inspect the vulnerable path

Give the agent the finding, affected revision, security requirement, and relevant repository context. Ask it to collect evidence before editing:

• Reproduce the issue in an isolated environment with a minimal request or failing security test. Do not test an exploit against production.
• State the security invariant that fails, such as “a caller can read only orders permitted by the authorization policy.”
• Trace attacker-controlled data from its source through parsing, validation, and business logic to the sensitive sink or resource.
• Inspect adjacent enforcement code and tests. Search for paths that may share the same root cause.

This is more than locating the line named by a scanner. OWASP recommends tracing data from sources through processing to sinks and checking business logic and authorization, which automated pattern matching can miss (Secure Code Review Cheat Sheet).

Change the enforcement point

Ask for the smallest coherent patch that restores the invariant. Use an established control for the vulnerability class: a parameterized interface for injection, contextual output encoding for cross-site scripting, or a server-side policy decision for authorization. Prefer a shared enforcement point when several entry points require the same rule.

Add a security regression test that fails on the vulnerable revision and passes after the change. Include permitted and denied cases. Review the diff for unrelated edits, disabled checks, additional bypasses, and exposed secrets.

Do not accept a blocklist tuned to one payload when the attack has other forms. A web application firewall rule or scanner suppression can provide temporary containment, but it is not a source-code fix at the vulnerable boundary.

Verify independent evidence

Verification should challenge the patch from several directions:

1. Rerun the exploit or security regression test. Confirm the safe result, not merely a different error.
2. Test valid requests, denied requests, boundary values, relevant roles, and alternate routes or methods that reach the same operation.
3. Run focused unit or integration tests, then the broader regression suite and required build, lint, and type checks.
4. Rerun the detector that produced the finding with the same relevant rules. Use static analysis, dynamic analysis, or fuzzing when it fits the flaw.
5. Inspect the final diff and test evidence before a human reviewer approves the merge.

No single signal is sufficient: exploit tests can miss variants, scanners can miss business-logic flaws, and general tests can pass while preserving an exploit. NIST’s Secure Software Development Framework separates code review, executable-code testing, and vulnerability response, and emphasizes addressing root causes to prevent recurrence (NIST SSDF).

Key distinctions and trade-offs

Finding versus root cause: A finding identifies observed unsafe behavior or a suspicious pattern. The root cause explains which trust or policy invariant the application failed to enforce.

Security regression test versus ordinary regression test: The security test encodes the attack and expected denial. Ordinary tests protect legitimate behavior. A defensible patch needs both.

Narrow diff versus complete fix: A small diff is easier to review, but the smallest line change may leave equivalent paths vulnerable. Expand scope only to the shared root cause and its necessary tests, and record follow-up work for unrelated findings.

Agent execution versus approval: A coding agent can inspect, edit, and run checks. It does not replace independent evidence or the human accountable for accepting residual risk. Google Cloud recommends a secure software development lifecycle even when teams use AI coding assistance (Gemini Code Assist security guidance).

Architecture / decision scenario

An API exposes GET /api/orders/{orderId}. A signed-in user can replace orderId with another customer’s identifier and receive that order.

During inspection, the coding agent creates an integration test in which Alice’s authenticated request asks for Bob’s order. The agent traces the disclosure through authentication, the route handler, and the repository. Authentication establishes Alice’s identity, but the repository loads an order by ID alone. This is broken object-level authorization, not an authentication failure. OWASP states that every endpoint acting on an object ID must check whether the signed-in user may perform that action on that object (API1 Broken Object Level Authorization).

The change routes access through a shared authorization policy and takes Alice’s identity from trusted authentication context. The policy covers ownership, tenant membership, and delegated access, so a simplistic ownerId == userId comparison does not break valid sharing.

Verification shows that Alice cannot read Bob’s order, Alice can read her own, and an authorized delegate keeps access. The team also tests update and delete paths that use the same lookup, runs the full suite and security scanner, and reviews the diff. This matches OWASP guidance to deny by default, validate permissions on every request, and test authorization logic (Authorization Cheat Sheet).

The patch adds one hop between the route handler and the repository: the shared authorization policy.

Common exam traps

• Asking the agent to make a security alert disappear without reproducing the exploit or stating the failed invariant.
• Patching the line in a scanner report without tracing the full source-to-sink or identity-to-resource path.
• Treating input validation as a universal fix for injection, output encoding, or authorization flaws.
• Rerunning only the scanner or only the ordinary test suite.
• Assuming authentication proves that an authenticated caller may access every requested object.
• Merging an agent-generated security patch without a reviewable diff and human approval.

What to remember

• Prove the vulnerable path before changing it.
• Patch the root cause by restoring a clear security invariant at the correct boundary.
• Preserve the exploit as a negative regression test and add positive cases for intended behavior.
• Verify with independent security, functional, and diff-review evidence.
• Treat the coding agent as an accelerator, not the authority that accepts risk.

Knowledge check

References

• Google DeepMind, Introducing CodeMender: an AI agent for code security
• Google Cloud, Security, privacy, and compliance for Gemini Code Assist
• NIST, Secure Software Development Framework
• OWASP Cheat Sheet Series, Secure Code Review Cheat Sheet
• OWASP Cheat Sheet Series, Authorization Cheat Sheet
• OWASP API Security Project, API1 Broken Object Level Authorization