Tech Teardown 024｜oss-scanner：Anthropic 公式脆弱性スキャンリポジトリ、5日で960スター、中にスキャナーのコードは1行もない

10月8日、Anthropicの公式アカウント「anthropics」がGitHub上で新しいオススキャナー（oss-scanner）のリポジトリを開設しました。5日間で960個以上の星を獲得しました（10-14のスナップショット、リポジトリの開設から5日後）。Pull Requestの番号は#598まで上がっています。この注目度はコミュニティの議論からではなく、3つの要因によるものです：公式発表、76の重要なオープンソースプロジェクトの自発的な登録、そしてPostgreSQL、OpenSSL、wolfSSL、curl、HotCRPのメンテナーが発表文に寄せた証言。さらに興味深いのはリポジトリ自体です：184ファイルを調べても、実行時の脆弱性スキャンを行うコードは一つも見つかりませんでした。これはスキャンサービスのレジストリであり、スキャナーはAnthropicのサーバー上に残されています。昨日の「anatomy」ではエージェントエコシステムの出力層を分解しましたが、今日はセキュリティ層を扱います。2回にわたる解説は、AI企業がオープンソース基盤構築に介入する2つの側面です。この記事では従来の方法で6つのセクションに分けて解説します。

一、それは何か

まず、核心的な判断を最前面に置きます：oss-scannerのリポジトリ本体はスキャナーのコードではなく、「レジストリ＋設定プロトコル＋自己検査ツール」の3つセットです。スキャナー本体はサービス側で動作し、オープンソースではありません。オープンソース部分が解決するのは別の問題です：オープンソースプロジェクトがどのようにこのスキャナーに自分を委ねるか、そして提供前にどのように自己検査を行うかです。

サービス自体はAnthropicが重要なオープンソースプロジェクトに対して提供する無料の脆弱性スキャンで、opt-in制であり、プロジェクトが自発的に登録した場合のみスキャンされます。使用はred.anthropic.com/oss-scanner上のサービス利用規約によって制限されます。公式発表文では非常に明確に述べられており、インスピレーションの源はGoogleのOSS-Fuzzで、fuzzerに最強の言語モデル（Claude Mythosを含む）を使用しています。その前身はAnthropic内部でClaudeを使用して脆弱性を探すProject Glasswingであり、6000以上のレポートを手動でレビューしたCVDプロセスです。企業向け有料製品Claude Securityとの役割分担も明確にされています：OSS Scannerはオープンソースプロジェクトに無料で提供され、商業顧客は別の経路を通じてサービスを受けます。

したがって、このリポジトリの形態については特別に言及する価値があります：AI企業がオープンソースのセキュリティ基盤構築を行う際、オープンソースとして提供されるのはモデルやスキャナーではなく、接続プロトコルです。これは従来のセキュリティツールが「コード即ち製品」というオープンソース方式とは全く異なります。レジストリが公開されているということは、誰がスキャン対象かが明確であり、スキャナーが閉鎖的であるということは、どのようにスキャンするかがブラックボックスであり、透明性が半分に切り分けられています。

二、リポジトリの構造

リポジトリには合計184ファイルがあります（.gitを含まない）、そのうち80ファイルはyaml、51ファイルはmd、4ファイルはpyで、Apache-2.0ライセンスが適用されています。

主体は projects/ 下の76のプロジェクトディレクトリで、各ディレクトリが一つの登録ファイルです。リストの質は非常に高い：openssl、cpython、spidermonkey（FirefoxのJSエンジン）、nss（Mozillaの暗号化ライブラリ）、homebrew、drupal、grafana、rabbitmq、jupyterlab、nestjs、valkey（Redisのサブセット）、uutils-coreutils、lvm2、cryptsetup；セキュリティツールにはnuclei、grype、syft、zmap、radare2、ossec-hids、go-tuf、tinyssh、botanがあります。AIプロジェクトもいくつか含まれており、unsloth、autogpt、gooseが含まれ、Anthropic自身のclaude-code-templatesも登録されています。注意すべきは、curlの本体はリストに含まれていないことですが、発表文にはcurlのメンテナーDaniel Stenbergの証言があります。

各ファイルの核心はproject.yamlで、2つの必須フィールドがあります：repo（gitリポジトリのアドレス、#branchを使用してブランチをロックすることができます）とprimary_contact（報告を受け取るメールアドレス）。オプションにはdockerfile、threat_model、auto_ccs、pgp、disabled、homepageが含まれます。opensslのサンプルは非常に代表的です：repoはopenssl/opensslを指し、masterをロックしています。primary_contactは個人アドレスではなくopenssl-security@グループのメールアドレスを使用しており、これはREADMEで強調されている「メールアドレスは公開されますので、securityという別名を使用してください」というルールの実例です。

ツールコードはtools/に集中しており、約1287行のPythonと142行のshellがあります：validate.pyは261行で設定ルールのチェックを行い、check_build.pyとcheck_qemu.pyはローカルビルドの自動チェックを担当します。templates/には設定テンプレートが置かれています。リポジトリの貢献に対する姿勢もREADMEの末尾に記載されています：projects/下の登録PRのみを受け付け、toolsとtemplatesの変更は一切受け付けません。5日間で598のPRがあり、ほとんどがプロジェクトの進行中です。

