AI Security Findings Need a Fix Capacity Budget Before Any Scanner Rollout

A team adopting AI security scanning should decide how many findings it can verify and fix each week before it decides how much code to scan, because AI has made discovery fast while every fix still runs through people. Chris Stokel-Walker makes the case in a recent article that AI security findings now arrive faster than teams can fix them, and this piece follows his point about triage load to the budget a leader needs before rollout.

Stokel-Walker reports that AI now produces real security findings faster than teams can fix them

Stokel-Walker opens with Google pausing product vulnerability submissions to its open-source bug bounty program after a rise in automated reports, its second restriction of the year after a March tightening aimed at hallucinated reports. He then turns to Daniel Stenberg, the creator and lead developer of curl, who tells him that bogus reports have largely disappeared and the hard problem is now a high volume of valid ones.

Stenberg’s advice in the article is that managers should avoid overloading their teams with findings, that scanners should confirm a vulnerability is real before handing it to developers, and that people reporting issues should check them by hand and write them up plainly. His closing line is “Use whatever tools you like, but communicate as a human.”

Each AI security finding carries a human workflow that scanning does not shorten

Stenberg described the work behind each report in a blog post titled “The pressure”, published on 26 May 2026. For every report on curl’s HackerOne queue, the security team has to verify the claim, assess its importance, write a patch, work out when the bug was introduced, understand the vulnerability, write a detailed public advisory, and communicate with the researcher and the rest of the team. That is seven steps, and an AI scanner speeds up none of them. It speeds up the step before the list starts.

The same post gives the arrival rate. Reports were coming in at 4 to 5 times the 2024 rate and double the 2025 rate, which Stenberg puts at more than one report a day. With about half a release cycle left, the project had twelve confirmed vulnerabilities waiting for CVE announcements, and he expected curl to reach thirty published CVEs in 2026 before the year was half over. He also wrote that if the team did not handle reports at roughly the speed they arrived, the backlog would simply grow.

A backlog of AI security findings grows without limit when they arrive faster than fixes

Stenberg’s last point is the one engineering leaders should plan around, because it is arithmetic. Take a hypothetical team that closes five security findings a week. If a new scanner produces eight valid findings a week, the queue grows by three every week, and it keeps growing for as long as the scanner runs. The backlog does not level off at some comfortable size. Extra detection only adds to waiting time unless fix capacity rises with it.

That makes fix rate the number to know before rollout. Most teams can read it from their existing tracker as the median count of security findings closed per week over the last quarter. With that figure in hand, a leader has three honest options: limit scan scope, rule sets, or frequency so expected valid findings stay below the fix rate; add people or time to remediation before switching the scanner on; or accept a growing queue and say so explicitly. The failure mode is the fourth option, where the scanner goes live and the queue grows without anyone having chosen that outcome.

The order of the security queue matters more than its length

A queue that cannot be cleared has to be ordered well. Most valid findings are low risk. Stenberg notes in the same post that every curl vulnerability found in the last few years was rated LOW or MEDIUM, and that the most recent HIGH severity curl CVE was published in October 2023. At a wider scale, Sasha Romanosky and Jay Jacobs write in FIRST’s guide to interpreting EPSS scores that only around 5% of all vulnerabilities are ever exploited in the wild. EPSS, the Exploit Prediction Scoring System, estimates the probability that a published vulnerability will see exploitation activity in the next 30 days.

A team working findings in the order they arrive spends most of its limited capacity on items that will never be exploited. Ordering by exploitation likelihood puts the scarce hours where an attacker is most likely to act.

There is a boundary here. EPSS scores published CVEs, and a fresh finding in a team’s own code has no CVE and no score. For those findings the team needs its own short rubric, written down before rollout: whether the code path is reachable from untrusted input, whether the service is exposed to the internet, and what data it can touch.

Deferring a security finding is a risk decision that needs an owner

Ordering the queue means some findings wait, and a finding in a tracker is a known weakness. The counter-case to throttling scans is that a company which knowingly leaves a vulnerability open carries more responsibility than one that never found it. That argues for treating each deferral as a recorded risk acceptance, with a named owner and a review date, so the decision is visible to the people accountable for it.

There is also a cheaper place to spend detection. Stenberg argues in Stokel-Walker’s article that teams should use these tools on their own code so quality improves. A finding raised on a change still in review is fixed by the engineer who wrote it, while the context is fresh, and because the code has not shipped there is no public advisory to write. Pointing AI scanning at new changes first, and sweeping older code at a pace the fix rate can absorb, keeps most findings out of the most expensive part of Stenberg’s seven-step list.

Why This Matters for Engineering Leadership

AI security scanning is usually bought as a detection tool and judged by how many issues it finds. Stokel-Walker’s reporting and Stenberg’s own account show that the cost lands downstream, on a small number of people who verify, patch and disclose each finding by hand. For an engineering leader the governance question is whether the organization has chosen how much remediation work it is taking on. Measuring the fix rate, sizing scans to it, ordering the queue by exploitation likelihood, and recording every deferral turns a flood of findings into a workload the team can plan. It also protects the people doing the work, which is the concern Stenberg raised about his own team.

FAQ