AI-generated reports push GNOME to shorten its disclosure window
Volunteer maintainers of open source projects now receive a steady flow of security vulnerability reports produced with AI tools. Many arrive with no mention that a language model helped write them. The volume has grown enough that GNOME is revising the rules it uses to track and disclose vulnerabilities across its projects.
The changes come from Michael Catanzaro, who has run GNOME’s security issue tracking since November 2020 with support from Red Hat. Under the new approach, GNOME applies one set of rules to every vulnerability report, treating AI-assisted and human-written submissions the same way.
“Reporters rarely disclose AI use, and it’s nice to not have to guess whether the issue report is AI-generated or not; it’s normally obvious, but not always. Also, vulnerability reports that are not discovered by AI are becoming increasingly rare. Non-AI reports are now moderately unusual, so it really doesn’t make sense to optimize for them,” Catanzaro explained.
A shorter disclosure deadline
For years, GNOME held vulnerability reports confidential for 90 days before disclosure, matching a timeline common across the industry. That window fit GNOME’s workflow poorly. Maintainers tend to resolve a valid report within a few weeks of receiving it, or they leave it open until the deadline arrives and the report becomes public. The long confidentiality period added delay with little benefit. Catanzaro discloses a report and requests a CVE once the issue is fixed or once the deadline passes, whichever comes first.
“I will switch to a 30 day disclosure deadline for issues reported on August 1, 2026 or later. This seems like a good compromise. The shorter deadline would probably work better for GNOME even if not for the increase in AI-generated issue reports,” Catanzaro said.
Other projects have gone further. The Linux kernel adopted immediate disclosure for reports that appear to be AI-generated, reasoning that any vulnerability an AI can surface is probably already known to attackers. Catanzaro considers that approach too harsh on maintainers, who could feel pressure to rush a fix. Immediate disclosure would suit GNOME poorly.
Projects that ban AI-generated reports
Some GNOME projects prohibit issue reports containing AI-generated content. For those projects, Catanzaro will stop forwarding security reports to their issue trackers, since most vulnerability reports now include AI-generated material and would break such a policy. He will close the report in the GNOME Security tracker and notify the project maintainers that it exists. He asks maintainers who want submissions to keep flowing to their own trackers to carve out an exception in their AI policy for vulnerability reports.
A permissions gap complicates this arrangement. GNOME maintainers lack access to confidential issues in the security tracker, and GitLab offers no way to CC individual developers on a confidential report. Catanzaro raises the idea of widening permissions so every GNOME developer can view the security tracker.
A handoff on the horizon
Catanzaro plans to step away from the role. He calls security tracking “largely a secretarial duty” that involves logging reports, closing them, disclosing them at the deadline, and requesting CVEs. The work has worn on him after more than five years. He will stop tracking newly reported issues on November 1, 2026, spend that month clearing reports filed earlier, and finish by December 1, once every remaining deadline has passed.
No one else currently tracks GNOME security issues. Catanzaro has offered to train an experienced community member willing to take it on, with a caveat that the job suits someone already familiar with the project. He also sees room to upgrade the tooling. The current setup runs on a wiki page that needs constant manual updates and can drift out of sync when a report closes. A web app that reflects the live state of each issue would replace it.