GNOMEの開発者が、オープンソースプロジェクトに対し、AIの支援を受けた脆弱性報告を全面的に禁止するのではなく、入念にレビューされたものを受け入れるよう促している。質の低い投稿がメンテナーの負担を増やす一方、自動スキャンはセキュリティ上の問題を見つける重要な手段になっていると論じる。

マイケル・カタンザロ氏はGNOMEプロジェクトのブログで、言語モデルはC、C++、Valaといったメモリー安全性を保証しない言語で書かれたソフトウェアの欠陥を見つける能力を高めていると述べた。GNOMEはこれらの言語に大きく依存しており、プログラミング上のミスがセキュリティへの影響をもたらし得る。同氏は、攻撃者も同様のツールを使って弱点を探し、悪用できるため、プロジェクト側もAIによるスキャンを行うべきだと主張した。

この投稿は開発者1人の意見であり、GNOME全体の正式な方針でも、条件を統制したモデル精度の測定でもない。それでもカタンザロ氏は、GLibやfwupdなどのプロジェクトに影響する脆弱性報告が増え続けている状況に直接対応した経験を、主張の根拠としている。同氏によると、GNOMEが対応するCVEの数は3年前のおよそ10倍となっている。その主因はAIを活用した発見だと同氏はみているが、内部の追跡管理の改善も一因だという。

発見件数が増えたからといって、報告の質が自動的に高まるわけではない。カタンザロ氏は、繰り返し見られる問題を列挙した。投稿が長すぎる、深刻さを誇張する、無関係な主張を含む、誤りがある、さらにはスタックトレースなどの診断情報を捏造する場合さえある。経験の浅い報告者が、モデルの出力を理解もテストもせずに貼り付けることもある。正確な報告であっても、メンテナーは問題を再現し、影響を評価し、公開の調整を行い、パッチをレビューし、セキュリティ勧告を追跡する必要があるため、ボランティアのチームに負担をかけ得る。

一部のメンテナーは対策として、課題管理システムでAI生成の内容を禁止している。カタンザロ氏は、GNOMEに届く脆弱性報告の大半が今ではAIによって生成されているため、その方法では有益な成果まで過度に排除してしまうと主張した。同氏が望むのは、作成を支援したツールの種類ではなく、報告の質を基準に区別することだ。無効な投稿や不注意な投稿は引き続き閉じてよいが、検証済みの発見を、発見や記録にモデルが関わったという理由だけで不適格にすべきではないという。

同氏はまた、AIの支援を受けた発見を、報告者が毎回一から書き直さなければならないという要件にも反対した。1回のスキャンで数十件もの不具合候補が出た場合、全面的な書き直しには検証や上流プロジェクトとの調整以上の時間がかかり、報告そのものをためらわせることになる。報告者が代わりに別の場所で公開すれば、影響を受けるプロジェクトが公表前に調査できる機会は減ってしまう。

この提案には、実務上の運営課題が残る。プロジェクトには、報告の作成経緯だけを唯一の受け入れ基準にすることなく、再現可能な証拠、影響についての明確な主張、人による検証を求める受け付けルールが必要だ。メンテナーが同時に届く報告に圧倒されないよう、件数制限やまとめて処理する仕組みも必要になるかもしれない。

AIによるセキュリティスキャンはレビュー能力を広げられるが、結果の確認が不十分であれば、後工程へ作業を押し付けることにもなる。したがって、カタンザロ氏の主張は、モデルの出力を自動的に信用すべきだというものではない。オープンソースのコミュニティーは、信頼できる証拠を有益なものとして扱い、幻覚による主張や裏付けのない主張を退けながら、出力を検証し、優先順位をつけるプロセスを整えるべきだということだ。