Anthropic OSS Scannerとは — OSSが無料で受ける脆弱性スキャンと申込手順

AnthropicのFrontier Red Teamは2026年10月8日、OSS Scannerを公開しました。オープンソースプロジェクトが自分で申し込むと、最上位クラスのモデル(Claude Mythosを含む)が定期的にコードをスキャンし、脆弱性の報告を無料で届けるサービスです。報告は人のレビューを通さず、モデルの出力がそのままメールで届きます。

要点

• OSS Scannerは申込制で、参加したプロジェクトは定期スキャンを無料で受けられる
• 報告には再現コード、脆弱性の説明、修正パッチ(可能な場合)が付く。バグが入った時期の特定(bisect)も、できる範囲で付く
• 報告は人の目を通らないため、誤りや深刻度の過大評価が混ざることがある
• 人のレビューがない報告には、90日の開示猶予を設けず、公開もしない
• 申込はGitHubのリポジトリへのPRで行い、適格性は個別に判断される

申し込む側は何を用意し、何を受け取るか

OSS Scannerに参加できるのは、プロジェクトのコアメンテナーです。申込はanthropics/oss-scannerリポジトリに、projects/<プロジェクト名>/ディレクトリを1つ追加するPRを送る形で行います。このリポジトリが受け付けるのは参加登録のPRだけで、tools/やtemplates/への変更提案は受け付けていません。申込にはOSS Scannerの利用規約(Terms & Conditions)への同意も必要です。

設定ファイルの中身

必須なのはproject.yamlと、ビルド手順を書いたDockerfileです。Dockerfileは自分のリポジトリに置くか、project.yamlの隣に置くかを選べます。自分のリポジトリに置くと、ビルド手順の更新にPRが要らなくなるため、こちらを勧めています。

project.yamlの例です(テンプレートの記述に沿った形)。

repo: https://github.com/example/project   # 必須。#ブランチ名で固定も可
primary_contact: security@example.org      # 必須。報告とビルドエラーの宛先
auto_ccs:                                  # 任意。全メールのCC
  - maintainer@example.org
homepage: https://example.org              # 任意
disabled: false                            # 任意。trueで報告を一時停止
dockerfile: .oss-scanner/Dockerfile        # 隣に置くなら不要
threat_model: .oss-scanner/threat_model.md # 任意

ここに書いたメールアドレスは公開される点に注意が要ります。セキュリティ用のエイリアスなど、公開されてよい宛先を使う設計です。報告を暗号化して受けたい場合はpgp欄にOpenPGPの公開鍵を入れますが、その場合はauto_ccsと併用できず、宛先はprimary_contactだけになります。

threat_model.mdは任意ですが、強く推奨されています。書いておくと、スキャナが深刻度の付け方やテスト対象の範囲を推測で補わずに済みます。次のような内容を書けます。

• 何を守るコードか、どこから信頼できない入力が入るか、対象外はどこか
• 深刻度の基準(認証後のSQLインジェクションはhighかcriticalか、など)
• 報告やパッチの書式、再現コードの種類の希望
• 重複排除をどの粒度で行うか

ファイルを自分のリポジトリに置けば、スキャンの合間に書き換えて報告の形式を調整できます。

申し込む前の手元確認

リポジトリには検証用のツールがあります。

# 設定ファイルが規則に合っているか検査する
tools/validate.py
 
# スキャナと同じ手順でビルドし、ネットワークなしのシェルを開く
tools/check <project>
 
# 仮想マシン上で、スキャナの構成に近い形で試す(Linux x86-64とQEMUが必要)
tools/check --qemu <project>

手元にはgit、Docker、PyYAMLを入れたPython 3が必要です。ビルド済みイメージの中でテストが通れば、スキャナも動く見込みが高いとされています。tools/checkはスキャナと同様にClaude Codeをイメージに導入します。Dockerfileはネットワークにつながった状態で実行されます。信頼できるプロジェクトだけを対象にするか、壊れても困らない環境で動かす前提のツールです。--qemuを使っても、手元のサービスやローカルネットワークには届きます。

マージ後の流れ

初回スキャンの後も定期的にスキャンされます。前回以降に入った新しい脆弱性と、以前に見逃した脆弱性が対象です。頻度は、パイプラインに載るプロジェクトの数や利用の広がりなどで変わります。パイプラインにはバグの再確認、パッチ案の作成、根本原因の分析を担うエージェントが含まれます。

誰が参加できるのか

適格性は、GoogleのOSS-Fuzzに近い基準で個別に判断されます。OSS-Fuzzの基準は、インフラとユーザーのセキュリティに決定的な影響を持つ、定着したプロジェクトを受け入れるというものです。Anthropicが挙げる判断材料は2つです。

重要性が自明でないプロジェクトは、PRに重要性を一文添えることが勧められています。応募数が読めないため、基準は今後変わる可能性があります。セキュリティ上の理由から、登録前にコアメンテナー本人であることを手作業で確認し、必要なら別の経路でも連絡を取ります。

もう一つ、サービスの前提条件があります。OSS Scannerは、検証済みのhigh・critical級の報告にすでに追従できているプロジェクトが、さらに守りを固めるためのものです。報告が多すぎて手が回っていないプロジェクトは、無理に参加する必要はありません。その場合も、Anthropicが人の検証を経た報告を協調的な脆弱性開示(CVD)の手続きで届ける取り組みは続きます。

OSS Scannerの開示ポリシーと、やめたいときの手順

OSS Scannerの報告には、通常のCVDで使う90日の開示猶予を設けません。人が検証していない報告には誤りが含まれることがあるため、メンテナーに1件ずつ読む負担を強いるのは適切でないという考え方です。報告をAnthropicが公開することもありません。

例外は2つあります。

