--- title: The Era of Software Quality, or the Era of Ostriches? description: GNOME security maintainer Michael Catanzaro argues that AI-powered vulnerability scanning has become essential for software quality, citing a massive surge in... canonical: https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Era of Software Quality, or the Era of Ostriches? | daily.dev og:description: GNOME security maintainer Michael Catanzaro argues that AI-powered vulnerability scanning has become essential for software quality, citing a massive surge in... og:url: https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav og:image: https://api.daily.dev/og/posts/Cey5ZiXav.png og:image:alt: The Era of Software Quality, or the Era of Ostriches? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Era of Software Quality, or the Era of Ostriches? **[Lobsters](https://daily.dev/sources/lobsters)** · 19 min read · 1 upvotes · 0 comments ## Summary GNOME security maintainer Michael Catanzaro argues that AI-powered vulnerability scanning has become essential for software quality, citing a massive surge in GNOME CVEs (from 13 in 2023 to a projected 188 in 2026, normalized) and WebKitGTK security fixes driven largely by AI analysis. He details the results of GNOME's now-closed bug bounty program (298 reports submitted, 71 accepted, €183,900 awarded across libsoup, GLib, and glib-networking), a Red Hat-sponsored AI scan of GLib finding 118 potential vulnerabilities (with a 40% false-positive rate due to misclassified gobject-introspection bugs), and a Codean Labs security audit that found critical Flatpak sandbox escapes AI likely couldn't have caught alone. He proposes GNOME projects should be required to accept AI-generated vulnerability reports, pushes back on demands that reporters rewrite AI-generated issues by hand, cautions against using Rust for new GNOME software due to Cargo supply-chain risk despite its memory-safety benefits, and sets informal guidelines discouraging AI-written code comments, commit messages, and impersonated human responses. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How many CVEs has GNOME received in 2026 compared to previous years? GNOME has logged 141 CVEs year-to-date through September 30, 2026 (normalized to about 188 for the full year), up from 97 in 2025, 37 in 2024, and just 13-21 per year from 2021-2023. Excluding GIMP, Gegl, libxml2, and libxslt, the 2026 figure is 74 (normalized to 99), still roughly double 2025's 49. The maintainer attributes the surge primarily to AI-assisted vulnerability scanning rather than codebases becoming less secure. _Maintainers tracking how AI scanning is reshaping CVE volume can follow this kind of analysis on daily.dev._ ### What were the results of the GNOME bug bounty program run through YesWeHack? The GNOME bug bounty program, sponsored by Germany's Sovereign Tech Agency and scoped to GLib, glib-networking, and libsoup, ran from mid-2024 until February 23, 2026, receiving 298 total reports and accepting 71, paying out €183,900 in bounties (45 in libsoup, 23 in GLib, 3 in glib-networking). Awards ranged from €500 to €7,500, with an average of €2,662.99. It was shut down because AI-driven submission volume became unsustainable for volunteer maintainers to triage. _Teams weighing whether a bug bounty program fits an open-source project can track real outcomes like this on daily.dev._ ### Why does GLib have so many integer overflow vulnerabilities and how can they be prevented? A large portion of GLib's reported bugs were integer overflow flaws that generally lead to buffer overflows, discovered because GLib exposes so many public APIs that accept potentially untrusted data, widening the attack surface. The recommended mitigation is enabling compiler flags such as -Wconversion, -Wint-conversion, and -Wsign-compare, which most GNOME projects currently do not use, to catch these issues at compile time. _Developers hardening C codebases against integer overflow bugs can find practical fixes like these on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 34 comments across lobsters, hackernews (as of 2026-10-03). **TL;DR:** Commenters largely argue with the post's call to avoid Rust over Cargo supply-chain risk, with many pushing back that the reasoning conflates package managers with uncontrolled dependencies, while a separate thread debates whether AI-driven vulnerability scanning is genuinely valuable or just hype masking deeper industry neglect of security and maintainer burnout. **Sentiment:** 20% positive · 45% mixed · 35% skeptical **The case for** - Some note LLM security scanning is remarkably effective despite lacking formal methods or structured approaches, which is a welcome surprise. - One commenter found genuine, useful bugs (XSS, DoS path) from an LLM scan on their own project. - Raising the 'zero-effort floor' for security scanning is seen as valuable even if it doesn't reach expert-level ceilings. **The pushback** - Many argue recommending against Rust due to Cargo risk is flawed since Rust has no inherent coupling to Cargo and dependencies can be vendored/pinned. - Some say the real issue is number of unique packages/authors in the supply chain, not lines of code, making the Rust-vs-C framing miss the point. - Several are skeptical that LLM scanning reflects real pentesting quality, suggesting it's more a sign the industry neglected security and that AI companies are inflating perceived results. - Maintainers worry AI-generated issues/PRs remove the human signals previously used to judge contributor effort, risking burnout and empathy fatigue. - One pushes back hard that avoiding memory-unsafe languages while touting AI scanning is a bad-faith argument to promote LLM usage. **By community** - lobsters (heated): Extensive, contentious back-and-forth mostly centered on whether the Rust/Cargo supply-chain argument holds up, plus a secondary heated debate over whether AI vulnerability scanning represents real progress or industry complacency dressed up as innovation. - hackernews (mixed): No substantive comments were provided, so no clear lean can be determined. **Hottest debate:** Whether avoiding Rust for GNOME software due to Cargo's supply-chain risk is a sound tradeoff or a flawed argument that conflates the language with its package manager ecosystem. **Open questions** - Why would GNOME's own Rust libraries be compromised via Cargo if dependencies are pinned or vendored? - Do LLM-found bugs overlap with what fuzzing or deterministic simulation testing would already catch, or are the result sets disjoint? - How should maintainers distinguish genuine, careful AI-assisted contributions from low-effort automated PR spam? **Highlights** > > Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. > Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software. In my opinion the response should be to pin versions of the dependencies or fork and maintain them in the GNOME project, rather than avoiding a programming language the author claims reduces vulnerabilities by an order of magnitude. > — [pyfisch on lobsters · 1 points, 4 comments](https://lobste.rs/s/elziso/era_software_quality_era_ostriches#c_e6egpa) > Vala compiles to C. It's got memory management constructs, but they aren't checked like in Rust. ``` void main () { unowned string x; // this is the equivalent of a reference with a lifetime from outside the function... { string y = "heap-allocated".up (); x = y; // ... but this just generates a pointer copy } print ("%s\n", x); // use after free } ``` More trivially, arrays are just not bounds-checked: ``` void main () { int[] a = { 1, 2, 3 }; a[4] = 0; // buffer overflow } ``` > — [gulbanana on lobsters · 5 points, 1 comments](https://lobste.rs/s/elziso/era_software_quality_era_ostriches#c_vgwd49) > Rust has no inherent coupling to Cargo. Rust codebases can be built with make, cmake, or any other build system by directly invoking rustc in the same manner one would directly invoke gcc. For Rust projects whose build system is Cargo, the `cargo vendor` subcommand conveniently produces a vendored tree of dependencies amenable to version control. > — [ghoti on lobsters · 3 points, 1 comments](https://lobste.rs/s/elziso/era_software_quality_era_ostriches#c_cpmp4o) > I’m trying to contribute to clippy now and the situation looks bleak for maintainers. Previously the signal was: could make a PR. Things like docs and tests were "wow this person is good" and a description that linked to the issue it closes and actually explained that it did was a 10/10. Mantainers have always relied on signals to determine where to invest their limited time. When they do invest it, it was clear their empathy is met and reciprocated. Now those signals are gone and there's not a good way to distinguish between "I spent days and hours meticulously promoting fans getting reviews and iterating combined with my own human iteration" and "told Claude to get me internet points to boost my resume in a Ralph loop". There's not even a guarantee the person on the other side is in fact a person. The rust/clippy policy is very thoughtful and clearly spells out how to use LLMs with empathy for the eventual maintainer/reviewer. I ran afoul of it by some degrees and even though I'm in the "meticulous code" camp of LLM users cannot genuinely say code produced by the machine isn't in the final product. I can though, and will. So closed it and will rewrite it. I think LLM scanning is good. But LLM issues and PRs are not. We need a human who has the skills and empathy for reviewers to make it easy enough for them. The challenge has never been the work, the challenge has always been doing the work in a way that is reviewable, maintainable, and sustainable. We need to find community standards and guidelines to reflect that reality. > — [schneems on lobsters · 1 points, 2 comments](https://lobste.rs/s/elziso/era_software_quality_era_ostriches#c_fsordf) > That LLMs have been finding bugs is more so an effect of the tech industry not taking security seriously than them being amazing at it. It also doesn't hurt that GenAI companies are pumping millions into making their models look as amazing as possible. If you hire a team of pentesters for a few million bucks, I'm sure you'll get way more (both quality and quantity) than whatever the LLMs regurgitated. If planet-burning slop machines are what it takes for the tech industry to start taking security seriously... heh. Though, that being said, throwing slop-machines at it doesn't mean they're taking it seriously, so I don't even think it had that effect. Either way, all we can do is object to this extremely unethical technology. > — [lumi on lobsters · 1 points, 1 comments](https://lobste.rs/s/elziso/era_software_quality_era_ostriches#c_wgp0iq) **Source threads** - [lobsters](https://lobste.rs/s/elziso/era_software_quality_era_ostriches) · 22 points · 34 comments - [hackernews](https://news.ycombinator.com/item?id=49944392) · 3 points · 0 comments ## Similar posts on daily.dev - [Did AI Just Break Software Security For Ever?](https://daily.dev/posts/did-ai-just-break-software-security-for-ever--6pxwdikky) · Foojay.io · 0 upvotes · 0 comments - [Significant raise of reports \[LWN.net\]](https://daily.dev/posts/significant-raise-of-reports-lwn-net--7wcsc3kk2) · Hacker News · 0 upvotes · 0 comments - [AI gets good at finding bugs, not as good at fixing them](https://daily.dev/posts/ai-gets-good-at-finding-bugs-not-as-good-at-fixing-them-sptd5ofrp) · The Register · 0 upvotes · 0 comments - [Just a rumour of a bug is enough to find a security exploit these days](https://daily.dev/posts/just-a-rumour-of-a-bug-is-enough-to-find-a-security-exploit-these-days-wzfcjbyf0) · Lobsters · 1 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#linux](https://daily.dev/tags/linux), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Era of Software Quality, or the Era of Ostriches?","url":"https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav"},"datePublished":"2026-10-03T17:24:54.007Z","dateModified":"2026-10-03T22:41:09.177Z","description":"GNOME security maintainer Michael Catanzaro argues that AI-powered vulnerability scanning has become essential for software quality, citing a massive surge in...","image":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","thumbnailUrl":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,linux,rust","timeRequired":"PT19M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"The Era of Software Quality, or the Era of Ostriches?"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-era-of-software-quality-or-the-era-of-ostriches--cey5zixav#faq","mainEntity":[{"@type":"Question","name":"How many CVEs has GNOME received in 2026 compared to previous years?","acceptedAnswer":{"@type":"Answer","text":"GNOME has logged 141 CVEs year-to-date through September 30, 2026 (normalized to about 188 for the full year), up from 97 in 2025, 37 in 2024, and just 13-21 per year from 2021-2023. Excluding GIMP, Gegl, libxml2, and libxslt, the 2026 figure is 74 (normalized to 99), still roughly double 2025's 49. The maintainer attributes the surge primarily to AI-assisted vulnerability scanning rather than codebases becoming less secure. Maintainers tracking how AI scanning is reshaping CVE volume can follow this kind of analysis on daily.dev."}},{"@type":"Question","name":"What were the results of the GNOME bug bounty program run through YesWeHack?","acceptedAnswer":{"@type":"Answer","text":"The GNOME bug bounty program, sponsored by Germany's Sovereign Tech Agency and scoped to GLib, glib-networking, and libsoup, ran from mid-2024 until February 23, 2026, receiving 298 total reports and accepting 71, paying out €183,900 in bounties (45 in libsoup, 23 in GLib, 3 in glib-networking). Awards ranged from €500 to €7,500, with an average of €2,662.99. It was shut down because AI-driven submission volume became unsustainable for volunteer maintainers to triage. Teams weighing whether a bug bounty program fits an open-source project can track real outcomes like this on daily.dev."}},{"@type":"Question","name":"Why does GLib have so many integer overflow vulnerabilities and how can they be prevented?","acceptedAnswer":{"@type":"Answer","text":"A large portion of GLib's reported bugs were integer overflow flaws that generally lead to buffer overflows, discovered because GLib exposes so many public APIs that accept potentially untrusted data, widening the attack surface. The recommended mitigation is enabling compiler flags such as -Wconversion, -Wint-conversion, and -Wsign-compare, which most GNOME projects currently do not use, to catch these issues at compile time. Developers hardening C codebases against integer overflow bugs can find practical fixes like these on daily.dev."}}]} ```