OSS Scanner とは｜Anthropic が無料で提供するAI 脆弱性診断の登録手順と、届くレポートの信頼度

OSS の依存先を経由する攻撃と、それを防ぐ道具の全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。本記事は OSS Scanner に絞り、何か、どう登録するか、届いたレポートをどう読むかを、リポジトリの実物と公式の発表から確かめます。

OSS Scanner とは：OSV-Scanner・OSS-Fuzz・Claude Security との違い

「OSS Scanner」で検索すると、上位には Google の OSV-Scanner が並びます。名前は1文字違いですが、探すものが違います。AI 脆弱性診断の道具として並べて語られる Anthropic の Claude Security・/security-review や、Google の OSS-Fuzz とも比べます。

OSS Scanner に近いのは OSS-Fuzz です。Anthropic の発表は OSS-Fuzz に着想を得たと書き、受け入れの基準も OSS-Fuzz に似せています。登録の形も同じで、OSS-Fuzz も projects/<名前>/project.yaml を足す PR で申し込み、primary_contact に連絡先を書きます。

違いは開示の扱いです。OSS-Fuzz は作者に知らせてから90日後か修正の公開後の早い方で、報告を公開します。OSS Scanner はレポートを公開しません。

Anthropic は企業向けに Claude Security を出していますが、OSS Scanner はそれとは別に、OSS に無料で監査を出す枠だと発表で位置づけています。登録の審査を待たずに自分のリポジトリで Claude 脆弱性診断を回すなら、入口は Claude Security か /security-review です。ブランチ単位で見る /security-review の GitHub Action 版は、Claude Code Security Reviewとは｜PRを自動で守るGitHub Actionを実測で試しています。

なぜ人のレビューを外したのか

発表によると、Anthropic はこの半年で最新モデルを使い、29,000件を超える脆弱性の候補を見つけました。人の手で確かめられたのは約6,000件にとどまります。最初のレポートを受け取ったメンテナーから「未検証でもいいから全部送ってほしい」と頼まれることが増え、そうして送ったレポートは5,000件近くになったといいます。

OSS Scanner は、この「未検証でも早く欲しい」側のための近道です。人が確かめたレポートを送る従来の協調的な脆弱性開示（CVD）も続け、特にトリアージに手が回らないプロジェクトにはそちらで送るとしています。OSS Scanner のもとになった取り組みは、Project Glasswing初回成果報告とClaude Mythos Preview発表の記事で追っています。

OSS Scanner の仕組み：ネットありでビルドし、ネットなしで解析する

登録の PR がマージされると、次の順で動きます（README）。

リポジトリの tools/check_build.py には、スキャナーがプロジェクトに割り当てる資源が書かれています。ビルドの制限時間は clone から完成まで45分、ビルド用のマシンは16 CPU・メモリ64GB・ディスク120GB、解析を受け持つエージェントのマシンは2 CPU・メモリ8GBです。ビルドしたイメージの上に、スキャナーが Claude Code・コンパイラ・デバッガの層を足します。

レポートの中身は、発表によると、単体で動く再現コード、脆弱性の説明（できる場合はバグが入った時点の二分探索を含む）、修正パッチの候補（ある場合）です。

公開されていないこともあります。スキャンの頻度と、1プロジェクトにかける予算です。リポジトリの tools/validate.py は、cadence・budget などの項目を「運営側が決めるもの」として project.yaml に書くと弾きます。スキャンの向きを変えたいときは、threat_model.md で伝える設計です。

OSS Scanner の登録のしかた：project.yaml・Dockerfile・threat_model.md

3つのファイル

Dockerfile を自分のリポジトリに置けば、ビルドを変えるたびにこのリポジトリへ PR を出さずに済みます。

project.yaml のメールアドレスは公開されます。 セキュリティ用の別名を使ってください。PGP の公開鍵を pgp: に入れると、レポートは暗号化されて primary_contact だけに届きます。この場合 auto_ccs とは併用できません。

手元で規則を確かめる

PR の前に tools/validate.py を回すよう README が勧めています。テンプレートをそのまま projects/example/ に置き、2026年10月20日に実行しました。必要なのは git と Python 3、PyYAML です。

git clone https://github.com/anthropics/oss-scanner.git
cd oss-scanner
python3 -m venv ../oss-scanner-venv && . ../oss-scanner-venv/bin/activate
pip install pyyaml
mkdir projects/example
cp templates/project.yaml projects/example/
python3 tools/validate.py | grep -E '^ok|example'
# ok: 128 project(s)
#   example                  https://github.com/example/project#main  -> [email protected]  (Dockerfile: in the repository at .oss-scanner/Dockerfile)

validate.py は引数を取らず、projects/ の全件を見ます。128件は、登録済みの127件に example を足した数です。

テンプレートの dockerfile: 行を残したまま Dockerfile も横に置くと、置き場所が二重になって落ちます。横に置くならこの行を消す、とテンプレートのコメントにあります。

cp templates/Dockerfile projects/example/
python3 tools/validate.py; echo "exit=$?"
# example: Dockerfile is given both beside project.yaml and as dockerfile: in your repository — one place only
# exit=1

