Automated Vulnerability Repair

How Automated Vulnerability Repair Works

An AVR system takes a confirmed finding and the code around it, works out the root cause and proposes a change. Better systems then check the change before anyone sees it, by building the code, running tests and confirming the vulnerability is actually closed.

Why a Fix Is Not the Same as a Correct Fix

AI models can write code that looks right and is not. A generated fix can block one input but leave the underlying flaw, break a feature, or change behavior nobody asked it to touch. Models can also suggest dependencies that do not exist, which attackers have learned to exploit. The hard part of AVR is not writing a patch but proving it works.

How to Validate an Automated Fix

• Build and test. The fix must compile and pass the existing test suite.
• Exploit replay. Re-run the original attack against the patched code and confirm it now fails.
• Feature checks. Confirm the change did not break expected behavior.
• Minimal scope. Prefer small, root-cause changes over broad rewrites.
• Human approval. An engineer reviews and merges, with the evidence in front of them.

Where AVR Struggles

Fixes that need design decisions, such as changing an authorization model, or that span several services are hard to automate safely. A good system knows when to hand a finding to a person instead of forcing a patch.

How Nullify Approaches Automated Fixes

Nullify's Autofix writes a minimal, root-cause fix and validates it against the build and tests before the pull request opens. Proposed fixes are independently reviewed, and Nullify manages the PR through review, reading CI output and fixing failures. Where an exploit exists, replaying it serves as the acceptance test. Nullify never auto-merges. See how Nullify delivers merge-ready fixes.