- Trail of Bits reviewed its own merged open-source patches and confirmed 21 regressions among more than 130 pull requests, none of which broke a security protection.
- As AI speeds up bug discovery, fixes need proof too. The firm released two agent plugins that demand a live demonstration for every claim, though its tests are preliminary.
- Ask your teams what evidence a patch needs before merging, who checks for regressions, and whether critical systems have written threat models and patching rules.
A security fix is a change to running software. Like any change, it can break something that worked. As AI speeds up the discovery of bugs, the fixes pile up behind them, and each one needs checking. That is the problem Trail of Bits addressed on October 21, when it published two plugins for AI coding agents and the data behind them.
What Trail of Bits found in its own patches
Trail of Bits runs Patch the Planet with OpenAI. Hundreds of fixes for widely used open-source projects have come out of that partnership. In September, the firm reported regressions in some of those patches. Since then, it has reviewed every patch its engineers wrote that maintainers merged upstream.
The review confirmed 21 regressions among more than 130 merged pull requests. Trail of Bits counts 16 as functional, one as performance and four as build or test problems. The firm says none broke a security protection. The count covers only the firm's own patches, so it is not an industry-wide rate.
Its test for a regression is strict. The problem must come from a change, it must damage behavior the project supports and that used to work, and a real user or attacker must be able to reach it.
Fixing a bug is a claim that needs proof
Here is the idea worth keeping. A patch is a claim: this change fixes the problem and breaks nothing else. Review has traditionally rested on the author's confidence and a reviewer's attention. When bug reports arrive in volume, both run thin.
Trail of Bits' answer is to replace confidence with evidence. Its two plugins are patching-bugs, which reproduces a bug, develops a fix and tests it, and regression-hunt, which checks whether a change breaks supported behavior. Engineers direct the work and review the results.
How the checks work
Both plugins rest on one rule. Every conclusion needs a proof of concept run against a live deployment. That means a built, running copy of the project, reached the way a real user would reach it. If a step cannot produce one, its result counts as inconclusive.
The patching plugin uses what Trail of Bits calls a three-arm proof. The same reproduction runs against three versions of the code. The original must fail. The patched version must pass. A full revert of the patch must fail again. If removing the patch brings the bug back, the patch is the likely reason it went away, not some unrelated change in the test environment.
The regression plugin works in stages. One step traces the changed code through its callers to the real interfaces and lists candidate regressions. Another reproduces each candidate on a live system. A fresh agent with no prior context replays the proof. A final adjudication step judges whether the evidence meets the definition.
That last step is where the burden of proof sits. The agent must show that a suspect finding is not a false alarm, a half-finished fix, or a bug that was already there. The plugin reports a regression only if the finding clears every one of these gates.
Each step takes and returns a fixed format covering the claim, the code revision, the check, the raw evidence and open questions. The firm says this lets each step verify the last one's work instead of trusting its summary.
The noise problem, and the limits of the numbers
Finding regressions is also noisy. In a single run, the agent produced 58 candidates, and 21 were confirmed. Trail of Bits puts that precision at about 36%. Because agents take different approaches, each run adds candidates that people must sort.
Trail of Bits says its early tests showed regression-hunt raising about a quarter fewer false alarms than a plain Codex agent asked to review the pull request for regressions. The margin of error is wide. At 95% confidence, the firm puts the true improvement anywhere from 14% to 38%.
Read this with care. The evaluation uses the firm's own patches as the test set. The comparison is against one baseline prompt. The company describes the results as preliminary.
There is also a tradeoff. The strict evidence rules left some known regressions classed as borderline: the plugin spotted a possible problem but could not gather enough evidence to confirm it. Fewer false alarms came at the cost of confirming fewer real regressions.
The project's rules decide the quality
The plugins perform better when a project supplies its own knowledge. Trail of Bits asks for two files. The first, THREAT_MODEL.md, tells agents what the project treats as a vulnerability or a regression. It covers the assets that matter, trust boundaries, access controls and supported configurations. PATCHING_GUIDELINES.md, or AGENTS.md, says how the project wants fixes built, tested and presented.
On GPAC, the firm's engineers drafted a threat model and a patching skill tailored to that project. The skill records how GPAC's maintainers want bugs reproduced and what evidence a fix needs. Two other projects, liboqs and validator.js, have published threat models following the firm's guidance. The lesson for any organization is plain. An agent can only follow standards that someone has written down.
What leaders should ask
If your teams use AI agents to write or accept fixes, put these questions to them.
First, what evidence does a patch need before it merges? A passing test is weaker than a reproduction on a running system, before and after the change.
Second, who checks for regressions, and with what written definition? Trail of Bits found 21 regressions in patches that maintainers had merged, so merge-time review alone cannot be assumed to catch them.
Third, do your critical systems have a written threat model and patching rules? Without them, an agent has nothing to check its work against.
Fourth, how many false alarms can reviewers absorb? Stricter checks cut noise but may miss real problems. Decide that tradeoff on purpose.
Faster discovery of bugs only helps if fixes can be trusted at the same speed. A patch that cannot show its evidence is a hope, not a repair.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Trail of Bits.