• 後から人が手作業で検証した報告は、メンテナーへ検証済みと通知した日から90日後に、CVDの方針で公開することがある
• 信頼性が高まれば、将来は一部の高深刻度の報告に開示猶予を課す可能性がある。その場合は十分な予告とオプトアウトの選択肢を示す

報告を止めたいときは、設定ファイルにdisabled: trueを足すPRで一時停止できます。projects/<プロジェクト名>/ごと消すPRなら、登録を完全に取り下げられます。どちらの場合も、自動の未検証報告は止まり、標準のCVDによる報告だけが残ります。

報告の取り扱いについては次のとおりです。

• 報告は、Anthropicのセキュリティ担当者のうち必要な者だけがアクセスできる隔離されたクラウド環境に保管される
• スキャン用エージェントは、強化されたサンドボックスの中でインターネット接続を完全に切ってから動かす
• 報告へのフィードバックは、届いたメールに返信する形で送れる
• 修正コミットにクレジットを書くことは必須ではない。書くなら、報告のIDを入れてほしいとされ、効果の集計に使われる

発表の数字は何を示しているか

OSS Scannerの設計は、見つかった数と人が見られた数の差から出ています。見つかった候補の約8割は、人の目を通らないまま残りました。それでもメンテナーの側から「未検証でいいから全部ほしい」という要望が増え、5000件近くを未検証のまま直接送りました。人手のレビューを外した速い経路を、正式な申込制サービスにしたのがOSS Scannerです。

早期版の検証結果

発表は、早期版のスキャナで出た重大な指摘を、専門のペネトレーションテスターに確認してもらった結果を載せています。

97件のうち、本物でなかったのは1件です。一方で、メンテナーからは深刻度が高めに付けられている、プロジェクトの脅威モデルをスキャナが取り違えたという声も届いています。完全であるとは保証できず、メンテナーの反応とモデルの進歩に合わせて改善していくとしています。

同社の別の発表(Anthropic Cyber Mission)は、真陽性率は90%を超える見込みと述べています。上の表は早期版かつcritical・highの指摘に限った検証で、この見込みの根拠そのものではありません。

メンテナーの声

発表に載った感想から、報告の質に関する部分を拾います。

• PostgreSQL(Noah Misch氏):ほぼそのまま使える修正が付いた報告があり、GA(正式版)に入る前に新しい問題へ対処できた
• OpenSSL Corporation(Anton Arapov氏):約18か月前のAI報告は粗かったが、今回の報告は「生のモデル出力」で送られたものを含め、人が書くものと同等かそれ以上だった。実際に動く攻撃コードが付いていれば、エンジニアはすぐ検証できる
• wolfSSL(Todd Ouska氏)が受け取った74件は、2件を除いて有効で、うち5件がCVEになった
• HotCRP(Eddie Kohler氏)の評価は、複雑な権限モデルの理解が深く、優先順位の付け方も良かったというもの
• curlでは、対処に値する複数の問題が見つかり、近年で最悪級の脆弱性も含まれていた(Daniel Stenberg氏)

導入前の検証でも、複数の脆弱性を連鎖させて、認証なしのリモートコード実行まで持ち込める攻撃が見つかっています。スキャンした数十のオープンソースプロジェクトで、最初の開示に数百件のバグ報告が含まれていました。

Claude Securityや無料プログラムとの違い

OSS Scannerの隣には、似た名前の施策がいくつかあります。対象と費用の面で比べます。

Claude Securityとの違いについて、FAQは次の点を挙げています。OSS Scannerは多様なハーネス(モデルを動かす枠組み)と手法を使い、多くのトークンを使う実験的なハーネスも加えて、より深いバグを狙います。その費用はすべてAnthropicが持ちます。Claude Securityの仕組みはClaude Securityの解説に、脆弱性の分類は深刻度の判定基準の記事にあります。

無料のMax 20xの条件はClaude for Open Sourceの解説に、専門家向けの審査段階はCyber Verification Programの拡大にまとめています。

受け取る側に残る仕事は何か

OSS Scannerが速く届ける代わりに手放したものは、人による選別です。その選別はなくなったわけではなく、受け取るメンテナーの側へ移ります。

発表の数字から言えるのは、次のことです。深刻度の見立てが外れることがある以上、報告の優先順位を決める基準を渡しておく価値は大きくなります。threat_model.mdに深刻度の基準を書ける欄があるのは、この弱点を受け手側で補うためです。報告を受ける体制のないプロジェクトが参加すると、メールの山をかえって増やす結果になります。FAQが、手が回らないプロジェクトに無理な参加を勧めていないのは、この負担を見越した書き方です。

一方で、開示猶予を課さない設計は、攻撃者に先んじて直すための時間をメンテナーに渡す意味も持ちます。エクスプロイトが数分で作れる今、脆弱性を早く見つけて直せるプロジェクトほど守りやすくなります。報告を非公開で保つのも、その速さを活かすための条件です。

背景にあるのは、Project Glasswingでの経験です。見つけること自体は容易になり、検証と修正が詰まるようになりました。OSS Scannerは、その詰まりのうち「検証」の部分を、受け手の側に開くための仕組みと言えます。同じ週に始まった取り組み全体の位置づけは、Anthropic Cyber Missionの解説で扱っています。

まとめ

OSSに依存するだけの開発者に、直接の設定変更はありません。依存先の脆弱性が早く見つかり、直る可能性が上がるという間接的な影響にとどまります。

メンテナーにとって参加するかどうかの目安は、検証済みのhigh・critical級の報告にすでに追いつけているかどうかです。適格かどうかは、これとは別にAnthropicが個別に判断します。今後は、適格基準の見直しや、高深刻度の報告への開示猶予の導入が、予告つきで行われる可能性があります。