三、メカニズムの分解

全体のサービスプロセスは4ステップです：ビルド、ネット切断、スキャン、メール送信。プロジェクトはDockerfileを提供します（自分のリポジトリに置くか、登録ディレクトリの隣に置くか、どちらかを選択してください。前者の方が推奨されます。なぜなら、ビルドを変更する際にPRを送る必要がないからです）。スキャナーは隔離されたVM内でプロジェクトをビルドし、初期ビルド段階ではネット接続がありますが、セキュリティアクティビレーション段階に入ると完全にネット切断されます。スキャン結果はprimary_contactにメールで送信されます。各報告には3つの要素が含まれています：自己完結型のreproducer、脆弱性の説明（bisectionを使用して脆弱性が導入された時点を示す）、そして候補のパッチです。

報告は二つのチャネルに分かれています。一つはCVDチャネルで、人手によるレビューが行われます。もう一つはfast trackで、全モデルの生成が行われ、人手によるレビューは行われず、スキャンしたらすぐに公開されます。発表資料によると、既に約5000件の未検証なfast track報告が、全内容を要求したメンテナーに直接送られています（Anthropicの自己申告による）。この二つのチャネル設計では、「検証能力」を希少資源として配分しています。人手によるレビューが必要な場合は順番を待ち、時間がある人は自分でデータを取得します。

ネットワーク切断時のアナリシスにも注意が必要です。構築段階ではネットワークを開放して依存関係を引き出しますが、アナリシス段階ではネットワークを切断して、モデルが分析中に外部に接続するのを防ぎます。これにより、環境スキャンでプロジェクトコードや脆弱性の詳細が漏れるのを避け、モデルが自ら何かをダウンロードして分析を妨げるのも防ぎます。tools/checkはこの環境を忠実に再現しており、これが自己検査ツールとしての価値です。ローカルで見られる行動とサービス側の動作が一致します。

登録前のローカル自己検査は、リポジトリ内で最も実用的な部分です。tools/validate.pyはREADMEの登録規則をコードに変換しています：フィールドのホワイトリスト、httpsチェック、メール形式、PGP公開鍵形式、ファイルサイズの上限などです。また、workflow、budget、cadenceといったサービス運営者のみが設定できるフィールドを遮断します。tools/check<name>はスキャナーの同様の方法でプロジェクトを構築し、ネットワーク切断後の完成したミラーイメージでシェルを起動して、このコンテナ内で正常に動作するかをテストします。—qemuバリアントはx86-64 Linux上でQEMUを使用してスキャナーのVMレイアウトを再現します。validate.pyのドキュメントストリングには、サービス側のスキャナーとはコードを共有せず、規則の変更は両方で同期する必要があるという正直な声明もあります。

四、数字と検証

まずAnthropicの自己申告による核心数値を見てみましょう。以下はすべて自己申告によるものです。過去6ヶ月間、最新のモデルを使用して世界で最も重要なソフトウェアプロジェクトをスキャンし、29,000以上の候補脆弱性を発見しました。そのうち人手によるレビューが行われたのは約6,000件で、公式は人材不足ではなくモデルの問題だと認めています。学術ベンチマークであるCyberGymでは、LLMの脆弱性検出率が昨年初めの20％未満から今年は85％以上に上昇しました。

検証実験は数値の中で最も厳しい部分です：AnthropicはCVDプロセスに精通した渗透テストエキスパートを招いて、48件のプロジェクトで報告された97件のcritical/highレベルの脆弱性をレビューしました。その結果、85件（88％）がCVDの基準を満たしました。残りの12件のうち、11件は実際に存在するものの重複報告であり、真の偽陽性は1件だけでした（Anthropicの自己申告による）。

公式も弱点を隠していません：一部のメンテナーからは、深刻度評価が過大である可能性や、スキャナーがプロジェクトの脅威モデルを誤解している可能性があるとのフィードバックがありました。

Anthropicからの発表によるメンテナーの証言は以下の通りです。PostgreSQLのNoah Mischは、実際の欠陥が非常に高い割合で見つかっていると述べ、多くの報告書に添付されている修正はほぼ即座に使用できると言っています。OpenSSL CorporationのAnton Arapovは、18ヶ月前のAIの脆弱性報告はひどかったと比較し、今回の報告は人間の報告に匹敵し、さらにはそれ以上であると述べています。実際のエクスプロイトが添付されている報告は、エンジニアにとってまるで作業が完了したかのようです。wolfSSLのTodd Ouskaによると、74件の報告のうち2件だけ無効であり、5件がCVEになりました。curlのDaniel Stenbergは、近年最も深刻なcurlの脆弱性の一つがこの種のスキャンで発見されたと述べています。HotCRPのEddie Kohlerも背書リストに含まれています。これらの証言はすべてAnthropicの発表からのものであり、単方的な転述であり、信頼する際にはこの割引を考慮する必要があります。

五、判断

3点注意すべき点があります。

