Anthropic OSS Scannerの使い方

Anthropic OSS Scannerは、参加条件を満たすオープンソースプロジェクト向けの、申請制の無料脆弱性スキャンサービスです。 2026年10月8日に発表され、登録済みのリポジトリをAnthropicの最も高性能なモデルで定期的に調べ、結果をメンテナーにメールで送ります。ただし、報告はAnthropicの担当者による確認を経ずに届きます。内容の検証と優先順位の判断は、プロジェクト側の仕事です。

重要なライブラリやアプリケーションを保守し、報告を調査する余力がある場合は、まず公式FAQを確認してください。申請はAnthropicのリポジトリへのプルリクエストで行います。ツールのダウンロードやAPIキーの購入だけでは登録されません。

どのプロジェクトが対象になる？

AnthropicはOSS-Fuzzに近い基準で、インフラと利用者の安全に重要な影響を持つ、実績のあるプロジェクトを個別に審査します。信頼できない入力を処理するなど遠隔攻撃にさらされる可能性や、利用者・依存プロジェクトの数が判断材料です。FAQには、一定のスター数で自動的に採用される基準はありません。

申請できるのは主要メンテナーで、Anthropicがその立場を確認します。申請ではプロジェクトの重要性を簡潔に説明し、セキュリティ窓口を担当する人を決めておきます。FAQが想定するのは、深刻度が「高」または「重大」の、検証済み報告に既に対応できているチームです。スキャンは無料でも、調査・修正・リリースには人の時間が必要です。

Claude SecurityやClaude Codeとの違い

関連する作業を扱うサービスでも、利用経路と結果の受け取り方は異なります。OSS ScannerのFAQとClaude Code Security Reviewerのリポジトリを整理すると、次のようになります。

発表時の研究記事では、Claude Mythosを含む最も高性能なモデルを使うと説明されています。これはスキャン内部の構成を示すもので、モデルのダウンロードや汎用のMythos API利用権を与えるものではありません。公開リポジトリには登録設定と準備用ツールがあり、ホスト型スキャナー全体をローカルで再現する手順は示されていません。

登録までの手順

1. ビルド環境と連絡先を準備する

リポジトリの説明と参加手順を読み、依存関係のインストールとビルドを行うDockerfileを用意します。ビルド時は通信できますが、その後のセキュリティ監査はオフラインです。 テストに必要なものは準備段階で取得し、構築後の環境でネット接続なしにテストできるか確認します。

登録ファイルのメールアドレスは公開されます。公開可能なセキュリティ窓口のアドレスが適しています。pgpに公開鍵を指定して暗号化を求める場合、宛先はprimary_contactだけになり、auto_ccsは併用できません。

2. 登録設定を追加する

Anthropicのリポジトリをフォークし、公式テンプレートからprojects/my-project/project.yamlを作成します。次の最小例は、ビルド用ファイルと脅威モデルを自分のプロジェクト側に置く構成です。例のリポジトリと連絡先を置き換え、参照先のファイルを用意してください。

repo: https://github.com/example/project#main
primary_contact: security@example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md

キーはテンプレートと検証コードにある小文字の**dockerfile**を使います。代わりに登録設定の隣へDockerfileを置く場合は、dockerfileフィールドを省略します。配置方法は一方だけを選びます。スキャン対象のGitリポジトリはGitHub以外でも構いません。

任意のthreat_modelファイルには、信頼できない入力、セキュリティ境界、対象外の挙動、深刻度の基準、有用な再現手順やパッチの条件を書けます。想定する挙動を伝える助けになりますが、モデルが常に正しく解釈する保証ではありません。

3. 設定とオフライン環境を確認する

登録用リポジトリのローカルコピーのルートで使う準備コマンドは次のとおりです。

python3 tools/validate.py
tools/check my-project

最初のコマンドは登録設定を検証します。次のコマンドはビルド後にネットワークを無効にしたシェルを開くので、そこでテストを実行できます。公式手順にはGit、Docker、PyYAMLを導入したPython 3が必要とあります。ビルド時は通信できるため、信頼できるプロジェクト定義だけを使ってください。本稿では公式のコマンドと照合しており、スキャナーの試用として実行したわけではありません。

