2026年10月20日、Anthropic Frontier Red Teamの研究員Chris Rohlfが技術レポートを公開し、定量的・検証可能なAIコードセキュリティ実験の詳細を明らかにした。Claudeを用いて25のオープンソースプロジェクト、合計500万行超のC、C++、Java、PHP、Pythonコードを解析し、「ソフトウェアがデフォルト設定で出荷されているが、露出させる必要のない」冗長な到達可能パスを493箇所発見した。
最も説得力のあるデータポイントはOpenSSHに関するものだ。Anthropicの公式ブログによると、ClaudeはOpenSSH 10.4のSSHデーモンの入力パスを追跡し、実験的なML-DSA-44ポスト量子署名アルゴリズムのコード約4,500行が、クライアントの認証完了前に到達可能であることを発見した。これは同バージョンのデフォルトsshdにおける認証前コードの総量の約16%にあたる。その後、OpenSSH 10.5で関連チェックポイントが移動され、10.6で完全修正が完了した。この修正により「未認証のクライアントが到達可能だったOpenSSHコードの約5分の1が削除された」。
攻撃面の縮小：脆弱性を探さずにセキュリティを向上させる手法
従来のソフトウェアセキュリティ対策は脆弱性の発見と修正を中心に展開されてきた。CVEを一つ見つけ、パッチを当て、次を探すというサイクルだ。Rohlfはレポートの中で、このアプローチの根本的な欠陥を直接指摘している。「重大な脆弱性を一つ修正しても、残りの脆弱性について何も分からない」。脆弱性の総数を網羅することは不可能であり、攻撃者はまだ発見されていない一点を見つけるだけでよい。
攻撃面縮小（Attack Surface Reduction）は別のアプローチをとる。脆弱性を探すのではなく、攻撃者が到達できるコードの範囲を制限するのだ。あるコードに未知の脆弱性が存在していても、攻撃者が認証通過前にそこに到達できなければ、脆弱性の悪用可能性は大幅に低下する。この手法は理論上以前から存在していたが、課題は手動実施のコストが非常に高いことにある。ソフトウェアはバージョンを重ねるごとに抽象層、依存関係、機能を蓄積し続け、どのコードがどの実行フェーズで到達可能かを人手で逐一把握することは、規模的にほぼ不可能だ。
今回の研究でClaudeが担った作業はまさにこの人力ボトルネックの解消だった。各プロジェクトのコード到達グラフを網羅的にマッピングし、3種類の問題を特定した。すなわち、デフォルト設定下での不必要な認証前露出、設定オプションの組み合わせによる予期しない動作、そしてコードの実行タイミングが想定と一致しない箇所だ。Anthropicの発表によれば、Claudeは25プロジェクト全体で17,000以上の設定オプションを識別し、そのうち3,842個がセキュリティ上重要なものとして分類された。162組の設定の組み合わせでは、それぞれ単独では問題ないように見える2つのオプションを同時に有効化すると、セキュリティ制御が静かに弱体化することが判明した。さらにそのうち94組では、組み合わせた結果として特定のセキュリティ制御が警告もドキュメントへの記載もなく完全に無効化されていた。
3つの技術的アプローチ、それぞれ異なる攻撃者の入口に対応
本研究では、互いを補完する3種類の分析手法が用いられた。第一はデフォルト設定分析だ。出荷時のデフォルト状態において、外部から到達可能でありながらデフォルト機能上は不要なコードを検査する。
第二は設定の相互作用分析だ。単独の設定項目には問題がないが、組み合わせると予期しない副作用が生じるケースを対象とする。この種の問題の複雑性は組み合わせ爆発的で、N個の設定項目は理論上2のN乗通りの組み合わせを生む。人手によるテストではごく一部のパスしかカバーできない。Claudeの優位性はここにある。設定ペアを機械的に網羅し、コードの実行パスへの影響を追跡できるのだ。
第三は早期到達可能性分析だ。プロトコルのステートマシン上でコードに到達するタイミング、すなわちどのコードが認証前、ハンドシェイク前、またはセッション確立前に外部入力によって実行駆動されうるかを分析する。OpenSSHのML-DSA-44の発見はこのカテゴリに属する。Anthropicは対象プロジェクトの中で、デフォルト設定下での不必要な認証前露出面が93箇所、認証フロー前に実行可能なコードの位置が37箇所あることを発見した。
この3つのアプローチが発見するのは「脆弱性」そのものではなく、「脆弱性が存在した場合にいかに容易に悪用されるか」の増幅要因だ。この増幅要因を取り除くことは、脆弱性の総数を変えることなく、コードベース全体が攻撃に成功される確率を低下させることに等しい。
産業への影響：開発者、セキュリティチーム、上流メンテナーそれぞれへの意味
オープンソースの上流メンテナーにとって、OpenSSHの事例が持つ肯定的な意義は次の点にある。報告受領からOpenSSH 10.6の正式リリースまでの修正の連鎖が完結かつ追跡可能であり、AIツールが実際に定量的なセキュリティ改善をもたらしたことだ。しかし同時に、AIツールが広く普及する以前は、ML-DSA-44と同様の問題が同じパターンでコードベースに長年潜在していた可能性があることも意味する。複数の情報源によって整理された研究の詳細によると、複数プロジェクトにまたがる証明書検証バイパス脆弱性の設定組み合わせパターンが、21年間にわたって発見されなかったケースもあった。誰も確認していなかったからではなく、個々の設定項目を単独で見れば問題がなく、特定の組み合わせ下でのみ機能不全を起こすためだ。
これらのオープンソースコンポーネントを利用する企業のセキュリティチームにとって、本研究の実践的な価値は新たな作業方法を示唆している点にある。デプロイ前に同様の手法で依存コンポーネントを審査し、デフォルト設定下での露出面が実際のビジネスニーズと一致しているかを確認するというアプローチだ。Anthropicの公式ブログによると、同社はこのClaudeの機能をOSS-Scannerに統合する作業を進めており、この手法がツール化された形でより広範な開発者に公開される見込みだ。
AIの能力競争という観点では、本研究の意義は「ClaudeがセキュリティにおいてほかのAIより優れている」という点にあるのではなく、AIを使ったセキュリティ作業の具体的なパラダイムを提示した点にある。AIにセキュリティレポートを書かせるのではなく、AIに検証可能な分析タスクを実行させ、その結果を上流プロジェクトが独立して検証するというモデルだ。この「結果を外部検証可能」という運用方式が、多くのAIセキュリティデモとの根本的な違いだ。ベンダーによる自己評価を信頼する必要がない。OpenSSH 10.6のコード変更は公開されており、削除されたとされる認証前コードの約5分の1が実際に消えているかどうかは、誰でも検証できる。
比較と先例：21年間の潜在的脆弱性とスケールコストの問題
「設定の組み合わせによってセキュリティ制御が静かに無効化される」という類の問題は、セキュリティ界では決して珍しくない。TLS/SSLの歴史においても類似の問題が繰り返し発生している。あるダウングレードオプションと互換性オプションを同時に有効化すると、暗号プロトコルのセキュリティ属性が静かに消失するにもかかわらず、サーバー側のログにはすべて正常と表示されるケースだ。この種の問題が長期間潜伏するのは、テスト環境では一切のエラーを引き起こさず、攻撃者が特定の設定の組み合わせを意図的に構成したときにのみ武器となるためだ。
従来のセキュリティ監査がこの種の問題に対処するには2つの選択肢があった。一つはすべての設定の組み合わせを網羅的にテストすること（コストは設定項目数に対して指数関数的に増大する）、もう一つはセキュリティ研究者の経験と直感に頼り、問題のある組み合わせを推測することだ。前者は17,000個の設定項目を持つコードベースでは現実的に不可能であり、後者は希少な人材に依存する。まさにここにAI分析の構造的優位がある。推測を必要とせず、すべての組み合わせを機械的に網羅できるのだ。
もちろん、この手法にも限界はある。Anthropicはレポートの中で明示している。「コードベースに存在する未知の脆弱性の数を計測することは、ほぼ不可能だ」と。攻撃面の縮小が低下させるのは既知・未知を問わず脆弱性の悪用可能性であって、脆弱性そのものを排除するわけではない。認証前フェーズから移動された脆弱性でも、攻撃者が有効な認証情報を既に持っていれば依然として悪用可能だ。これがこの技術の上限であり、本研究が隠そうとしなかった境界条件でもある。
戦略的考察：今後の注目すべきシグナル
本研究が持つ最も重要な長期的含意は、OpenSSHの4,500行のコードよりも、再現可能なワークフローを検証した点にあるかもしれない。AIで到達グラフを生成し、ルールに基づいて異常箇所にフラグを立て、上流メンテナーに提出し、結果を上流の変更として追跡可能にするというフローだ。このプロセスが開発者が日常的に使うツール（AnthropicがOSS-Scannerへの統合として言及したもの）に組み込まれれば、「リリース前に攻撃面分析を一通り実行する」ことが、今日の静的解析ツールや依存関係の脆弱性スキャンと同様に、オープンソースソフトウェアのリリースプロセスにおける標準ステップになりうる。
この判断を検証するための観察シグナルは3つある。第一に、OSS-Scannerへの統合後の実際の採用率が、主要ディストリビューションのビルドパイプラインをカバーできるかどうか。第二に、OpenSSH以外の分析された24プロジェクトの修正状況だ。Anthropicは現時点でプロジェクト別の修正進捗を公開しておらず、このデータの公開度合いが上流コミュニティによるAIレポートの受容意欲を直接反映することになる。第三に、ほかのセキュリティベンダーが同様のデータを追って公開し、方法論レベルでの競争と相互検証が形成されるかどうかだ。
防御的セキュリティの観点から見れば、攻撃面の縮小と脆弱性修正は相互排他的ではなく、補完的な関係にある。前者は未知の脆弱性の爆発半径を低下させ、後者は既知の脆弱性のリスクを排除する。両方を通常の開発プロセスに組み込むには、ツールだけでなくエンジニアリング文化の転換も必要だ。「発見してから修正する」から「デプロイ前に攻撃面を縮小する」へのシフトである。AIがこの転換を推進できるかどうかは、コストを十分に低下させ、Anthropicのような機関が大規模デモを行う際だけでなく、すべてのメンテナーがリリースのたびに実行したいと思えるレベルに達せるかにかかっている。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接