第一に、開示ポリシーの二重違反です。READMEの原文によると、報告はモデルによって生成され、人の手によるチェックが行われていないため、90日間の開示期間を設けず、公開もしていません。従来の脆弱性開示の慣例である2つの基盤がここで破壊されています。工学的な理由があります：報告が検証されていないため、90日間のタイムリングを適用すると、メンテナーが偽陽性でもカウントダウンを行うことになります。公開しないことで、検証されていない情報が攻撃者の手に渡ることを防ぎます。しかし、その代償は、外部世界がこのシステムが何を報告し、何を漏らしていないかを監査できないことであり、88%の達成率はAnthropic自身だけが計算できるものです。

第二に、トリアージのコストがメンテナーに移行されています。無料であることは事実ですが，README全体が報告が人の手によるチェックを受けていないと述べており、サービスはverifiedの高リスク報告を処理できる能力を持つプロジェクトを対象としています。OpenSSLやPostgreSQLのような専門のセキュリティチームを持つ大企業にとっては純粋な利益ですが、人員不足のプロジェクトにとっては、約5000件の未検証報告の直接配布は純粋な負担かもしれません。登録されている76件のプロジェクトはすべてハイリスクプロジェクトであり、このリストはサービスの位置づけの証拠です。これは非難ではなく、サービスの境界です：セキュリティ対応能力を持つプロジェクトのみが選別されており、これは外部のセキュリティ支援が最も必要なプロジェクトを排除しています。

第三に、設定チェックの二重実装の変化です。validate.pyはサービス側のスキャナーとコードを共有せず、ルールは手動で両側で同期されます。これは工学的には明確な技術的問題であり、規模が大きくなるほど「ローカルチェックが通過し、サービス側でのインポートに失敗する」という問題が起こりやすくなります。76件のプロジェクト、598件のPRを考えると、このルールを変更するたびに2箇所でコードの手動同期が必要です。

より大きな観点から見ると、このリポジトリは新しい形態を代表しています：AI企業はセキュリティ能力をサービスとして提供し、オープンソース化されているのは接続プロトコルとレジストリだけです。プロトコルはオープンですが、能力は閉鎖されており、OSS-Fuzzのような「インフラが完全にオープンソース」の前世代のモデルと比べて、透明性はイテレーション速度に譲るものです。メンテナーにとってこの交換が有益かどうかは、88%の達成率という自己申告の数字を信じるかどうか、およびセキュリティチームにどれだけの余力があるかに依存します。

六、誰が、どのように使用できるか

資格のハードルは高い：核心メンテナーの身分を確認する必要があり、さらにOSS-Fuzz方式の資格審査が行われ、プロジェクトが信頼できない入力を処理しているか、下流ユーザー数が十分に多いかを判断する。プロセス自体は簡単：PRを開き、projects/<name>/ディレクトリを追加し、project.yamlとDockerfile（または自分のリポジトリ内のパスを指す）を置き、マージ後にスキャナーが自動的にインポートする。

2つの実用的なアドバイス。1つ目として、threat_model.mdは選択可能だが、作成することを強く推奨する。READMEに記載されている正しい使い方では、重大度を明確に記述する：認証後のSQLインジェクションをhighと見なすかcriticalとし、エクスプロイトのデモンストレーションがないバッファオーバーフローはhighとして扱わないか、ストレージ型XSSはどのような条件下でアップグレードするかなどを明確にする。これらは、公式が認識している「重大度の過大評価」という弱点に対応している。2つ目として、登録前にtools/validate.pyとtools/checkを実行する。注意：checkはプロジェクトのDockerfileをネットワーク経由で実行する。READMEには自分が信頼するプロジェクトのみをチェックするか、損失のないマシンを使用するように警告する。報告書が漏洩することを防ぐため、pgp暗号化を使用できるが、暗号化後はprimary_contactにのみ報告書を送信し、auto_ccsと併用しないこと。非アップデートで一時停止したい場合は、disabledをtrueに設定する。

一般開発者にとって、このリポジトリは教材として役立つ：76件のproject.yamlはセキュリティコンタクトの設定におけるベストプラクティスのサンプルであり、validate.pyの261行は「ドキュメントのルールをチェッカーに書き換える」という清潔な例である。

情報源

• リポジトリとドキュメント：github.com/anthropics/oss-scannerのREADME、tools/validate.py、projects/ディレクトリの一覧およびopensslのサンプル設定（10-14のローカルスナップショット、ファイル数とコード行数はfind+wcで統計）
• 星の数、PR番号、プロジェクト数：GitHubページとAPI、10-14のスナップショット（リポジトリ作成日：2026-10-08）
• 主要数字（29,000/6,000/約5,000/88％/97中1は偽陽性/CyberGym検出率）：anthropic.comが発表した記事「Launching an opt-in vulnerability-finding service for open-source software」（2026-10-08）、すべてAnthropicが自己申告した内容で、本文は各所にマークされている
• メンテナーの証言（PostgreSQL/OpenSSL/wolfSSL/curl/HotCRP）：Anthropicが発表した記事のメンテナーの証言、本文は引用形式で処理されている
• 開示ポリシー、登録規則、自己チェックツールの使用法：READMEの原文