4. 登録のプルリクエストを送る

1件のPRに1プロジェクトを含め、チェックリストを記入し、利用規約と貢献者契約の手続きに従います。採用前にAnthropicが主要メンテナーであることを確認します。採用後、同社の環境でビルドできなければ主連絡先へ通知されます。

初回以降も、新しく混入した問題や過去のスキャンで見落とした脆弱性を探します。毎日・毎週といった固定周期の保証はありません。 FAQでは処理待ちの件数、プロジェクトの利用状況などによって頻度が変わるとしています。

報告の内容と数値の読み方

報告には再現手順と脆弱性の説明があり、用意できる場合は修正候補が付きます。問題が入った時点を二分探索で特定することもあります。エージェントによる再確認は含まれますが、人による検証とは別です。深刻度の過大評価、既知の問題との重複、脅威モデルの誤解が起こり得ます。

発表時の検証では、48プロジェクトから選ばれた、深刻度が「高」または「重大」の97件を抽出し、85件がCVDの基準を満たし、11件は実在する問題の重複、1件は無効でした。選ばれた初期サンプルの結果であり、全深刻度にわたる独立した精度評価ではありません。見逃した脆弱性の数も測っていません。

Cyber Mission発表の**「真陽性率90%超」は予測であり、サービス保証ではありません**。自分のプロジェクトでは、確認できた問題、重複、深刻度の誤り、無効な報告を分けて集計すると判断しやすくなります。

メンテナー向けの報告処理手順

以下は本稿が提案する運用であり、Anthropicのサービス上の約束ではありません。

1. 担当と記録を決める。 閲覧を制限した安全な窓口で担当者を決め、報告ID、対象リビジョン、初期状態を記録します。
2. 再現し、重複を確認する。 隔離したテスト環境で再現手順を確認し、既存の勧告や非公開報告と照合します。重複でも問題自体は実在する場合があります。
3. 影響を判断する。 攻撃者が入力を制御できるか、サポート対象の構成で到達できるか、必要な権限は何かを確認し、プロジェクトの深刻度基準を適用します。
4. パッチをレビューしてリリースする。 変更を確認し、回帰テストと互換性検証を追加します。機微な情報を公開する前に、既存の安全管理手順で修正と勧告を調整します。

たとえば「重大」とされた問題でも、到達に管理者権限が必要なら、その前提を記録して影響を再評価します。最初の評価が誤っていたという理由だけで報告全体を捨てないことが大切です。繰り返される誤解は脅威モデルへ追記し、Anthropicへの返信でも伝えます。

公開方針・停止・よくある疑問

どの報告も90日後に公開される？

いいえ。FAQでは、未検証の報告に自動的な90日期限は設けないとしています。後から人が検証した場合は通常のCVD方針で公開される可能性があり、期間は人による検証を通知された時点から始まります。永久に公開されないという約束ではありません。

一時停止や退会はできる？

PRでdisabled: trueを設定すると報告を停止でき、登録ディレクトリを削除すると退会できます。退会後も、通常の人が確認したCVD報告が届く可能性はあります。FAQは、将来の公開方針変更には事前通知と退出の選択肢を設けるとしています。

無料なら他の検査をやめてよい？

採用されたプロジェクトのスキャン費用はAnthropicが負担します。ただし、依存関係の検査、テスト、人によるセキュリティレビューは併用することを勧めます。公表された結果は全脆弱性の検出を証明していません。追加の報告を受けても運用を圧迫せず、確認済みの修正につなげられるかが判断の軸です。

OmniaKeyを使う場面

別途行う開発・修正作業では、Claude Codeの設定ガイドと、現在の選択肢を示すモデル一覧を参照できます。OSS Scannerの登録先はAnthropicです。OmniaKeyのアカウントで、このサービスや内部モデルを利用できるわけではありません。