ソフトウェア品質の時代か、それともダチョウの時代か？

ソフトウェア品質の時代か、それともダチョウの時代か？ 2026年10月2日 Fedora, GNOME, セキュリティ 人間は安全なコードを書くのが苦手であり、GNOME開発者も例外ではありません。GNOMEは主に安全でないプログラミング言語で書かれており、コードの単純な間違いがユーザーに壊滅的な結果をもたらします。そして、私たちはこれらの間違いを常に犯しています。どれだけ努力しても、C、C++、またはValaのような安全でない言語を使用する場合、GNOME開発者は安全なコードを書くことができません。経験豊富な開発者にとっても、それを正しく行うのはあまりにも難しいからです。 上記の段落は、私のGUADEC 2024および2025の講演の要旨から取られたものです。当時、失敗は避けられないと考えていました。私たち人間はソフトウェアを書くのがあまりにも下手で、それを正しく行うチャンスはないと思っていました。そして、AIが人間よりも優れているとは決して信じていませんでした。 しかし、今日の状況は昨年とは全く異なります。AIは著しく進歩し、この問題に対する魔法の杖のような解決策を提供しています。私たちは今、言語モデルにソフトウェアの脆弱性を探すように依頼するだけでよいのです。彼らはこれに非常に長けています。2026年にAIの脆弱性スキャンなしで品質の高いソフトウェアを維持する希望はゼロです。それに反するいかなる主張も、真剣ではなく、妄想的です。 GLibやfwupdのような最もよく維持されているプロジェクトで見つかった膨大な量のバグが、それ自体を物語っているはずです。私たちのプロジェクトをスキャンしないことは、ユーザーにとって不当な不利益です。もし私たちがスキャンによって脆弱性を発見しなければ、攻撃者は間違いなく発見するでしょう。なぜなら、Linuxのユーザーベースは増加し、Linuxユーザーはターゲットにする価値があるほど十分に多数になったからです。一方、AIは、以前は考えられなかった、動作するエクスプロイトを構築することをこれまで以上に容易にしました。 すでに検出可能な脆弱性をすべて解決しましたか？それなら、AIにセキュリティ以外のバグも探すように依頼して、さらに品質を向上させましょう。GNOMEのコードは以前より全体的に良くなっていますが、改善の余地はまだ十分にあります。歴史上初めて、かつては現実的でなかったレベルまでソフトウェアの品質を向上させる機会を得ました。 ほとんどのAIバグレポートは「スロップ（不出来）」だと聞いたことがありますか？2026年ではありません。それは2025年のほとんどで真実でしたが、AI生成の脆弱性レポートの品質は劇的に向上しました。これは、悪い脆弱性レポートに関する問題がなくなったという意味ではありませんが、一般的に、今日ではそのほとんどがかなり良いものです。（Daniel Stenbergはcurlについても同様のパターンを報告しています。） それでも、AI生成の脆弱性レポートはGNOMEのメンテナーに多くの望ましくない影響をもたらしました。それらは通常、迷惑なほど冗長で、不必要に詳細です。それらはしばしば問題の深刻さを誇張したり、誤解を招く、または無関係な主張をしたりします。それらは時々不正確です。時には、偽のスタックトレースのような、完全に偽造されたデータ（これは標準ではありませんが、悲しいことに珍しくもありません）が含まれることもあります。 優れた人間のレビュアーは、上記のほとんどの問題に気づき、解決してから、あなたの問題追跡システムにバグレポートを作成しますが、多くの場合、問題は、何を見ているのかを実際には知らない経験の浅い人間によって報告され、すべてを盲目的にコピー＆ペーストするだけです。 生成された問題レポートが良いもので、上記のすべての問題を回避している場合（これはまれです）でさえ、十分な量の良い脆弱性レポートは、ボランティアのメンテナーを圧倒する可能性があります。そして、レポーターが問題を解決するためのマージリクエストを提出したとしても（これもまれです）、それらのマージリクエストをレビューすることは、過労のメンテナーにとってさらに歓迎されない作業です。 これらすべてが言いたいのは、現在のAI生成問題レポートの波によって引き起こされる苦痛は理解できるということです。それにもかかわらず、それらは不可欠であり、避けられません。私たちは、頭を砂に突っ込んで無視するのではなく、それらを受け入れて対処する方法を学ばなければなりません。 一部のGNOMEメンテナーは、問題レポートでAI生成コンテンツを禁止するポリシーを採用しています。そうしないでください。今日では、脆弱性レポートの圧倒的多数がAIによって生成されています。問題レポートでAI生成コンテンツを禁止するプロジェクトは、すべての脆弱性レポートを禁止するのと同じくらい効果があるでしょう。私は次のように提案します。GNOMEメンテナーは、4か月前に私が以前要求したように、AI生成の脆弱性レポートを許可するようにAI貢献ポリシーを書き直すべきです。AI生成の脆弱性レポートを引き続き禁止するプロジェクトは、もはやGNOMEの依存関係として適しておらず、GNOME GitLab以外の場所で開発されるべきです。悪い問題レポートを容認する必要はありませんが、AIの使用だけが失格となるべきではありません。 人間がAI生成のバグレポートを書き直すべきではないか？ メンテナーはAI生成の脆弱性レポートを許可すべきだと私が主張するとき、最も一般的な反論は、人間がAIのレポートを読み、理解し、AI生成コンテンツをすべて削除するために全体を書き直すべきだということです。一部のバグレポーターは実際に自発的にこれを行いますが、これはまれです。 脆弱性報告は公共サービスであり、義務ではありません。レポーターに余分な作業を依頼した場合、彼らはそうするかもしれませんが、あなたのプロジェクトを見るのをやめて他のことに移るか、あなたのプロジェクトを見続け、問題追跡システム以外の場所に脆弱性レポートを公開する可能性の方がはるかに高いです。 問題レポートの書き直しもスケーリングしません。GNOMEプロジェクトで100件のセキュリティバグを見つけるためにAIを使用すると仮定します。これは実際のスキャンの結果と一致する数です（読み進めてください）。提出する前に、それらのバグレポートを数か月かけて書き直しますか？AIの主張を検証し、問題レポートをアップストリームし、マージリクエストを提出することは、すでに多くの作業です。多くの人が、すべての問題レポートをさらに書き直すことを望むでしょう。それは他のすべてを合わせたよりも多くの作業であり、非現実的です。 たとえバグが少数であっても、他のタスクに時間を費やしたいので、問題レポートを書き直すのに多くの時間を費やすことをためらうでしょう。せいぜい、簡単な要約を用意するかもしれませんが、完全なレポートほど役立ちません。 CVEの波がGNOMEを襲う GNOMEのCVE発行トレンドに、現在の脆弱性レポートの波が反映されています。 年 | GNOME CVE数 | GIMP, Gegl, libxml2, libxslt2を除くGNOME CVE数 ---|---|--- 2021 | 21 | 14 2022 | 14 | 6 2023 | 13 | 4 2024 | 37 | 28 2025 | 97 | 49 2026 (年初来 9/30まで) | 141 | 74 ここでの傾向はかなり明確であるはずです。最近まで、GNOMEに脆弱性を報告する人はあまりいませんでした。それは変わりました。現在、3年前と比較して1桁多いCVEを扱っています。AIだけがこの増加の原因ではありません。GNOMEメンテナーも、私がセキュリティ追跡に追加できるように問題をフラグ付けするのが少し上手になりました。しかし、AIがこの増加の主な原因です。 （この表に関するいくつかの技術的な注記。CVEはCVE識別子の年ではなく、GNOMEに報告された年の分類です。例えば、多くのCVE-2026は2025年にカウントされます。CVEがまだない2026年に報告された脆弱性はカウントされないため、データはおおよそ9月1日まで正確であると考えてください。2026年の数に4/3を掛けて、前の年と比較できるようにします。GNOMEセキュリティに報告された問題のみをカウントするため、報告されていないCVEはカウントされません。） 2026年はまだ3か月残っていますが、年末までのデータは決して得られません。なぜなら、私が新しい問題レポートのセキュリティ追跡を終了し、他に誰もその作業を引き受けてくれなかったからです。これらのCVEは私が自分で要求したためのみ存在するため、CVEの数は今後劇的に減少すると予想されます。 CVEの波がWebKitGTKを襲う 同様のパターンがWebKitGTKにも当てはまります。 年 | WebKitGTK CVE数 ---|--- 2015 | 17 2016 | 5 2017 | 7 | 1 2018 | 10 | 1 2019 | 9 | 9 2020 | 38 2021 | 52 2022 | 50 2023 | 45 2024 | 38 2025 | 66 2026 (WSA-2026-0006まで) | 30 CVEは、WebKitGTKセキュリティアドバイザリに掲載された年に基づいて報告されます。その年ではありません。