软件质量的时代，还是鸵鸟的时代？

# 软件质量的时代，还是鸵鸟的时代？ 来源：https://blogs.gnome.org/mcatanzaro/2026/10/02/the-era-of-software-quality-or-the-era-of-ostriches/ 人类写不出安全的代码，GNOME 开发者也不例外。GNOME 主要用不安全的编程语言编写，我们在代码中的简单错误会给用户带来毁灭性的后果（https://wingolog.org/archives/2011/10/13/whats-your-c-migration-plan），而我们一直在犯这些错误（https://blogs.gnome.org/mcatanzaro/2022/07/27/common-glib-programming-errors/）。无论我们多么努力，只要还在使用 C、C++ 或 Vala 这类不安全的语言，GNOME 开发者就注定写不出安全的代码：即使是经验丰富的开发者，把这件事做好也实在太难了。 上面这段话摘自我在 GUADEC 2024 和 2025 年演讲中的摘要。当时我以为失败是不可避免的：我们人类写软件的能力太差，根本没有机会把它做好，而且我当然也不会相信 AI 能比人做得更好。但今天的情况与去年已截然不同。AI 有了长足的进步，为这个问题提供了一根魔法棒：我们现在可以直接让大语言模型去检查我们软件中的漏洞。它们做这件事相当不错。（https://github.com/fwupd/fwupd/releases/tag/2.0.21） **在 2026 年，如果不借助 AI 漏洞扫描，想维护高质量的软件是毫无希望的。**任何相反的说法都是不严肃、甚至自欺欺人的。我们维护得最好的项目——比如 GLib 和 fwupd——所发现的海量 bug 本身就说明了一切。不扫描我们的项目，是对用户不负责任。如果我们自己不扫描项目来发现漏洞，攻击者一定会找到它们，因为 Linux 的用户群已经增长到足以成为值得攻击的目标。与此同时，AI 让构建可运行的 exploit 变得比以往任何时候都容易（https://blogs.gnome.org/mcatanzaro/2026/05/21/single-click-code-execution-exploit-for-evince-atril-and-xreader/），而这在以前是闻所未闻的。 已经修复了所有可检测的漏洞？那就再让 AI 找找非安全类的 bug，进一步提升质量吧。GNOME 的代码总体上比过去好得多了，但仍有很大的改进空间。我们有史以来第一次，有机会把软件质量提升到以前根本不现实的程度。 你听说过吗？说大多数 AI 生成的 bug 报告都是“垃圾”。在 2026 年已经不是这样了。在整个 2025 年，这大体属实，但如今 AI 生成的漏洞报告质量已经有了极大提升。这并不是说我们完全不用再为糟糕的漏洞报告发愁了，但总体而言，现在大多数报告都相当不错。（Daniel Stenberg 在 curl 上也观察到了同样的趋势。（https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/）） 不过，AI 生成的漏洞报告还是给 GNOME 维护者带来了不少负面影响。这些报告通常啰嗦得恼人，细节又多得毫无必要。它们经常夸大问题的严重程度，或者做出误导性或无关的陈述，偶尔还会出错。有时它们甚至包含纯属捏造的数据，比如伪造的栈回溯（https://gitlab.gnome.org/GNOME/gegl/-/issues/477#note_2881273）（这并不是常态，但可惜也并不少见）。一位优秀的人类审查者会在你的 issue 追踪器上提交 bug 报告之前发现并解决上述大多数问题，但报告问题的人往往是没有经验的，他们并不真正明白自己在看什么，只是盲目地复制粘贴一切。即使生成的 issue 报告质量不错、避开了上述所有问题（这很罕见），数量足够的高质量漏洞报告仍然会压垮志愿维护者。而且，即使报告者主动提交合并请求来解决问题、免去维护者动手（这同样罕见），审查这些合并请求本身对已经不堪重负的维护者来说也是额外的、不受欢迎的工作。 总之：我理解当前这波 AI 生成的 issue 报告所带来的痛苦。然而，它们是必不可少、无法回避的。我们必须学会接受并应对它们，而不是把头埋进沙子里视而不见。 一些 GNOME 维护者采用了禁止 issue 报告中使用 AI 生成内容的政策。不要这样做。如今，绝大多数漏洞报告都是 AI 生成的。选择在 issue 报告中禁止 AI 生成内容的项目，不如干脆禁止所有漏洞报告；效果几乎是一样的。 我提出如下建议： - GNOME 维护者应当重写他们的 AI 贡献政策，允许 AI 生成的漏洞报告，正如我四个月前所要求的那样（https://blogs.gnome.org/mcatanzaro/2026/06/08/please-do-not-ban-ai-assisted-issue-reports/）。 - 继续禁止 AI 生成漏洞报告的项目，不再适合成为 GNOME 的依赖，它们应该在 GNOME GitLab 之外的别处进行开发。 我们不必容忍*糟糕的* issue 报告，但仅凭使用了 AI 就不应该将其拒之门外。 ## 不该由人类重写 AI 生成的 bug 报告吗？ 每当我抱怨维护者应该允许 AI 生成的漏洞报告时，最常见的反驳是：人类应该阅读 AI 的报告、理解它，然后把整篇重写一遍，以清除所有 AI 生成的内容。一些 bug 报告者确实会自愿这样做，但这很罕见。 漏洞报告是一种公共服务，不是义务。如果你要求报告者做任何额外的工作，他们或许会愿意，但他们更可能的选择是：要么不再关注你的项目、转而去别的项目，要么继续关注你的项目，但把漏洞报告发布到你的 issue 追踪器以外的其他地方。 重写 issue 报告也无法规模化。假设你用 AI 在一个 GNOME 项目中发现了 100 个安全 bug——这个数字与实际扫描的结果是一致的（见下文）。你真的会花上几个月时间重写这些 bug 报告，然后才提交给上游吗？验证 AI 的说法、将 issue 报告提交给上游、提交合并请求，这本身就已经是很大的工作量了。没有多少人会愿意在此之上再把所有 issue 报告全部重写一遍。那工作量比前面所有事情加起来还要多，根本不现实。 即使 bug 数量不多，我也会犹豫要不要花大量时间重写一篇 issue 报告，因为我还有许多其他任务更值得我投入时间。充其量，我可能会准备一份简短的摘要，但它不会像完整报告那样有用。 ## CVE 风暴席卷 GNOME 当前这波漏洞报告也反映在 GNOME 的 CVE 颁发趋势中： | 年份 | GNOME CVE | 排除 GIMP、Gegl、libxml2 和 libxslt 后的 GNOME CVE | | --- | --- | --- | | 2021 | 21 | 14 | | 2022 | 14 | 6 | | 2023 | 13 | 4 | | 2024 | 37 | 28 | | 2025 | 97 | 49 | | 2026 年截至今日（2026-09-30） | 141 | 74 | | 2026 年换算全年 | 188（141 × 4 / 3） | 99（74 × 4 / 3） | 这里的趋势应该已经相当清楚了。在不久之前，向 GNOME 报告漏洞的人并不多。现在情况变了。我们目前处理的 CVE 数量比仅仅 3 年前多出了一个数量级。AI 并非*唯一*原因；GNOME 维护者也*稍微*更善于标记问题了，这样我就能把它们纳入安全追踪。但 AI 是导致这一增长的主要原因。 （关于这张表的几点技术说明。CVE 是按照问题被报告给 GNOME 的年份来归类的，而不是按照 CVE 编号中的年份，因此例如许多 CVE-2026 的条目被计入了 2025 年。2026 年报告的、尚未获得 CVE 的漏洞不计入统计，所以你可以认为这些数据大致准确到 9 月 1 日左右；把 2026 年的数字乘以 4/3，就可以与之前的年份进行比较。我只统计报告到 GNOME Security（https://gitlab.gnome.org/Teams/Releng/security/-/wikis/home）的问题，所以任何未报告的 CVE 都不计入。） 虽然 2026 年还剩下 3 个月，但我们不会再有全年数据了，因为我已经停止了对新 issue 报告的安全追踪（https://blogs.gnome.org/mcatanzaro/2026/10/02/how-to-request-a-cve/），也没有其他人自愿接手这项工作。这些 CVE 之所以存在，完全是因为由我亲自去申请，所以我预计今后 CVE 的数量会大幅下降。 ## CVE 风暴席卷 WebKitGTK WebKitGTK 也呈现出类似的模式： | 年份 | WebKitGTK CVE | | --- | --- | | 2015 | 175 | | 2016 | 57 | | 2017 | 158 | | 2018 | 101 | | 2019 | 99 | | 2020 | 38 | | 2021 | 52 | | 2022 | 50 | | 2023 | 45 | | 2024 | 38 | | 2025 | 66 | | 2026 年截至 WSA-2026-0006（https://webkitgtk.org/security/WSA-2026-0006.html） | 305 | CVE 是按照漏洞出现在 WebKitGTK 安全公告中的年份来报告的，而不是按照 CVE ID 中的年份。2026 年的大幅增长完全归因于对 Skia 和 ANGLE 的 AI 分析。WebKit 打包了这些库，因为它们并非设计为安装为系统库，因此它们的漏洞应当与 WebKit 自身代码中的漏洞同等对待。如果不计 Skia 和 ANGLE，今年迄今为止实际上只有 21 个其他的 WebKitGTK CVE，这是一个显著的下降，但把打包代码中的 CVE 排除在外并不公平。 实际上今年 WebKit 的安全修复数量有了大幅增加，但这并没有导致 CVE 数量增加。Apple 通常只为外部研究者发现的漏洞创建 CVE，而较少为 WebKit 开发者自己发现的漏洞创建 CVE，因此安全修复数量的增加并没有反映在 CVE 总数上。只有很小一部分 WebKit 漏洞会获得 CVE。 我此前没有注意到，WebKitGTK 的 CVE 数量在 2026 年之前，过去十年间一直在下降。我不确定这是为什么。我也不知道该如何解释 2016 年数量之低。 ## 宣布 GNOME 漏洞赏金计划，以及宣布 GNOME 漏洞赏金计划的结束 我的博客待办事项清单上写着，我需要写一篇博客，宣布在 YesWeHack 平台上创建 GNOME 漏洞赏金计划（https://yeswehack.com/business-units/sovereign-tech-fund/programs/gnome-bug-bounty-program/details）。哎呀，太迟了。它已经关闭了。（一旦一件事进入我的待办清单，可能要过*非常*久我才腾出时间去做。） GNOME 漏洞赏金计划由德国 Sovereign Tech Agency 的 Sovereign Tech Resilience 计划慷慨资助。我不确定它确切的开启时间，但第一个漏洞是在 2024 年 6 月 27 日报告的，所以它应该在那之前不久开启。我们只接受针对 GLib、glib-networking 和 libsoup 的 issue 报告，因为 GNOME 从未运营过漏洞赏金计划，我们也不知道会发生什么。从小处着手——事后看来这很天真——似乎是避免收到大量 issue 报告的审慎做法。我曾想把这个计划扩大到覆盖整个 GNOME，但由于针对 GLib 和 libsoup 报告的问题数量实在压倒性，这一尝试失败了。 我要求结束这个漏洞赏金计划，因为涌入的 AI 生成 issue 报告让我应接不暇。最后一个 issue 是在 2026 年 2 月 23 日报告的。以下是结果： | 年份 | 提交的报告 | 被接受的报告 | | --- | --- | --- | | 2024 | 26 | 14 | | 2025 | 150 | 33 | | 2026 | 122 | 24 | | **总计** | **298** | **71** | 2026 年的数字反映的只是不到两个月的 issue 报告量，所以你能明白为什么这个计划已无法持续。 计划关闭之后，我们的工作并没有结束：还有一长串积压的报告需要处理。就在上个月，我们才刚刚处理完接受 2 月份所报告的最后一批 issue，而最后一笔赏金就在今天早些时候终于发放出去了！即使有 YesWeHack 专业的分类人员在我审查之前先行分析 issue 报告，要跟上如此大量的漏洞对我而言也并不轻松。 到目前为止，所有未被接受的报告都已被拒绝。该计划共为 71 个漏洞发放了 183,900 欧元的赏金：libsoup 45 个，GLib 23 个，glib-networking 3 个。单笔赏金金额从 500 欧元（16 笔）到 7,500 欧元（2 笔）不等。算术平均赏金为 2,662.99 欧元。 漏洞赏金计划是“大多数 AI 生成的漏洞报告质量不错”这一规律的例外。你可以看到被接受的报告数量只占提交数量的一小部分。排除 30 份被判定为重复的报告，还剩下 197 份被拒绝的报告。事实证明，在有经济激励的情况下，人们会提交糟糕的报告。低得可怜的接受率甚至低估了问题的严重性，因为许多*被接受的*报告实际上质量也不高！许多被接受的报告确实成功识别出了有效的安全问题（事实上，许多*被拒绝的*报告也成功识别出了有效的安全问题！），但它们需要多轮修改和纠正。 长话短说，我审查过*大量*极其糟糕的 AI 生成漏洞报告。但我们通过已停止的漏洞赏金计划收到的报告，与通过常规 GNOME issue 追踪器和安全漏洞报告表单（https://security.gnome.org/）收到的报告是不可同日而语的。我们偶尔仍会收到质量不高的漏洞报告，但并不频繁、数量也不多，所以这已不再是个大问题。当人们提交 AI 生成的报告而*不指望*获得经济回报时，这些报告总体上要好得多。 ## 漏洞赏金计划的教训 因为发现了太多漏洞而关闭漏洞赏金计划，并不是什么令人愉快的结果。话虽如此，它仍算是一次部分的成功，因为它在 libsoup 和 GLib 中挖掘出了大量 bug。 我曾推测 libsoup 可能并不十分安全，但我从未料到会发现如此多的漏洞。为了减少涌入的 issue 数量，并更好地反映对 GNOME 用户的实际风险，我最终把所有拒绝服务类 bug 移出了计划范围，后来又把 SoupServer 移出了范围，原因是请求走私漏洞（https://portswigger.net/research/http1-must-die）太多——这些是 HTTP 请求解析类 bug，对 GNOME 用户并不构成威胁。即便做了这些调整，针对 libsoup 的漏洞报告仍源源不断地到来，直到我放弃为止。令人欣慰的是，libsoup 现在比以前安全得多。其他漏洞报告者仍在通过常规的 libsoup issue 追踪器提交 AI 生成的 bug 报告，因此幸运的是，尽管经济奖励已经终止，libsoup 的改进仍会继续下去。 我曾推测 GLib 会比 libsoup 好得多。我不确定自己是否正确。评估 GLib 缺陷的严重性要比 libsoup 困难得多，因为 GLib 的漏洞报告总体上是假设性的：通常是一个概念验证程序以合法但不太可能出现的值调用某个 GLib API，然后发生了不好的事情。 GLib 的 bug 中有很大一部分是整数溢出缺陷，它们通常会导致缓冲区溢出。现在我对整数溢出比对任何其他问题都更感到恐惧。很可能大多数软件项目都存在许多整数溢出问题。幸运的是，我们应该可以通过调整所使用的编译器选项来捕获大多数此类问题。特别是 `-Wconversion` 或 `-Wint-conversion`，以及 `-Wsign-compare`，应该会有所帮助。一些 GNOME 项目已经在使用 `-Wsign-compare`，但我怀疑大多数并没有。我认为很少或没有 GNOME 项目在使用 `-Wconversion` 或 `-Wint-conversion`。 只有在截然不同的条件下，漏洞赏金计划才有可能重启。我们之前所做的行不通。若要重启，我们需要把范围限定在那些定期自行进行 AI 漏洞扫描的项目上。我们很可能也只愿意为功能性