Anthropic OSS Scannerは無料、ただしメンテナーによる検証が必要
Anthropicは10月8日、Anthropic OSS Scannerを無料サービスとして公開し、オープンソースプロジェクトに同社最強のAIモデルによる定期的なセキュリティ監査を提供し始めた。このサービスには脆弱性の説明、再現手順、修正パッチ案が含まれる。ただし、レポートは人間によるレビューを経ずにメンテナーへ届く。
このトレードオフこそがサービスの本質だ。Anthropicは社内レビュアーを工程から外すことで、より迅速に調査結果を届けられる。一方、各脆弱性が有効か、適切に優先順位付けされているか、安全に修正できるかを判断するのはプロジェクトチームとなる。
今回の公開により、Anthropicは限定的なセキュリティ研究プログラムや有料のエンタープライズ向けスキャンを越えて活動を広げた。また、最先端モデルをソフトウェア防御に活用する競争において、同社はOpenAIやGoogleと並ぶ存在となる。競争の焦点は、もはやバグを見つけることだけではない。機械生成された増え続ける調査結果を、信頼できるパッチへと転換することにある。
オープンソースのメンテナーには、この支援を受け入れる十分な理由がある。広く利用されるプロジェクトであっても、少人数のチーム、限られた予算、拡大するセキュリティ責任のもとで運営されていることが多い。しかし、無料の検出サービスであっても、各レポートにテスト、開示判断、リリース調整が必要となれば、実質的なコストを生みうる。
Anthropic OSS Scannerは人間のレビューを速度と引き換えにする
Anthropic OSS Scannerは、メンテナーに未加工のAI調査結果を直接提供する。迅速な提供は最大の利点であると同時に、最大のリスクでもある。
このサービスはオプトイン方式で、対象となるオープンソースプロジェクトは無料で利用できる。Anthropicによれば、登録したリポジトリにはClaude Mythosを含む最強モデルによる定期スキャンが提供される。
scanner launchによると、各レポートには自己完結型の再現コード、脆弱性の説明、利用可能な場合には修正候補が含まれる。再現コードとは、メンテナーが疑わしい欠陥を発生させ、確認するための簡潔なテストである。
この形式が重要なのは、曖昧な警告では調査作業の大半が受け手に戻されてしまうためだ。動作する再現コードがあれば、エンジニアは明確な出発点を得られる。修正案があれば、検出から対処までの時間をさらに短縮できる。
プロジェクトは公開GitHubリポジトリを通じて登録する。メンテナーは、設定ファイル、ビルドプロセス、連絡先情報、任意の脅威モデルを含むプルリクエストを提出する。
その後、スキャナーは隔離された仮想マシン内でプロジェクトをビルドする。分析前に、その環境をインターネットに接続されていないネットワークへ移す。調査結果は自動公開されるのではなく、プロジェクトが指定した連絡先へメールで送られる。
enrollment instructionsでは、レポートが配信前に人間のレビューを受けないことが明記されている。Anthropicはまた、これらの調査結果に標準の90日間の開示期限を設けず、公開もしないとしている。
この方針は、差し迫った危険の一つを抑える。不確実なレポートによって、疑われる弱点が自動的に露出したり、公表までの時計が動き出したりすることはない。メンテナーは検証、修正、その後のアドバイザリー公開を引き続き管理できる。
ただし、機密性によって検証の問題が解消されるわけではない。モデルは実際のコーディング上の欠陥を特定しても、その到達可能性、深刻度、実務上の影響を誤って評価することがある。また、ある経路を塞ぐパッチを提案しつつ、別の場所で期待される挙動を変えてしまう可能性もある。
Anthropicもその可能性を率直に認めている。同社はこのサービスを、未レビューの出力を処理できるプロジェクト向けの任意の高速ルートと位置付けている。その能力がないプロジェクトは、調査結果を配信前に人間のレビュアーが確認するAnthropicの協調開示ワークフローにとどまることができる。
その結果、実質的に二本立ての仕組みとなる。一方はレビュー品質と統制された開示を重視し、もう一方は頻度と速度を重視する。後者では、メンテナーがより多くのトリアージ責任を負う。
Anthropicは、初期版を数十のプロジェクトで検証したとしている。これらの開示では数百件のレポートが生成され、その中には認証なしのリモートコード実行チェーンを形成したとされる欠陥も含まれていた。
同社はまた、48プロジェクトにまたがる高深刻度およびクリティカルの調査結果97件を、ペネトレーションテスターにレビューさせた。Anthropicによれば、85件、すなわち88％が協調開示の基準を満たした。残る11件は実在したが、既知の問題や同一スキャンからの重複した調査結果であり、1件は無効だった。
これらの結果は期待を持たせるものだが、Anthropic自身の検証に基づく。異なる言語、ビルドシステム、アーキテクチャ、プロジェクト規模において、このサービスがどのように機能するかを示すものではない。
また、未加工の精度だけでは不完全な指標である理由も示している。重複レポートは実在する欠陥を示していても、限られたメンテナーの時間を消費する。深刻度が過大に評価された有効なレポートも、プロジェクトのリリース優先順位を乱しかねない。
したがって、このサービスが変えるのは検出速度だけではない。運用上の判断の最前線を、Anthropicのセキュリティチームから、影響を受けるコードにすでに責任を負う人々へ移す。
この公開は研究プログラムをオープンなインフラへと変える
OSS Scannerは、Anthropicのこれまでの脆弱性研究を、より多くのメンテナーが直接申し込める継続的なサービスへ転換する。
このスキャナーは、重要なソフトウェアに対して高度なモデルを用いるAnthropicの限定プログラム、Project Glasswingから生まれた。Anthropicは2026年4月、テクノロジー企業、セキュリティベンダー、オープンソース組織とともにこの取り組みを始めた。
立ち上げ時のグループにはAmazon Web Services、Apple、Broadcom、Cisco、CrowdStrike、Google、Linux Foundation、Microsoft、Nvidia、Palo Alto Networksが含まれていた。Anthropicはさらに40を超える組織にもアクセスを拡大した。
Anthropicは、最大1億ドル分のモデル利用クレジットと、オープンソースセキュリティ組織への400万ドルの寄付を約束した。このプログラムでは、選ばれた防御側に、高度な脆弱性発見およびエクスプロイト能力を持つモデル、Claude Mythos Previewへの早期アクセスが提供された。
この統制された構造には二つの目的があった。防御側にモデルへの早期アクセスを与える一方、攻撃的な活動も支援しうる能力の広範な提供を制限することだ。
報告された調査結果の規模は、間もなく別の問題を生んだ。5月の更新でAnthropicは、およそ50のパートナーが1万件を超える高深刻度またはクリティカルな脆弱性を発見したと述べた。この数値は同社が報告した合計であり、独立監査の結果ではない。
AnthropicのGlasswing updateは、主なボトルネックが検出から検証、開示、パッチ適用へ移ったと主張した。つまり、モデルは人間が安全に処理できる速度を上回って、潜在的な調査結果を生み出していた。
OSS Scannerは、Anthropic自身のレビュアーがすべてのレポートを精査する必要なく、利用範囲を広げようとする試みだ。このサービスはオプトインという境界を維持しつつ、処理能力を制約していた中心的なレビュー工程を取り除く。
この転換により、スキャナーは一回限りの研究活動とは異なるものになる。研究チームはリポジトリを選択し、スキャンのタイミングを制御し、注目すべき調査結果に集中できる。継続的なサービスでは、多様なプロジェクトを支え、各メンテナーのワークフローをすべて把握せずとも有用な出力を提供しなければならない。
Anthropicは2026年10月までに、協調開示プロセスを通じて6,000件を超えるレポートをレビューしていた。手動レビューは誤検知からプロジェクトを守るのに役立ったが、一部の開示を遅らせる要因にもなった。
複数のメンテナーは、自身のプロジェクトに関するすべての調査結果を、未レビューの出力を含めてAnthropicに求めたとされる。OSS Scannerは、自前でトリアージを行う意向のあるチームに対して、その取り決めを正式なものにする。
初期のフィードバックは、一部のチームがなぜこの取引を受け入れたかを示している。WolfSSLは受け取った74件のレポートのうち72件が有効で、そのうち5件は脆弱性として割り当てられたと述べた。PostgreSQLは、複数の修正案がほとんど変更せずに使えたと報告した。
OpenSSLのAnton Arapovは、これらのレポートを、約18か月前に受け取っていたはるかに質の低いAI提出物と対比した。Anthropicの未加工の出力は、ときに人間によるレポートに匹敵、あるいはそれを上回っており、特に動作するエクスプロイトが含まれる場合にそうだったと語った。
CurlのメンテナーであるDaniel Stenbergは、このスキャナーが対処する価値のある複数の問題を見つけ、その中には近年で最も深刻なcurlのレポートの一つも含まれていたと述べた。これらは選ばれた初期参加者からの証言であり、代表的なベンチマークとして扱うべきではない。
それでも、調査結果とともに証拠をパッケージ化する実用的な価値を示している。メンテナーがAIシステムに求めるのは、単に怪しいコードを特定することではない。問題を再現し、影響を受けるバージョンを評価し、安全なリリースを準備するのに十分な文脈が必要だ。
そこで整理されたengineering knowledge baseも役立つ。チームはレポートを、アーキテクチャの記録、過去の修正、担当情報、リリース判断と結び付ける必要がある。
OSS Scannerは、その組織的知識を置き換えるものではない。潜在的にはるかに大きな量で、そこへ新たな入力を供給する。
オープンソースのメンテナーが新たなセキュリティ上のボトルネックになる
このサービスは脆弱性を見つけるコストを下げるが、修正を検証し、リリースするために必要な人間の作業をなくすものではない。
脆弱性レポートは、プロセスの終わりではなく始まりである。メンテナーは挙動を再現し、影響を受けるバージョンを特定し、悪用可能性を評価し、提案されたパッチが回帰を招かないか確認しなければならない。
また、下流のディストリビューターと非公開で調整する必要があるかもしれない。広く使われるライブラリは、OS、クラウドサービス、アプリケーション、組み込み製品に組み込まれている可能性がある。準備なしにパッチを公開すれば、利用者が更新する前に攻撃者へ知らせることになりうる。
大手ベンダーは、この作業のためにセキュリティ対応チームを雇用している。多くのオープンソースプロジェクトは、機能開発、サポート要求、ビルド失敗、コミュニティ運営もすでに担う少数のメンテナーに依存している。
Anthropicのスキャナーは、その出力を処理する十分な能力を持つプロジェクトを対象にしている。この条件は重要だ。チームが評価できるより速くレポートが蓄積すれば、スキャン頻度は有害になりうるからだ。
高品質なレポートにも運用コストがある。誰かが担当し、サポート対象の環境でテストし、リリース済みのバージョンに影響するかを判断し、解決内容を文書化しなければならない。
自動生成されたパッチには、別のレビュー義務が生じる。提供された概念実証を阻止しても、根本的な弱点に対処していない変更である可能性がある。また、互換性を損なったり、性能を下げたり、コードベースの他の場所にある前提を破ったりすることもある。
モデルが完全な運用コンテキストを持たない場合、このリスクは大きくなる。リポジトリへのアクセスによりコードやテストは確認できても、すべてのデプロイパターンや下流での変更を捉えられるとは限らない。
脅威モデルはその隔たりを縮められる。Anthropicは、セキュリティ境界、信頼される入力、重要な資産を記述した脅威モデルファイルをプロジェクトが提供できるようにしている。しかし、正確な脅威モデルを維持すること自体が継続的な作業だ。
レポートの優先順位付けも同様の課題をもたらす。クリティカルと分類された欠陥でも、ごく一部の利用者しか有効にしていない設定を必要とするかもしれない。低い評価の問題が、広く公開されるコンポーネントに存在するため、より重要になる場合もある。
Anthropicは、レポートに不正確な深刻度評価が含まれる可能性があるとしている。つまり、プロジェクトはモデルのラベルをそのままリリースの優先順位へ安全に変換することはできない。
重複にも注意が必要だ。Anthropicの検証では、既知の問題や他のスキャン結果と重複する実際の問題が11件見つかった。規模が大きくなると、繰り返し現れるバリエーションは、個別の修正作業を意味しないまま、バックログが増えているように見せる可能性がある。
プロジェクトには、重複排除のルール、担当経路、明確な完了記録が必要になる。新たな脆弱性と、既存の根本原因の別表現を区別しなければならない。
スキャナーの隔離モデルは、別の懸念にも対処する。オンラインでビルドし、その後インターネット接続なしでスキャンすることで、モデルが制御する環境が外部システムへ到達できる範囲を制限する。ただし、サプライチェーンやビルド時のリスクをすべて排除するわけではない。
プロジェクトのDockerfileと依存関係は、何がビルド環境に入るかを依然として左右する。メンテナーは、継続的インテグレーションのワークフローと同じ慎重さで、登録設定を確認する必要がある。
したがって、最も有用な導入指標は検出件数ではなく、修正完了の数になる。もっともらしい問題を数千件特定するスキャナーでも、プロジェクトが検証して解決できなければ、運用面では失敗しうる。
ここに、このローンチの中心的な逆説がある。AIはコードを検索する限界コストを下げる一方、責任あるセキュリティ判断を下せるメンテナーの相対的な価値を高める。
OpenAIとGoogle、信頼できるパッチへの道筋で競争
Anthropicにとっての真の競争相手は、最長のアラート一覧を生成するスキャナーではなく、発見・検証・修正を組み合わせるシステムだ。
OpenAIは2026年3月、Codex Securityをリサーチプレビューとして発表した。このアプリケーションセキュリティエージェントは、リポジトリの文脈を構築し、疑わしい脆弱性を調査し、修正案を提示する。
OpenAIは、自動検証とノイズの少ない結果を重視している。同社の目標は、セキュリティチームが弱いアラートの却下に大半の時間を費やすことなく、対応できる検出結果を提示することだ。
同社はまた、オープンソースのメンテナーをCodex for OSSに迎えている。このプログラムは、セキュリティ支援とコーディングツールへのアクセスを提供する。
8月までに、OpenAIはCodex Security Cloudが3万以上のコードベースにまたがる3,000万件超のコミットを分析したと発表した。より広範なDaybreakの取り組みでは、リポジトリスキャンをプルリクエストレビュー、定期チェック、問題調査、既存のセキュリティシステムと結び付けている。
したがって、Codex Security previewは、Anthropicのアプローチに対する、より統合された競合といえる。両社とも、自社モデルは既知のパターンに一致させるだけでなく、コード全体を横断して推論できると主張している。
GoogleはBig SleepとCodeMenderを通じて、関連する戦略を追求している。Big Sleepはソフトウェア脆弱性の発見に注力し、CodeMenderはGeminiの推論能力を用いて修正を開発・検証する。
Googleには、OSS-Fuzzという長年にわたるオープンソースセキュリティの前例もある。このサービスは、プログラムに通常とは異なる入力を与えてクラッシュや危険な挙動を発見するファジングを継続的に適用する。
Anthropicは明示的にOSS-Fuzzを着想源として挙げている。この比較は有益だが、基盤となる手法は異なる。ファジングでは、特定の入力が障害を引き起こしたときに観測可能な証拠が得られる。言語モデルは、単純なクラッシュを生まない、より広範なロジック、権限、データフローについて推論できる。
この広い到達範囲は、より大きな解釈上の不確実性をもたらす。モデルは微妙な認可経路を追跡できるが、その結論は依然としてプロジェクトの実際のセキュリティ文脈で確認する必要がある。
GoogleのAI threat researchも、こうした製品の背景にあるデュアルユースの圧力を浮き彫りにしている。同社は、AIで開発されたとみられるゼロデイ脆弱性のエクスプロイトを利用する攻撃者を特定したと報告した。
Anthropicも同じ戦略的な主張をしている。高度なモデルが悪用を高速化するなら、攻撃者が未修正の弱点を利用する前に、防御側にも同等のアクセスが必要になる。
ベンダー間では、その優位性をどう提供するかが異なる。Anthropicは登録済みプロジェクトに対し、最強モデルからの直接かつ定期的な出力を提供する。OpenAIはリポジトリの文脈と検証を重視する。Googleは発見を自動修復と既存のセキュリティインフラに接続する。
現時点で、オープンソースプロジェクト全体で一つのアプローチが一貫して優れていることを示す公開証拠はない。ベンダーの集計値は、対象範囲、定義、重要度体系、レビュー手順が異なる。
検出件数には、重複、到達不能なコード、既知の問題、あるいは割り当て済みの脆弱性にならない欠陥が含まれる場合がある。パッチ件数も、メンテナーが却下した変更や大幅に書き直した変更を覆い隠す可能性がある。
信頼できる競争指標は、メンテナーを圧倒することなく、受け入れられた修正に至った、固有かつ有効な脆弱性の数だ。初回報告から安全なリリースまでの時間も同じくらい重要である。
この競争は、明確な勝者がいなくても、最終的にはオープンソースプロジェクトの利益になる可能性がある。複数のシステムが、異なる推論経路で同じ重要なコードを調査できる。独立した検出結果は信頼性を高めたり、別のスキャナーのカバレッジの穴を明らかにしたりできる。
ただし、並行するスキャナーは重複報告を増幅させる可能性もある。提供事業者は、開示慣行を調整し、プロジェクト固有の報告ルールを尊重する必要がある。
AIセキュリティの次の段階では、こうした運用上の境界を理解するツールが評価される。バグを見つけることには価値がある。責任あるチームが安全に解決できるよう支援することこそ、より難しいプロダクトである。
無料スキャンは、コストもリスクもゼロという意味ではない
OSS Scannerは、プロジェクトがAIの出力を権威あるセキュリティ判定ではなく、構造化された証拠として扱える場合に最も有用だ。
このサービスを利用する最も強い理由は明快だ。メンテナーは、通常であれば多大な計算資源とセキュリティ専門知識を必要とするモデルへ、定期的にアクセスできる。
レポートは、既存のテスト、静的解析ツール、ファザー、人間によるレビューで見逃された欠陥を明らかにする場合がある。再現手順は確認を迅速化し、候補パッチは修正の検討に必要な時間を短縮できる。
このサービスの非公開配信モデルは、プロジェクトに調査の余地も与える。Anthropicは生の検出結果を公開しないとしており、自動開示期限による圧力を軽減する。
それでも、いくつかの不確実性は残る。第一に、Anthropicは、言語、リポジトリ規模、脆弱性カテゴリごとに精度がどう変化するかを示すだけの本番データをまだ公表していない。
報告された協調開示の受理率88%は、選定された高重要度およびクリティカルの検出結果97件を対象としている。典型的なスキャンで生成されるすべての検出結果を測定したものではない。
第二に、モデルの改善はスキャナーの挙動を変えうる。新しいモデルは、より深い欠陥を見つけたり、より多くのレポートを生成したり、異なる重要度判断を下したりする可能性がある。プロジェクトには、スキャナーバージョン間で結果を比較する手段が必要になる。
第三に、生のモデル出力はセキュリティ上重要な誤りを生む可能性がある。不完全な再現手順では、主張された問題を証明できない場合がある。提案されたパッチは、根本の悪用経路を取り除かずに、一つの症状を抑えるだけかもしれない。
第四に、レポート自体が機密情報を含む。メール配信は便利だが、プロジェクトは悪用手順や影響を受けるコードパスを含むメッセージへのアクセスを管理しなければならない。
メンテナーは、検出結果を制限されたセキュリティプロセスに振り分けるべきだ。また、連絡先アドレスを確認し、判断を記録し、レポートを受理または却下した理由を文書化する必要がある。
第五に、このサービスはAnthropicの継続的な資金提供と運用上の選択に依存している。Defender Advantage Fundは現在、無料提供を支援しているが、同社は恒久的な提供を約束していない。
したがって、「無料」という言葉はサービス料金がないことを表すに過ぎない。メンテナーの時間、テストインフラ、協調リリース、下流への通知作業までは含まれない。
より広いガバナンス上の問題もある。Anthropicはモデルを運用し、スキャン手法を選び、初期段階で性能を評価する。独立した研究者と参加プロジェクトは、時間をかけてこれらの主張を検証する必要がある。
有用な公開証拠には、匿名化された適合率データ、重複率、パッチ受理率、修正時間の中央値が含まれる。プログラミング言語と脆弱性クラスごとの内訳があれば、これらの数値はより意味のあるものになる。
プロジェクトは、脆弱性の修正後に独自の評価を公開することもできる。こうした記録は、スキャナーが優れた性能を発揮する領域と、人間の調査者がなお作業の大部分を担う領域を明らかにできる。
これらの懸念はどれも、このサービスが本質的に安全でないことを意味しない。責任ある利用の条件を示している。
プロジェクトは、非公開の報告プロセス、対応可能なレビュー担当者、信頼できるテスト、リリースを調整する権限を備えている場合に登録すべきだ。これらの資源がないプロジェクトは、Anthropicの人間によるレビューを伴う開示経路の方が有益かもしれない。
選択は、AIを受け入れるかセキュリティを無視するかの二択ではない。異なるレビュー負荷、配信速度、信頼水準の間での選択である。
Anthropic OSS Scannerの有効性を示す三つのシグナル
今後数カ月は、見出しを飾る脆弱性総数ではなく、受け入れられた修正、メンテナーの対応能力、競合による検証で評価すべきだ。
第一のシグナルは、レポートから受け入れられたパッチへの転換率である。初期の証言は、一部のプロジェクトが利用可能な修正を受け取ったことを示唆しているが、より広範な本番結果の方が重要になる。
説得力のある実績では、固有の脆弱性と重複を分けて示す必要がある。また、候補パッチのうち、メンテナーが受け入れた、修正した、却下した、または置き換えた数も示すべきだ。
プロジェクトが未解決のセキュリティバックログを増やさずに、意味のある脆弱性をより速く解決できれば、このシグナルはAnthropicの主張を強める。未レビューのレポートが大規模なトリアージキューを生むなら、その主張は弱まる。
第二のシグナルは、確立されたオープンソースプロジェクトでの採用状況だ。登録用プルリクエストは可視的な指標になるが、リポジトリ数だけでは全体像を示せない。
件数が管理困難になれば、プロジェクトはスキャンを停止する可能性がある。公開設定は無効状態をサポートしており、参加チームが定期レポートを止める必要があるかどうかを示すことができる。
メンテナーのコメントは特に価値が高い。チームは、検出結果に十分な証拠が添えられていたか、重要度ラベルが有用だったか、パッチがレビュー工程を通過したかを説明できる。
プロジェクトが最初のバッチを処理した後もスキャンを受け続けるなら、採用はAnthropicのモデルを強く支持する。一度限りの試行の後に広範な停止が続けば、未解決の作業負荷問題を示唆する。
第三のシグナルは、OpenAI、Google、既存のセキュリティツールとの独立した比較だ。同じリポジトリから十分な数の公開開示が得られれば、カバレッジとレポート品質の違いが明らかになるはずだ。
公平な比較は、生の件数に頼ることはできない。研究者には、対応させたプロジェクト、共通の重要度定義、メンテナーからの確認が必要である。
異なるAIシステムが、固有かつ有効なバグを独立して発見するという証拠は、複数ツールによるセキュリティ戦略を支持する。重複が多いという証拠は、共有された報告・調整システムを求める圧力を高める。
競合側の対応も重要である。OpenAIはメンテナー向けの無料セキュリティ支援を拡大できる。GoogleはCodeMenderをOSS-Fuzzやオープンソースプロジェクトのワークフローとより緊密に結び付けられる。
Anthropicは、長期的なスキャナーデータを公表し、自動検証を強化することで、その立場を改善できる。また、プロジェクトによる重複排除、優先順位付け、テスト、修正追跡を支援するツールを追加することもできる。
同社はすでに、トリアージとパッチ作成の自動化を次の段階として挙げている。この取り組みが、OSS Scannerが発見エンジンにとどまるのか、完全な修正システムの一部になるのかを決めるだろう。
Anthropic OSS Scannerは、攻撃者が同等の優位性を得る前に、オープンソースのメンテナーへ高性能モデルへのアクセスを提供するという、もっともな提案から出発している。本当の試練は、最初の報告が届いた後に始まる。
参加を検討するメンテナーは、まず非公開開示のプロセス、レビュー体制、テストカバレッジ、リリース権限を評価すべきだ。そのうえで、生成されたアラート数ではなく、解決された脆弱性を測定する必要がある。Anthropicが小規模チームを圧倒することなく、プロジェクトが安全な修正をより迅速にリリースできるよう支援できれば、無料のAIスキャンは価値あるインフラとなるだろう。一方で、検証が依然として支配的なコストであり続けるなら、業界はこのスキャナーが浮き彫りにした人間側のボトルネックをなお解決しなければならない。