ほかに試して落ちたのは、primary_contact を消したとき（missing primary_contact）、pgp: と auto_ccs を両方書いたとき、Dockerfile がどこにも無いとき（dockerfile: を消して横にも置かない）です。どれも終了コード1でした。

validate.py が見るのは書式と置き場所だけです。ok と出ても、dockerfile: のパスに実物があるか、ビルドが通るかまでは見ていないので、スキャナーでビルドできるとは限りません。それを確かめるのが tools/check <名前> で、スキャナーと同じ手順でビルドし、ネットワークを切ったシェルを開きます。規則の確認・clone・Dockerfile の配置までは動くことを確かめましたが、ビルドの完了は未検証です。README の注意どおり、tools/check は Dockerfile をネットワークありで実行し、イメージに Claude Code を入れます。信頼できるプロジェクトだけで使ってください。

PR で求められること

PR のテンプレートには、確認のチェック欄が並びます。コアメンテナーであること、規約への同意、受け入れ基準を満たすと考えていること、validate.py と tools/check を通したことなどです。規約への同意の欄は、チェックが入るまで GitHub Actions が失敗させます。初回は CLA への署名もコメントで求められます。

PR には、★数・フォーク数・ライセンス・ダウンロード数の順位・SECURITY.md の連絡先などを集めたコメントが自動で付きます。ワークフローの説明では、これはレビューの材料で、可否を決めるものではありません。

止めるときは disabled: true、やめるときは projects/<名前>/ を消す PR を出します。このリポジトリは、登録・変更・停止・取り下げの PR だけを受け付けます。

届いた OSS Scanner のレポートをどこまで信じるか

数字は Anthropic の発表にある検証です。初期版のスキャナーが48プロジェクトで出した critical・high の97件を、同社の CVD の指摘を確かめているペネトレーションテスターが見ました。85件（88%）が CVD に回せる水準で、残り12件のうち11件は本物でも重複、無効は1件でした。

この数字を読むときの前提は3つあります。

・対象は critical・high だけ。medium 以下の精度は示されていない
・初期版での検証。今のスキャナーと同じとは限らない
・88% は「開示に回せる」の割合で、深刻度まで合っていた割合ではない。Anthropic は、深刻度が高めに付く、プロジェクトの脅威モデルを取り違える、という声をメンテナーから受けていると書いている

発表には、試験運用に参加したメンテナーの声もあります。wolfSSL は受け取った74件のうち2件を除いて有効で、5件が CVE になったとしています。curl の Daniel Stenberg 氏は、ここ数年で最悪級の curl の脆弱性を含む複数の問題が見つかったと述べています。

届いたあとに決めること

人のレビューが無く、90日の期限も無いので、仕分けと開示の段取りはメンテナーが持ちます。

深刻度の基準を先に書いておくほど、仕分けが楽になります。登録済みのプロジェクトが置いた threat_model.md には、たとえば OpenSSH の「バッファオーバーフロー・use-after-free・二重解放は最低でも high、sshd の認証回避は critical、DoS はすべて medium」のような書き方があります。

発表は、脆弱性の修正などに使えるものとして、OSS 向けに Claude Max 20x を無料で提供する Claude for OSS も案内しています。

登録済みの127件と、OSS Scanner が向いているプロジェクト

リポジトリの projects/ を2026年10月20日に数えた結果です。リポジトリの最初のコミットは発表と同じ10月8日です。

このリポジトリに置かれた threat_model.md 80件は、13〜284行で、中央値は80行です。

向いているのは、次の条件がそろうプロジェクトです。

・ネットワーク越しの入力や信頼しないファイルを扱い、多くの利用者や他のプロジェクトが依存している
・Docker でビルドとテストが45分以内に終わり、解析中にネットワークが要らない
・未検証のレポートを受け取り、自分で再現と仕分けをする人手がある

逆に、トリアージの人手が無いプロジェクトは、人が確かめたレポートだけを受け取れる従来の CVD の方が合うと Anthropic 自身が書いています。コアメンテナーでない人は、依存先のプロジェクトを代わりに登録できません。

OSS を使う側にとっては、依存先が projects/ に載っていても、届くものも見えるものもありません。変わるのは、メンテナーに修正の材料が早く届くことです。手元で見るべきものは今までと同じで、依存先の既知の脆弱性をnpm audit の結果はどれから直す？依存関係の脆弱性を到達性・EPSS・KEVで仕分ける実践手順のように仕分けて直します。

参照ソース

・Anthropic: Launching an opt-in vulnerability-finding service for open-source software（2026-10-08）
・OSS Scanner（Anthropic Frontier Red Team）
・OSS Scanner terms
・anthropics/oss-scanner（README・templates・tools・projects。2026-10-20 確認、Apache-2.0）
・google/osv-scanner README
・OSS-Fuzz: Accepting new projects
・OSS-Fuzz: Bug disclosure guidelines
・Claude Code Docs: Scan your codebase for vulnerabilities（Claude Security）