Michael Catanzaro has spent years running security response for GNOME, and his new essay is the clearest thing written so far about what AI has done to vulnerability work in open source. Its thesis is blunt: “There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning.” The numbers he brings are not rhetorical. GNOME went from 13 CVEs in 2023 to 37 in 2024, 97 in 2025, and 141 in the first nine months of this year, which normalizes to roughly 188. WebKitGTK shows the same pattern with an extreme: 305 CVEs in 2026, almost all from AI analysis of Skia and ANGLE, the graphics libraries WebKit bundles. Excluding those, it is 21 CVEs, a decrease.
The uncomfortable part
The wave is the bill for years of not looking. Catanzaro’s position is that the bugs were always there; pervasive scanning is simply the first time anyone checked. It follows that stopping the scanning would not make the flaws go away, and that the attackers, who now generate working exploits cheaply, will find what the scanners would have. He has put his time where the argument is: his own tracking stops here, so the numbers above are also the end of that particular dataset, and GNOME’s bug bounty program has already been wound down.
The policy fight inside open source
Some GNOME maintainers have adopted rules prohibiting AI-generated content in issue reports. Catanzaro argues that is self-defeating: the overwhelming majority of vulnerability reports are now AI-assisted, so a ban on AI reports is close to a ban on vulnerability reports. He accepts that the reports are often verbose, sometimes inflate severity, and occasionally contain fabricated stack traces, and he wants quality standards enforced on the content. What he does not accept is authorship as the filter. He also dismisses the common counterargument that humans should rewrite AI reports, on the grounds that nobody will rewrite a hundred reports to be nice to a maintainer.
His concrete proposal: GNOME should permit AI-generated vulnerability reports, and projects that continue to prohibit them are no longer suitable dependencies for GNOME, and should live somewhere other than GNOME’s GitLab. There is a Rust section, too, with a take some people will hate: memory safety reduces the need for scanning but does not remove it, and he argues against more Rust in GNOME on the grounds that Cargo’s dependency supply chain is a bigger risk than the memory flaws Rust prevents.
My read
The scarce resource has moved from finding bugs to triaging them, and every policy that filters reports by how they were produced instead of whether they are true is a way of not triaging. Catanzaro’s essay is one side of a live argument, but the GNOME numbers and the same reporting pattern Daniel Stenberg describes for curl are hard to argue with. If you maintain anything, read it before you write your own AI policy, because your backlog is already being written by these tools whether you accept the reports or not.
Source: the essay.