A GNOME developer is urging open-source projects to accept carefully reviewed AI-assisted vulnerability reports rather than prohibiting them outright, arguing that automated scanning has become an important source of security findings even as low-quality submissions create extra work for maintainers.
Michael Catanzaro, writing on the GNOME project blog, said language models are increasingly capable of finding flaws in software written in memory-unsafe languages such as C, C++ and Vala. GNOME relies heavily on those languages, where programming mistakes can cause security consequences. He argued that projects should use AI scanning themselves because attackers can use similar tools to locate and exploit weaknesses.
The post is an opinion from one developer, not a formal GNOME-wide policy or a controlled measurement of model accuracy. Catanzaro nevertheless based his argument on direct experience with a growing stream of vulnerability reports affecting projects including GLib and fwupd. He said GNOME is handling roughly an order of magnitude more CVEs than three years earlier, with AI-assisted discovery the primary reason in his assessment, though improved internal tracking also contributed.
More findings do not automatically mean better reports. Catanzaro listed recurring problems: submissions can be excessively long, overstate severity, include irrelevant claims, contain errors or even fabricate diagnostic details such as stack traces. Inexperienced reporters may paste model output without understanding or testing it. Even accurate reports can burden volunteer teams when maintainers must reproduce the issue, assess its impact, coordinate disclosure, review a patch and track a security advisory.
Some maintainers have responded by banning AI-generated material in issue trackers. Catanzaro argued that this rejects too much useful work because most vulnerability reports reaching GNOME are now AI-generated. His preferred distinction is based on report quality rather than which tool helped produce it. Invalid or careless submissions can still be closed, while a verified finding should not be disqualified merely because a model assisted in finding or documenting it.
He also rejected a requirement that reporters rewrite every AI-assisted finding from scratch. In a scan that produces scores of potential bugs, full rewrites would take longer than validation and upstream coordination, discouraging people from reporting at all. A reporter might instead publish elsewhere, leaving the affected project with less opportunity to investigate before disclosure.
The proposal leaves a practical governance challenge. Projects need intake rules that demand reproducible evidence, clear impact claims and human verification without turning provenance into the only acceptance test. They may also need limits or batching mechanisms so maintainers are not flooded with simultaneous reports.
AI security scanning can expand review capacity, but it also shifts work downstream when results are poorly checked. Catanzaro's case is therefore not that model output should be trusted automatically. It is that open-source communities should build processes for validating and prioritizing it, treating reliable evidence as useful while rejecting hallucinated or unsupported claims.
