Anthropic OSS Scanner、無料のオープンソース監査を提供 ただしメンテナーはAI出力のトリアージが必要
Anthropicは10月8日、対象となるオープンソースプロジェクト向けに、脆弱性監査を継続的かつ無料で提供するAnthropic OSS Scannerを発表した。このサービスは、AI支援型セキュリティ調査を大きく拡張するものだ。一方で、レポートは人による検証を経ずに届くため、重要な負担をメンテナーへ移すことにもなる。
このトレードオフが今回の発表を規定している。Anthropicによれば、同社のモデルはセキュリティ研究者が手作業でレビューできる量を上回るコードを調査できる。OSS Scannerは、生の検出結果を参加プロジェクトへ直接送付することで、そのレビュー上のボトルネックを取り除く。
オープンソースのメンテナーにとって、そのタイミングは厳しい。Googleは最近、無効な自動生成レポートの増加を受け、オープンソース脆弱性報奨プログラムの一部を停止した。curlプロジェクトも、メンテナーが低品質な報告への対応に苦慮したことを受け、バグ報奨金制度を終了している。
Anthropicは、自社のレポートが、これまでメンテナーを悩ませてきたAI生成の検出結果よりもはるかに優れた証拠を提供できるようになったと考えている。初期参加プロジェクトからのフィードバックは、一部の事例でその主張を裏付けている。ただし、この公開サービスが、より幅広いリポジトリで精度を維持できるかは、まだ明らかになっていない。
Anthropic OSS Scannerは人によるレビューを速度と引き換えにする
Anthropic OSS Scannerは、メンテナーに潜在的な脆弱性への早期アクセスを提供する一方、各参加プロジェクトがモデルの結論を検証する責任を負う。
OSS Scannerの発表によると、参加プロジェクトはAnthropicの最も高性能なモデルによる定期スキャンを受ける。これらには、高度なサイバーセキュリティ業務向けにAnthropicが開発したClaude Mythosも含まれる。
レポートは完全にモデルによって生成される。Anthropicは、検出結果がプロジェクトに届く前にセキュリティ研究者が検証するとは約束していない。同社は、レポートが誤っていたり無効だったりする可能性を明示的に警告している。
各レポートは、疑わしいコード箇所だけでなく、より多くの情報を含むよう設計されている。Anthropicは、説明、再現手順、利用可能な場合は修正候補を提供するとしている。レポートには、疑われる欠陥がいつ混入したかを特定するコード履歴分析も含まれる場合がある。
この証拠は重要だ。なぜなら、メンテナーには、実際の脆弱性ともっともらしく聞こえるモデル出力を区別するための、再現可能な方法が必要だからである。具体的な再現手順があれば、エンジニアは関連コードを実行し、報告された挙動が実際に発生するかを確認できる。
修正候補は次の工程を短縮し得る。しかし、レビュー、テスト、互換性確認、下流との調整が不要になるわけではない。セキュリティ修正は、ときにユーザーや依存ソフトウェアが暗黙に依存している挙動を変えることがある。
Anthropicは、登録をより広く受け付ける前に、数十のオープンソースプロジェクトでこのパイプラインをテストした。同社によれば、これらの初期スキャンでは数百件のレポートが生成された。Anthropicは、複数の検出結果を組み合わせることで、認証不要のリモートコード実行につながる可能性があるとしている。
これは深刻な脆弱性の分類である。攻撃者が影響を受けるシステムにログインせずとも、コードを実行できる可能性があるためだ。ただしAnthropicは、初期結果に関する完全な独立評価を公表していない。
今回の発表は、Anthropicが従来、協調的脆弱性開示プログラムを通じて扱ってきた業務を拡張するものだ。そのプロセスでは、セキュリティ研究者がメンテナーに通知する前に検出結果をレビューしていた。公開開示は通常、定められたタイムラインに従って行われた。
OSS Scannerは別の高速ルートを設ける。その自動検出結果はメンテナーに非公開でメール送信され、Anthropicは標準的な開示期限に基づいて自動公開することはないとしている。
Anthropicが後に人によるレビュー済みプログラムを通じて検出結果を検証した場合、そのレポートは同社の既存の開示プロセスに入る可能性がある。それまでは、自動レポートは未検証の非公開報告として扱われる。
この違いは本質的だ。Anthropicは、登録済みソフトウェアが安全であるという認証を提供しているわけではない。システムが成功した場合には再現可能な証拠に裏付けられた、脆弱性仮説の新たな情報源を提供しているのである。
Anthropicがプロセスを変えた理由は数字に表れている
このサービスが存在するのは、Anthropicのモデルが、研究者による検証よりはるかに速く候補となる検出結果を生成できるためだ。
Anthropicによれば、過去6カ月間に重要なソフトウェアプロジェクトをスキャンし、2万9,000件超の脆弱性候補を発見した。その期間中に研究者が手作業でレビューしたレポートは約6,000件だった。
つまり、2万3,000件を超える候補が完了した人によるレビュープロセスの外に残ることになる。一部は実際のセキュリティ問題を示すだろう。ほかは重複、誤解、影響の小さい欠陥、またはモデルによる誤った結論となる可能性がある。
Anthropicは、メンテナーから未検証の出力を一括で受け取りたいという要望が増えていたとも述べている。同社は、利用可能なすべての情報の受領を求めたプロジェクトに、未検証の検出結果を約5,000件送信したとしている。
これらの数字は、Anthropic OSS Scannerの運用上の論理を説明している。手作業によるレビューを必須にし続ければ、Anthropicが対象にできるリポジトリ数は制限される。その要件をなくすことで、対象範囲、頻度、不確実性が同時に増す。
同社はこの転換をモデル性能の向上と結び付けている。Anthropicによれば、2025年初頭には言語モデルがCyberGymベンチマークで発見できた脆弱性は20％未満だったが、2026年には85％を上回ったという。
ベンチマークは標準化されたテストセットであり、実環境での性能を保証するものではない。現実のリポジトリには、特殊なビルドシステム、文書化されていない前提、生成コード、プロジェクト固有のセキュリティ境界が存在する。
モデルは、ソフトウェア上の本物の欠陥を特定しても、そのセキュリティ上の影響を正しく判断できない場合がある。到達不能なテストユーティリティ内の範囲外読み取りと、ネットワークサービス経由で公開されるものとでは、リスクが異なる。
Anthropic自身の数字は、もう一つの制約も示している。候補となる問題を見つけることだけが希少な資源ではなくなった。検証、優先順位付け、修正、開示が、ワークフローの中でより難しい部分になりつつある。
この移行は、専任のセキュリティチームを持たないプロジェクトに負荷をかける。主要なインフラライブラリは、機能要望、回帰、不具合、パッケージング問題、コミュニティ支援をすでに担っている少数のメンテナーに依存していることがある。
よく構成されたレポートであっても、注意力を消費する。誰かが挙動を再現し、影響を受けるバージョンを確認し、悪用可能性を評価し、安全な修正を設計し、リリースを調整しなければならない。
セキュリティチームは長年、静的解析、ファジング、依存関係スキャンを用いて疑わしい挙動を特定してきた。ファジングは、予期しない入力をソフトウェアに与え、クラッシュやその他の障害を露呈させる手法だ。
AI脆弱性スキャンは、そこに推論の層を加える。モデルは関数間の関係を調べ、意図された挙動を推測し、バージョン履歴を確認し、狙いを定めたテストを構築できる。
Anthropicによれば、従来の手法で何も見つからなかった後に、同社のモデルが新たな調査経路を追ったことがあるという。過去の研究には、ソース管理の履歴を調べたり、疑われる脆弱性の概念実証プログラムを書いたりする作業が含まれていた。
この幅広い推論は、パターンベースのツールが見落とす欠陥を見つけられる可能性がある。一方で、説得力はあるものの誤った説明を生み出すこともある。したがって、添付される証拠の質は、説明の流暢さより重要になる。
オープンソースのメンテナーが最終検証層となる
Anthropicの無料サービスは、コストのかかるモデル計算をメンテナーから切り離すが、セキュリティトリアージに伴う人的コストを取り除くものではない。
中心的なメンテナーは、プロジェクトの登録リポジトリを通じてオプトインする。ソフトウェアのビルドに必要な設定詳細と手順を含むプルリクエストを提出する。
各プロジェクトは、リポジトリアドレス、主たるセキュリティ連絡先、Dockerfileを提供する。Dockerfileは、コンテナ内でプロジェクトをビルドするために必要な環境とコマンドを記述する。
プロジェクトは脅威モデルも提供できる。この文書では、どの資産が重要か、信頼できないデータがどこから入るか、メンテナーが深刻度をどのように分類するかを説明する。
この文脈は、明白な誤解を防ぎ得る。そうでなければスキャナーは、意図的な挙動を脆弱性として扱ったり、信頼できない入力を決して処理しないコードの重要性を過大評価したりする可能性がある。
Anthropicは、参加プロジェクトを隔離された仮想マシン内でビルドする。セットアップ時には、必要な依存関係を取得するためにネットワークアクセスを使用できる。実際のセキュリティ分析は、強化されたサンドボックス内でインターネットアクセスなしに実行される。
検出結果は、その後プロジェクトの指定連絡先へメール送信される。メンテナーは、登録設定とともにOpenPGPキーを公開することで、暗号化された配信を要求できる。
このサービスは、条件を満たすオープンソースプロジェクトに限定される。Anthropicによれば、対象要件はGoogleのOSS-Fuzzプログラムで用いられる基準に似ている。プロジェクトは、インフラまたはユーザーセキュリティに重大な影響を持つべきだとされる。
この基準により、OSS Scannerは、誰もが任意のリポジトリに向けられる公開ツールとは異なるものになる。Anthropicは登録を管理し、受け入れられたプロジェクトのモデル計算コストを負担する。
同社はまた、一般向けの商用セキュリティ製品で使用するよりも、実験的でトークン消費量の多いスキャン手法を適用する。この選択により、オープンソース向けサービスは、より深い監査の実験場として位置付けられる。
メンテナーは、登録後も主導権を保持する。別のプルリクエストを通じて、設定の編集、ビルド手順の更新、スキャンの一時停止、プロジェクトの撤回ができる。
各検出結果をどう扱うかも、メンテナーが決める。Anthropicは、生の自動出力に対して公開Issueを自動作成したり、脆弱性識別子を割り当てたり、開示期限を課したりしない。
このアプローチは、誤ったレポートが、プロジェクトが悪用可能な欠陥を出荷していると公に非難する可能性を低減する。また、メンテナーが修正を評価する前に技術的詳細が露出することも避けられる。
しかし、非公開配信はキャパシティ制約を解決しない。小規模プロジェクトであっても、ボランティアが処理できる以上の信頼性の高いレポートを受け取る可能性がある。Anthropicは、レポート量に対する一律の上限を発表していない。
プロジェクトには独自の受け入れルールが必要となる。実用的なワークフローでは、再現可能で外部から到達可能な問題と、非現実的な条件を必要とするクラッシュを分けるべきだ。
チームには、永続的な技術記録も必要だ。検索可能なエンジニアリング・ナレッジベースは、再現手順、影響を受けるバージョン、パッチに関する判断、後続タスクを保存できる。
複数のレポートが同じ根本原因を共有する場合、この記録は重要になる。これがなければ、異なるメンテナーが同じ調査を繰り返したり、ブランチごとに一貫性のない修正を適用したりする可能性がある。
AI脆弱性スキャンはいま精度の試練に直面している
中心的な問題は、AIモデルが脆弱性を見つけられるかどうかではなく、メンテナーの注意を払うに値するだけの検証済みシグナルを提供できるかどうかだ。
Anthropicの最も強い初期証拠は、このシステムを試験したプロジェクトから得られている。PostgreSQLコントリビューターのNoah Mischは、複数のレポートが欠陥を特定し、ほぼそのまま使える修正を含んでいたと述べた。
OpenSSL CorporationのAnton Arapov氏は、生の出力を人間による報告と比べて高く評価した。同氏は、エンジニアが直接テストできるため、動作するエクスプロイトを受け取れることの価値を強調した。
報告された結果の中で最も具体的だったのはwolfSSLからのものだ。Anthropicが公開したフィードバックによると、このプロジェクトは74件の指摘を受け、そのうち2件を除くすべてを有効と判断した。5件の指摘は、一般にCVEと呼ばれるCommon Vulnerabilities and Exposuresの記録となった。
この結果は、ある初期導入環境で高い精度が得られたことを示唆している。ただし、プログラミング言語、プロジェクトの種類、ビルド構成、脅威モデルをまたいで同じ割合が成立することを裏付けるものではない。
このサンプルはAnthropic自身の発表資料に由来するものでもある。同社はパイロットで受理、却下、重複、異議申し立てとなったすべての報告を示す完全なデータセットを公開していない。
独立した評価には、報告件数を数える以上の作業が必要になる。研究者は、有効性、深刻度、重複、再現までの時間、パッチ適用までの時間、提案された修正によって発生した回帰の数を検証すべきだ。
メンテナーの負担も重要な指標である。より多くの実在する欠陥を見つけるスキャナーであっても、有効な報告が多数のもっともらしい誤検知に埋もれるなら、全体としては負担を増やしかねない。
このリスクは理論上のものではない。他のオープンソースコミュニティでは、十分な根拠を欠く自動生成の脆弱性報告が急増した経験がある。
Googleは、自動生成レポートが大幅に増加したことを受け、Open Source Software Vulnerability Rewards Programの一部を停止したと述べている。同社の説明によれば、これらの提出の大半は無効だった。
curlプロジェクトは2026年1月にバグバウンティを終了した。メンテナーは、AI生成レポートが相応のセキュリティ上の価値をもたらさないまま時間を消費していると、繰り返し警告していた。
Linuxのメンテナーも、重複する自動生成レポートの管理は難しいと説明している。複数の人が似たツールを実行し、同じ疑わしいパターンを見つけ、ほぼ同一の報告をそれぞれ送信する可能性がある。
Anthropicのオプトイン設計は、この問題の一部に対処している。承認されたメンテナーだけがプロジェクトを登録し、報告は指定された連絡先に直接送られる。外部の人々が提出量を最大化するよう促す金銭的報酬もない。
必須の再現手順も、求められる証拠水準を引き上げる。観測可能な挙動を示す報告は、単にコードパターンを危険とラベル付けするだけの報告より有用だ。
それでも、再現手順はクラッシュを示せても、有意義な攻撃経路を証明するとは限らない。また、実際のユーザーが決して利用しない人工的なビルドオプションや構成に依存する場合もある。
候補パッチも不確実性の要因となる。パッチはテストを通過させても、根本的な脆弱性を残す可能性がある。また、別のバグを導入したり、下流での互換性を壊したりすることもある。
初期結果は慎重な注目に値するが、自動的な信頼を正当化するものではない。Anthropic OSS Scannerは、協力的なパイロットプロジェクトを超えて登録が拡大した後も、その出力が有用であり続けることを証明しなければならない。
OSS Scannerは既存のセキュリティツールを補完する
Anthropicは、このスキャナーをファザー、依存関係データベース、コードレビュー、協調的開示に代わるものではなく、追加の発見システムとして位置付けている。
最も明確な歴史的比較対象は、ファジング基盤で重要なオープンソースプロジェクトを継続的にテストしてきたGoogleのOSS-Fuzzサービスだ。
OSS-Fuzzは、ツールが意味のあるプログラム挙動を引き出す入力を生成できる場合に有効である。特に、ファイル、ネットワークメッセージ、その他の信頼できないデータを解析するソフトウェアに役立つ。
ただし、ファジングはテストハーネスと観測可能な失敗に依存する。一部の認可エラー、ビジネスロジック上の欠陥、複数ステップの攻撃経路は、直ちにクラッシュを引き起こさない。
大規模言語モデルは、こうした関係性を推論できる。異なるコンポーネントをまたぐデータの流れを追跡し、プロジェクトが掲げるセキュリティモデルを考慮し、標的を絞った実験を生成できる。
従来の静的解析も比較対象の一つだ。これは完全なプログラムを実行せずにソースコードを調べ、危険なデータフローやパターンを特定するルールを適用する。
静的解析ツールは再現性があり、ソフトウェア変更のたびに実行できる。その有用性は、ルールの品質、言語サポート、そしてチームが繰り返し発生する警告を管理できるかどうかに左右される。
ソフトウェア構成分析は、含まれるパッケージと既知の脆弱性に焦点を当てる。依存関係が影響を受けるバージョンに一致していることはチームに通知できるが、これまで知られていなかった欠陥を発見することは通常ない。
Anthropicのサービスは、ソースコード内にある未知の脆弱性を対象とする。同社のモデルは、リポジトリを既存の脆弱性カタログと照合することに限定されない。
これらすべてのアプローチにおいて、人間によるレビューは依然として必要だ。セキュリティエンジニアは、デプロイ環境、攻撃者の動機、互換性要件、そしてスキャナーの即時のテスト環境を超えた影響を理解している。
各ツールは互いを補強することもできる。AIが生成した仮説はファジングの標的になり得る。ファザーによるクラッシュは、根本原因分析のための具体的な証拠をモデルに与えられる。
モデルはパッチを提案でき、静的解析と回帰テストはその変更に新たな問題がないか検証できる。依存関係分析はその後、更新版リリースが必要な下流製品を特定できる。
Anthropicの標準開示ポリシーは、同社の研究者が問題を検証する場合にも引き続き関係する。このポリシーは一般に、通知後90日が経過した時点、またはパッチがリリースされた時点での開示を対象としている。
このポリシーでは、現在悪用されている重大な脆弱性に対して、より短い期限を認めている。また、修正に向けて進展しているメンテナー向けの延長についても説明している。
生のOSS Scannerレポートは、この自動的なスケジュールの対象外である。Anthropicは、それらが後に人間によるレビューのプロセスに入らない限り、公開しないとしている。
この分離により、メンテナーには調査の余地が与えられる。一方で、長期間未解決のままとなる指摘に関するガバナンス上の未解決の問題も生まれる。
Anthropicは、将来的に一部の高深刻度な自動検出結果について開示期間を導入する可能性があるとしている。同社は、方針が変更される場合には事前通知を行い、プロジェクトがサービスを離脱できる選択肢を提供すると約束している。
現時点では、このサービスは公的な説明責任よりも非公開の防御的アクセスを優先している。これは妥当なローンチ時の立場だが、参加するメンテナーが責任を持って対応することに大きく依存している。
サービスの成否を左右する要因
Anthropic OSS Scannerが有用なセキュリティ基盤になるのか、それとも要求の多い自動生成レポートの新たな発信源になるのかは、3つのシグナルが示す。
最初のシグナルは、新たに登録されたプロジェクトの経験だ。Anthropicのパイロットに寄せられたフィードバックは、強力な技術的専門性と成熟したセキュリティプロセスを持つ確立されたチームからのものだった。
登録対象の拡大により、スキャナーは異なる言語、アーキテクチャ、保守モデルで試されることになる。その結果は、初期の精度が選ばれたグループを超えて通用するかどうかを明らかにするはずだ。
公開文書化された修正は有用な証拠となる。コミット参照、CVE記録、メンテナーによる振り返りは、どの報告が意味のあるセキュリティ改善につながったかを示せる。
帰属表示は任意だが、Anthropicは関連するコミットにスキャナーレポートの識別子を含めるようプロジェクトに勧めている。これらの識別子は、どの指摘がパッチにつながったかを同社が測定する助けとなる。
2つ目のシグナルは、時間の経過に伴うレポート品質だ。Anthropicは最終的に、未解決の脆弱性を公開することなく、精度、重複、深刻度、修正状況に関する集計データを公開すべきである。
最も有益な指標は、候補となる指摘の総数ではない。メンテナーが過度な調査なしに再現、受理、修正できる報告の割合だ。
誤検知率の低下は、言語モデルが重要な有用性の閾値を超えたというAnthropicの主張を強めるだろう。トリアージコストの上昇は、その主張を弱めることになる。
3つ目のシグナルは、他のセキュリティプログラムがどう反応するかだ。Googleは、無効な自動生成レポートに対処した後、停止中のオープンソース報酬プロセスを見直す計画だ。
Anthropicの導入が成功すれば、バグバウンティや開示プログラムで使われる証拠基準に影響を与える可能性がある。再現手順とテスト可能なパッチが、機械生成レポートには当然求められるものになるかもしれない。
導入が失敗すれば、より厳格なフィルターが促される可能性がある。認められた組織が人間による検証を行わない限り、メンテナーは自動生成の指摘をデフォルトで拒否するようになるかもしれない。
Anthropicは、攻撃者側の適応も注視しなければならない。防御目的の指摘を見つけるモデルの能力は、悪意ある研究者が広く導入されたソフトウェアを調査する助けにもなり得る。
同社は、高度なサイバー能力に対してアクセス制御と監視を適用していると述べている。OSS Scannerはさらに、隔離された環境で動作し、指摘を非公開で提供することで露出を抑えている。
これらの対策で、より広い競争をなくすことはできない。モデルは改善を続け、同様の能力はプロバイダー、セキュリティ企業、ローカルシステム全体に広がっていく。
そのため、修正の速度はいっそう重要になる。攻撃者に悪用される前に、プロジェクトが脆弱性を再現し、パッチを適用し、テストし、修正を配布できなければ、先に脆弱性を見つけても保護効果はほとんどない。
オープンソースのメンテナーは、このサービスをコードに対する判定ではなく、追加のセキュリティ入力として評価すべきだ。対象となるプロジェクトは登録要件を確認し、十分なトリアージ能力を備えているかを判断できる。
より重要な問いは、AIスキャナーが時折間違うかどうかではない。あらゆるセキュリティ技術には限界がある。問われるのは、Anthropicのレポートが消費する以上のエンジニアリング時間を節約するかどうかだ。
Anthropic OSS Scannerは今後、そのバランスを公に示さなければならない。今後数か月のメンテナー側の成果は、モデルが見つけたと主張する脆弱性の件数よりも重要になる。
