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

ソフトウェア品質の時代か、それともダチョウの時代か？ 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生成の脆弱性レポートを引き続き禁止するプロジェクトは、GNOMEの依存関係として適切ではなくなり、GNOME GitLab以外の場所で開発されるべきです。私たちは悪いバグレポートを容認する必要はありませんが、AIの使用だけでは失格となるべきではありません。 人間はAI生成のバグレポートを書き直すべきではないか？ メンテナーはAI生成の脆弱性レポートを許可すべきだと私が文句を言うとき、最も一般的な反論は、人間がAIのレポートを読み、理解し、AI生成コンテンツをすべて削除するために全体を書き直すべきだということです。一部のバグレポーターは実際に自発的にこれを行いますが、これはまれです。脆弱性報告は公共サービスであり、義務ではありません。レポーターに追加の作業を依頼した場合、彼らはそれを行う意思があるかもしれませんが、彼らはプロジェクトを見るのをやめて他のことに移るか、プロジェクトを見続け、バグトラッカー以外の場所に脆弱性レポートを公開する可能性の方がはるかに高いです。 バグレポートの書き直しもスケールしません。GNOMEプロジェクトで100件のセキュリティバグを見つけるためにAIを使用すると仮定します。これは実際のスキャンの結果と一致する数です（読み進めてください）。提出する前に、それらのバグレポートを数か月かけて書き直しますか？AIの主張を検証し、バグレポートをアップストリームに提出し、マージリクエストを提出することは、すでに多くの作業です。多くの人が、さらにすべてのバグレポートを書き直す意思があるわけではありません。それは他のすべてを合わせた以上の作業であり、非現実的です。たとえ少数のバグであっても、私はバグレポートを書き直すのに多くの時間を費やすことをためらうでしょう。なぜなら、私は他に時間を費やしたいタスクがたくさんあるからです。最悪の場合、簡単な要約を作成するかもしれませんが、完全なレポートほど有用ではありません。 CVEの波がGNOMEを襲う 現在の脆弱性レポートの波は、GNOMEのCVE発行トレンドに反映されています。 年 | GNOME CVE数 | GIMP, Gegl, libxml2, libxsltを除くGNOME CVE数 ---|---|--- 2021 | 21 | 14 2022 | 146 | 20 2023 | 134 | 20 2024 | 372 | 8 2025 | 97 | 49 2026 (年初来 9月30日まで) | 141 | 74 2026 (正規化) | 188 (141 * 4/3) | 99 (74 * 4/3) ここでの傾向はかなり明確であるはずです。最近まで、GNOMEで脆弱性を報告する人は多くありませんでした。それは変わりました。私たちは現在、わずか3年前の10倍の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 | 57 2017 | 158 2018 | 10 2019 | 99 2020 | 38 2021 | 52 2022 | 50 2023 | 45 2024 | 38 2025 | 66 2026 (WSA-2026-0006まで) | 305 CVEは、WebKitGTKセキュリティアドバイザリに掲載された年に基づいて報告されます。年ではなく...