Linuxカーネルコミュニティは、 脆弱性の報告と管理方法に関する詳細なレビューこれは主に、AIツールがコード監査に直接的な影響を与えていることに起因します。これらのシステムの普及により、セキュリティアラートの量は劇的に増加しましたが、同時に重複、ノイズ、そして保守担当者への負担増といった深刻な問題も明らかになりました。
プロジェクトの中心人物であるリナス・トーバルズは、次のように説明しています（ Linux 7.1-rc4 リリースノートカーネルのプライベートセキュリティリストとして AI支援レポートの殺到により「ほぼ完全に管理不能」これらの報告の多くは重複していたり、分類が誤っていたりした。これを受けて、プロジェクトはLinux 7.1に統合された新しいドキュメントを公開し、真のセキュリティ脆弱性とは何か、そしてAIモデルを使用して生成された報告をどのように処理すべきかを再定義した。
重複報告で溢れかえったセキュリティリスト
トーバルズはLinux 7.1の開発に関する最近の通信で、脆弱性メーリングリストが 重要な通知が多数の重複したレポートと混ざり合ってしまうボトルネック問題は量だけではなく、同じ自動化ツールを使用しているにもかかわらず、異なる人々が全く同じ調査結果を提出してしまうことにある。
彼が説明したように、開発者は本来メッセージを受け取るべき相手にメッセージを転送したり、バグが既に修正済みであることを明確にしたりすることに多くの時間を浪費している。 カーネルブランチで数日または数週間前に修正されましたこの状況は、一部の人々から「メールの洪水」に例えられており、新たな深刻な脆弱性への対応に注力するのではなく、重複メールの整理にリソースを割かざるを得ない状況を生み出している。
HAProxyの開発で知られるベテランの安定版カーネルメンテナーであるウィリー・タロー氏は、以下の図表を提示している。 ほんの数年前までは、この非公開メーリングリストには週に2～3件の報告が届いていた。現在は1日に5件から10件の報告書が処理されている。その多くはAIによる分析に基づいているが、それらは時に実際の問題点を指摘するものの、実用的でない形式で提出され、関連する追加情報も提供されていない。
トーバルズはAIそのものを非難しているのではなく、AIの悪用を非難しているのだ。
そうは見えないかもしれないが、トーバルズは 人工知能を開発および監査ツールとして使用することには反対しない。彼自身も仕事でこうしたシステムを利用していることを認めているが、責任を持って慎重に利用しなければならないと主張している。
彼はコミュニティへのメッセージの中で、AIツールは実際に役立つときは「素晴らしい」が、問題を引き起こすときは問題になると強調している。 「不必要な苦痛と無益な架空の仕事」言い換えれば、自動化されたモデルが潜在的な脆弱性を指摘したという事実だけでは、検証が不十分な報告や技術的な背景情報が欠落した報告でセキュリティチャネルを溢れさせることを正当化するものではない。
トーバルズは、AIを使ってバグを見つける人は、生の結果をそのまま転送するのではなく、 カーネルのドキュメントを読み、脅威モデルを理解し、可能な限りパッチを提供するか、少なくとも影響について明確な説明を提供してください。目標は、人間がツールとメーリングリストの単なる仲介役となるのではなく、自動化された作業に付加価値を与えることである。
Linux 7.1 の新ルール：脆弱性とは何か、そうでないものとは何か
この状況に対応して、カーネルプロジェクトはLinux 7.1でより正確なドキュメントを組み込みました。 どの不具合をセキュリティ上の脆弱性として扱うべきか、そしてどの不具合を通常の経路で処理すべき単なるバグとみなすべきか。Willy Tarreau氏によって書かれたこのテキストは、既にカーネルのGitツリーの一部となっており、Linux 7.1-rc4のリリース前に入手可能です。
このガイドは、シンプルなアイデアから始まります。 ほとんどのエラーはプライベートセキュリティリストを経由すべきではないむしろ、これらの問題は公開開発メーリングリストで率直に議論されるべきです。問題を公に議論することで、より多くのレビュー担当者が集まり、より多くのユースケースが網羅され、一般的に質の高いソリューションにつながります。
この文書では、Linux にすでに 明確に定義された脅威モデルこれは現在、脆弱性を非公開で処理すべきかどうかを判断する際の主要な基準点となっています。セキュリティ脆弱性とは、適切に構成された本番システムでは本来持つべきではない機能を攻撃者が取得でき、悪用される可能性が高く、かつ多数のユーザーに深刻な脅威をもたらすものと定義されます。
実際には、問題を発見した人は、そのエラーが それは、一般的な状況においては、まさに信頼の境界線を越える行為だ。答えが「いいえ」の場合は、制限付きセキュリティチャネルではなく、公開メーリングリスト（LKMLやサブシステム固有のメーリングリストなど）を確認することを推奨します。とはいえ、このガイドではある程度の注意を払うことも推奨しています。疑わしい報告については、真の脆弱性を見過ごすよりも、非公開で確認する方が望ましいでしょう。
この文章のもう一つの重要な点は、 通常のバグをプライベートのメーリングリストに送信しても、修正が早まるわけではありません。それどころか、セキュリティチームが真に重大な障害を優先的に処理するために必要なトリアージ時間を浪費してしまう。軽微な問題でそのチャネルが溢れかえると、最終的にはサーバー、クラウドインフラストラクチャ、産業機器など、Linuxベースのシステム全体のセキュリティが悪化する。
脅威モデル：権限の分離と除外ケース
新しいドキュメントでは、カーネルの脅威モデルを更新して詳細に説明し、違反が問題となる保証事項を列挙しています。 優先的に対処すべきセキュリティ問題これらには、ユーザー空間とカーネルの分離、プロセス間のメモリ分離、ptraceの制限、IPCおよびネットワークメカニズムの分離、CAP_SYS_ADMIN、CAP_NET_ADMIN、CAP_SYS_PTRACEなどの機密性の高い機能に関連する保護が含まれます。
ユーザー名前空間には特に注意が払われており、CONFIG_USER_NS のような設定により、権限のないユーザーが隔離された環境を作成できます。プロジェクトでは、 それらの事例はグローバルシステムを侵害することはできないそのため、その隔離が破られた場合、それはセキュリティ上の問題となる。
/proc/kmsg、perf、debugfsなどのデバッグインターフェースも分析対象となりますが、これらのメカニズムを通じて機密情報にアクセスすることは危険を伴うことに留意する必要があります。 管理者による明示的な許可がない限り、ブロックされなければならない。さもなければ、攻撃を巧妙化させたり、権限を昇格させたりするために悪用される可能性のあるデータが漏洩するリスクがある。
この保証の定義に加えて、ガイドではどのような問題が それらは自動的に脆弱性として分類されるべきではない。このカテゴリには、古いカーネルブランチのエラー、管理者が選択した安全でないコンパイルオプション、sysctlまたはファイルシステムの不適切なパーミッション、デバッグ用に予約されている関数（LOCKDEP、KASAN、FAULT_INJECTION）、およびステージングエリアの実験的なコードが含まれます。
欠陥には 過剰な権限、現実世界での使用とはかけ離れた実験室シナリオ、操作されたハードウェア、管理不能な数の試行 あるいは、常識的な管理者であれば本番環境では適用しないような構成も該当します。同様に、明確な脆弱性を伴わないデータ漏洩や、ファイルシステムイメージにおける特定の問題（これらは通常、fsckなどのツールで対処されます）は、セキュリティチャネルのコアスコープ外となります。
AIを活用した調査結果：民間から公共へ
今回のアップデートで最も注目すべき変更点の1つは、AIの助けを借りて発見されたバグへのアプローチです。ドキュメントには次のように記載されています。 自動分析によって検出されたバグは、基本的に公開情報として扱われるべきである。たとえ最初の発送が私的郵便で行われたとしても。
理由は純粋に実務的なものだ。セキュリティチームの最近の経験から、これらの障害は発生しやすい傾向があることがわかっている。 同時に複数の研究者の手に渡った 同様のツールを試用している企業もある。数時間以内に同じ症状を説明するメールが複数届くことはよくあることで、形式に若干の違いはあるものの、長期にわたる機密保持を期待するのは非現実的だ。
この新たな現実により、トーバルズは次のように主張する。 これらの発見を、修正パッチがリリースされるまで隠しておかなければならない秘密として扱うのは、全く理にかなっていない。一般的なAIが発見できるのであれば、潜在的な攻撃者を含む他の主体も同様の結果にたどり着けると考えるのが妥当である。それらを「予約済み脆弱性」と分類することは、余計な作業を増やし、連携を複雑にするだけだ。
それは、フィルタリングせずにすべての技術的な詳細を公開することが推奨されるという意味ではありません。ガイドでは、AI を使用して検出されたケースでは、 このバグを再現できるプレイヤーはすぐには共有されません。 （エラーを引き起こす正確な手順またはコード）。適切なアプローチは、この資料が存在することを明示し、修正の検証に必要だと判断した場合に、保守担当者が非公開で要求できるようにすることです。
このアプローチでは、プロジェクトは2つの利益を組み合わせようとしています。一方では、 他の人が既に知っているような発見事項で、非公開リストを埋め尽くさないようにしましょう。一方で、対策が講じられる前に、誰にでも悪用される「レシピ」を提供してしまうのは避けるべきです。メディアプレーヤーはデバッグと影響評価の両方において貴重なツールとして認識されていますが、最低限の制御なしに配布されると、デリケートな問題にもなり得ます。
AI生成レポートの品質要件
新しいドキュメントでは、AI を活用したレポートの書き方に関するセクションが丸ごと設けられています。メンテナンスチームからよく聞かれる不満は、これらのレポートの多くが 過度に誇張されており、冗長な説明が多く、重要なデータにほとんど焦点が当てられていない。そのため、その読み解きや分類が複雑になる。
まず、報告書には以下の内容が記載されている必要があります。 簡潔で分かりやすく平易な文章でチームは、メーリングリストでの連鎖的な返信に適さないMarkdown形式、装飾的な表現、複雑な構造の使用を推奨していません。これは、メッセージを転送したり引用したりする際に情報が失われず、テキストが読みにくい塊にならないようにするためです。
内容に関しては、まず 影響を受けるファイルまたはサブシステム、影響を受けるバージョン、およびバグによる目に見える影響を示す簡単な要約。そこから詳細を追加することもできますが、常に、その不具合が優先度の高いものか、それとも軽微な問題に分類されるものかを判断するために、素早く読み取れるようにすることを目的としています。
もう一つ重要な点は、その影響がどのように説明されるかです。カーネル開発者は、AIが生成した多くのレポートが… 彼らは理論的な結果を誇張する傾向がある。プロジェクトの実際の脅威モデルを考慮しない架空のシナリオを連鎖させることは避けるべきです。複雑な攻撃シナリオを作成する代わりに、参加者は検証可能な事実、例えば標準構成のシステムでユーザーがどのような追加機能を得られるかを具体的に説明するなど、事実に基づいた説明を行うよう求められます。
このガイドでは、可能な限り、AIツール自体がLinuxの脅威モデルのドキュメントを事前に読み込んでおくべきだとまで提言している。 プロジェクトによって既に確立された基準に結論を合わせるその目的は、誤解を減らし、影響が限定的なバグが、何の根拠もなく重大な脆弱性であると誤って報告されることを、自動報告によって防ぐことである。
自動化時代のプレイヤー、パッチ、そして常識
ドキュメントでは、障害の説明方法に加えて、より実践的な側面にも焦点を当てています。 AIによるプレイヤーとパッチの生成および検証多くの最新ツールは、バグを再現する小さなテストプログラムやスクリプトを作成したり、バグを修正するためのコード変更を提案したりできるが、必ずしも確実に動作するとは限らない。
カーネルは、レポートを送信する前に、 研究者は、プレーヤーが説明どおりに動作することを自ら確認しなければならない。手順が失敗を引き起こさない場合、またはAIが再現可能な方法を生成できない場合、レポートの妥当性は著しく損なわれます。この検証なしに結果を公表することは、ノイズを増やすだけで、保守担当者の時間を無駄にするだけです。
パッチに関して言えば、本文では多くのAIがさらに優れていることを強調している。 影響を評価するコードを書くしたがって、これらのツールを使用するユーザーは、問題点の特定だけでなく、解決策の提案もツールに依頼することが推奨されます。ただし、開発メーリングリストに送信する前に、結果を手動で確認し、テストする必要があることを強調しておきます。
ガイドでは、パッチが依存しているためテストできない場合について明確に説明しています。 特殊なハードウェア、事実上消滅したネットワークプロトコル、または極めて稀な構成脆弱性が、誰も容易に検証できないような特殊な環境でのみ顕在化する場合、それは関連するセキュリティ脆弱性カテゴリに該当しない可能性が高く、プライベートチャネルの時間を費やすべきではない。
修正案を提案する際、プロジェクトは、ラベルを含む標準的なカーネルパッチ提出ガイドラインを遵守する必要があることをユーザーに通知します。 「修正:」は、バグを引き起こした特定のコミットを示します。また、常識的に判断することも推奨されます。影響を受けるファイルが1年以上変更されておらず、かつ単一の担当者によって管理されている場合、古いハードウェアドライバや廃止されたファイルシステムなど、実際のユーザーが非常に少ないコンポーネントである可能性があります。
このような場合、推奨事項は明確です。問題が些細で、簡単に検出でき、通常の環境では明らかな影響がない場合は、 最も合理的な方法は、公共開発リストを通じて直接対処することである。 そして、セキュリティ専用のリストには含まれていない。このようにして、最も機密性の高いリソースは、重大な結果を招く可能性のある事案のために確保される。
ファジングの時代からAIの雪崩まで：フリーソフトウェアへの教訓
現在の状況は、Syzkallerのようなファジングツールが登場した時代をいくらか彷彿とさせる。 検出されたエラーの報告を半自動的にカーネルに送りつける当時、地域社会は、日々の業務を阻害することなく、継続的に得られる知見を開発プロセスに統合する方法を学ぶ必要があった。
人工知能でも同様のことが起こるが、規模が異なる。今では、エラーを引き起こす入力の生成が自動化されているだけでなく、さらに... レポート自体の作成、コードの静的解析、およびパッチの提案これはバグ発見のスピードアップにつながるが、適切にフィルタリングや優先順位付けが行われないと、メールの数、並行して行われる議論、そしてカーネルチームが対応できる範囲についての期待値も増大してしまう。
Linuxエコシステム内部では、この現象の評価には微妙な違いがある。カーネルの主要メンテナーの一人であるグレッグ・クロア＝ハートマンは、次のように指摘している。 AIが生成するレポートは、かつてはほとんどが役に立たないものだったのが、急速に有効な情報提供へと変化した。このより楽観的な見方は、重複データの過剰とセキュリティリストの過負荷に対するトーバルズの懸念と共存している。
これらの立場は矛盾ではなく、 同じ養子縁組プロセスの二つの側面一方では、AIは実際の問題を発見するのに非常に役立ちます。他方では、多くの人が同じツールを同じコードに対して実行し、結果をフィルタリングせずに提出すると、その複合的な影響で管理が困難なアラートの「嵐」が発生します。
責任ある自動化の使用例として、Kroah-Hartman 氏自身がカーネルのスキャン、パッチの生成、テスト、プロジェクトの標準ワークフローに従った提出を行うカスタムシステムを公開しています。重要なのは、これらのケースでは、 開発者は、ライフサイクル全体に対する完全な技術的責任を負います。ツールが出力する内容を確認せずに単に転送するのではなく。
Linux 7.1 をめぐる動き全体は、人工知能を否定するどころか、 自動化がセキュリティに悪影響を与えるのではなく、セキュリティに有利に働くようにプロセスを調整する脆弱性の定義に関するより厳格な基準を設定し、検証可能な平文レポートを義務付け、AIがパッチの生成とテストに貢献することを奨励することで、カーネルは保守担当者の時間を保護し、ノイズを減らし、実際に本番システムを危険にさらす可能性のあるバグに注力することを目指しています。