Detection scaled. The loop did not.

Findings got cheap. Verified closure did not. That AppSec remediation gap is the actual problem.

AppSec spent a decade winning the wrong race. We got very good at finding things. Scanners in CI. SCA on every manifest. SAST on every pull request. Container and IaC checks on the way to the cluster. Then AI arrived and did what AI does to a solved problem: it made discovery cheaper, louder, and continuous. The same model that writes the function will also enumerate the ways to break it. Findings are no longer scarce. They are a feed.

Sit with what that actually produced. Not a safer estate. A wider gap between what you can see and what you can close: the verification gap between a proposed fix and a fix that’s actually confirmed gone. This series is about closing that gap. Six pieces, in this order: the problem, the doctrine, the write path, the verify stage, the moment the consumer of AppSec is an agent, and, when the product can carry it, the loop as a system with proof. This is the problem. Doctrine comes next. Architecture after that. Proof last. We will not skip ahead.

The filing is the mistake

When a CISO looks at a dashboard that is redder than last quarter, the instinct is to buy more detection. Another scanner. Another feed. Another AI that “finds more.” That instinct is rational if the scarce resource is visibility. It has not been, for years.

Veracode’s 2026 State of Software Security report put numbers under a feeling every AppSec lead already has. Fix speed improved. The half-life of flaws moved from 252 days to 243. Nine days. In the same breath, the share of applications carrying OWASP Top 10 flaws went up. Third-party flaws found by SCA still sit at a half-life of 358 days. Detection is not the lagging function. Closure is.

I do not need that report to believe the loop is broken. I need it so we stop arguing from mood. The industry got faster at seeing. It did not get faster at finishing. AI made the mismatch structural. Generation compresses the time from idea to commit. Every commit is more surface. Every surface is more findings. The team that is supposed to turn a finding into a verified change did not get a matching compression. So the backlog is not a staffing anecdote. It is the rate of generation minus the rate of closure, compounding.

If you measure the program by findings opened, you will report success while the loop fails.

Three loops, only one of them closed

Most AppSec programs actually run three loops and call them one.

The first is detection. Code, dependencies, containers, configurations, now models and agents. This loop closed. It closes every night. It is the part we know how to buy and the part vendors know how to sell.

The second is triage. Reachability, exploitability, ownership, exception. This loop is half-closed. The tools got better. The politics did not. Someone still has to decide that this CVE is the afternoon, and that one is a waiver, and this package is owned by a team that left in 2022.

The third is remediation that holds. A change lands. The vulnerable path is gone, not just the ticket. Tests pass. The next scan does not reopen the same issue under a new ID. This is the loop that did not close. It is also the only loop an attacker cares about.

People collapse all three into “we have AppSec.” That is how you get a mature detection program and an immature security outcome. The dashboard is busy. Production is not meaningfully different. AI did not invent the third loop’s failure. It removed the slack that used to hide it. When humans wrote the code, you could pretend a 243-day half-life was a process problem you would get to. When models write the code, 243 days is a decision to carry known risk at machine speed.

Validation is the part that is actually widening

There is a quieter failure inside the third loop, and it is the one I want named before we talk about tools.

A ticket moving to “done” is not a verified fix. A dependency bump that compiles is not a verified fix. An AI-suggested patch that makes the scanner go quiet is not a verified fix. The scanner going quiet is a statement about the scanner.

The validation gap is this: we have scaled the production of proposed changes, and we have not scaled the production of justified confidence that the change did what we think it did, and only that. That gap widens as generation speeds up, for a boring reason. More proposed fixes. More ways to be wrong. More pressure to accept a green check as the end of the story. The failure mode is not “we missed a CVE.” It is “we shipped a change we did not actually close, and we updated the risk register as if we had.”

If you want a test: count how many of last quarter’s “remediated” items would survive a second look that asks whether the vulnerable path still exists. Not whether the finding is suppressed. Whether the path is gone. The number is the health of the loop. The finding count is not.

What this is not

This is not an argument against detection. You cannot close what you cannot see. Inventory still comes first. Reachability still matters. Exploitability still matters. None of that is the bottleneck anymore. Treating it as the bottleneck is how programs get more sophisticated and less finished.

This is also not yet the independence argument. That is the next piece. You can believe everything above and still think the same platform that wrote the code should also grade the fix. I think that is a category error, and I will make that case on its own terms. I will not smuggle it in here. The broken loop is a problem even if you have never heard of Mend.io, and even if you are loyal to the generator.

And this is not a pitch for more dashboards. A dashboard is a view of the first two loops. The third loop lives in the write path: a change, a review, a merge, a verification that is allowed to fail.

What I would do this quarter

• Stop reporting program health as volume of findings. Report rate of verified closure against rate of new reachable risk. If you cannot produce that ratio, you do not have a verified path. You have a scanner.
• Separate “we have a fix suggestion” from “we have a verified close.” Put them in different columns. Watch which one grows when you turn on AI.
• Pick one class of issue you already know how to detect (dependencies are the honest one) and measure time from reachable finding to merged change that still looks closed on a subsequent scan. That number is your actual MTTR. The SLA on the ticket is a story you tell GRC.
• Do not add a scanner until you can say what happens to its output on the write path. Unconsumed detection is not coverage. It is inventory of unfinished work.

The bottom line

Detection scaled. The loop did not. The scarce resource in AppSec is no longer a finding. It is a verified change that holds.

That is the bottleneck. I have called it verification before, and I will keep calling it that, because “remediation” in practice has come to mean “we generated a patch,” which is only the middle of the job. The job ends when an independent look at the running system, or the code as it will run, can say the path is gone.

The next piece is why the system that authored the change is the wrong system to say that. The auditor cannot be the author. That is doctrine. This piece was only the problem. If we skip it, the rest of the series is architecture in search of a reason.

Related reading:

• OWASP LLM Top 10 2026: the model will be fooled, the question is what breaks
• The skill layer is a dependency problem without a lockfile: what the OWASP Agentic Skills Top 10 gets right