GNOME Just Rewrote Its Security Rules Because of AI Slop

The slow collision between AI-generated bug reports and open-source maintainers just claimed its biggest piece of governance yet. Michael Catanzaro, who has run security issue tracking for GNOME since November 2020, announced three changes today: the disclosure deadline for GNOME vulnerabilities drops from 90 days to 30, security reports will no longer be forwarded to projects whose policies ban AI-generated content, and he is personally stepping down from the role this fall^[1].

Start with the deadline, because it sounds reckless and is actually honest. The industry-standard 90-day window assumes vendors need months to ship fixes. Catanzaro's observation after nearly six years of data is that GNOME maintainers either fix an issue within one to three weeks or never touch it, so the extra two months of confidentiality "only introduces a delay that is not useful"^[1]. A disclosure policy should describe reality. This one now does. Honest for GNOME, though, reads differently downstream. GNOME is the default desktop of RHEL, SUSE, and Ubuntu, and a 30-day clock leaves Red Hat and Canonical far less room to coordinate, backport, and test a fix across every supported release before the details go public. The window did not shrink for GNOME alone. It shifted the burden of speed onto the enterprise ecosystem, which now inherits the deadline whether its release calendars like it or not.

The slop problem

The second change is the one that will make people sit up. Several GNOME projects, in a policy trend that started with the Loupe image viewer, prohibit all LLM-generated contributions, including issue reports. But most incoming security reports now contain AI-generated text, so forwarding them would violate those projects' own rules. The pragmatic fix: reports meant for those projects get closed immediately in the central tracker, with a ping to the maintainers so nothing real dies silently^[1]. The distinction from forwarding is thin but real: the machine-written text itself stays out of the project's tracker, and the maintainers learn only that a report exists, which their own policy leaves them free to go read or ignore. If you want one sentence to describe where open source is in 2026, "we had to route around the AI policies" is a strong candidate.

Catanzaro has been unusually quantified about the flood. In June he wrote that he had reviewed "well over 100 vulnerability reports that I strongly suspect were generated by AI," counting only a particularly heavy four-week stretch, which makes it a very loose lower bound^[2]. And here the story stops being a clean maintainer-versus-AI binary, because the same June post calls banning AI-assisted reports "stupid" and warns that a ban "punishes your users": an expert with a good model files excellent reports, and he credits one with a real code-execution flaw in Evince, Atril, and Xreader. The disaster is the other tail, "an inexperienced human with a bad AI" producing reports where a significant share is outright spam. Sit with that tension: the man stepping down under a flood of machine-generated slop is the same man begging GNOME projects not to ban the tools that generate it, on the grounds that those tools in skilled hands are simply what security research looks like now. Since non-AI reports are the unusual case either way, he argues, policy written for them is fiction^[2].

Every project is inventing its own immune response

Compare the approaches now on the board. The Linux kernel's answer to suspected AI reports is immediate full disclosure, and not only on the theory that a vulnerability a chatbot can find is one attackers already have. The kernel security team keeps receiving the same AI-generated finding from multiple researchers within days of each other, because parallel scanners running over the same code converge on the same bugs. An embargo protects a secret, and there is no secret once five bots have found it independently. Catanzaro calls the kernel's approach pretty extreme and unkind to maintainers, and he is right on both counts^[1]. Fedora's bug tracker drowned earlier this summer when an AI agent went feral inside it^[4]. GNOME's own bug bounty program closed entirely after the reports it attracted turned out to be mostly noise, and curl killed its bounty for the same reason, two more casualties Catanzaro tallies in his post^[1]. Nobody has a good answer. Everybody has an answer shaped by what they can survive.

The part I keep coming back to is the resignation. Catanzaro stops triaging new reports in November and is asking for a successor, which means the project now has to find a volunteer willing to read a hundred machine-written vulnerability reports in a bad month, forever, for free^[3]. The AI industry likes to say its tools will handle the tedious work. In open-source security, the tools are generating the tedious work and billing the maintainers for it. Somebody should invoice the labs.