OSS Scanner 調査レポート

1. 基本情報

• ツール名: OSS Scanner
• ツールの読み方: オーエスエス スキャナー
• 開発元: Anthropic
• 公式サイト: https://red.anthropic.com/oss-scanner/
• 関連リンク:
  • GitHub: https://github.com/anthropics/oss-scanner
• カテゴリ: セキュリティ/脆弱性診断
• 概要: Anthropicが提供する、Claudeモデルを用いてオープンソースソフトウェアの脆弱性を自動で発見し、パッチを提案するオプトイン型のセキュリティスキャンサービス。

2. 目的と主な利用シーン

• 解決する課題: オープンソースソフトウェアにおける未知の脆弱性（ゼロデイなど）の発見と、メンテナーのトリアージ・パッチ作成の負担軽減。
• 想定利用者: 重要インフラやユーザーセキュリティに大きな影響を与えるオープンソースプロジェクトのコアメンテナー。
• 利用シーン:
  • オープンソースプロジェクトの定期的なセキュリティ監査
  • 最新のLLMモデルを用いた高度なバグ（従来の静的解析ツールでは発見が困難な複雑な脆弱性など）の発見
  • 脆弱性のトリアージおよび修正パッチ案の自動生成

3. 主要機能

• モデル駆動スキャン: Claude Mythos等の最強の言語モデルを使用し、深層の脆弱性を探索・発見する機能。
• パッチの自動提案: 発見された脆弱性に対して、自己完結型の再現手順（PoC）と、可能な場合は修正パッチを提案する。
• 自動ビルドと検証: 提供されたDockerfile等を使用して隔離環境で自動ビルドを行い、依存関係等を解決したうえでテストする。
• 定期スキャン: 初回スキャン後、前回のスキャン以降に導入された潜在的な新しい脆弱性を特定するため、定期的にスキャンを実行する。
• 脅威モデルのカスタマイズ: threat_model.mdを介してプロジェクト固有のセキュリティ目標や深刻度の評価基準をスキャナーに指示できる。

4. 動作原理・システム構成

• アーキテクチャ: クラウド完結型SaaS（スキャン処理はAnthropicのインフラ上で実行）。
• 主要コンポーネントとデータフロー:
  • GitHub上のanthropics/oss-scannerリポジトリにPRを送ることでプロジェクトを登録。
  • スキャナーは対象プロジェクトをインポートし、提供されたDockerfileに従ってネットワーク接続ありの隔離VM内でビルドを行う。
  • その後、VMはインターネットアクセスを持たないネットワークに移動され、完全にオフラインの環境下でClaudeエージェントによるセキュリティ監査（脆弱性探索、根本原因分析、パッチ作成）が実行される。
  • 発見された脆弱性レポートは、モデルによって生成され、人間のレビューを経ずに直接プライマリーコンタクト宛にメール（PGP暗号化オプションあり）で送信される。
• 特筆すべき要素技術:
  • 複数のハーネスや実験的技術を組み合わせたAIエージェントによるコード解析。
  • インターネットアクセスを遮断したハードニング済みサンドボックス内でのエージェント実行による高いセキュリティ。

5. 開始手順・セットアップ

• 前提条件:
  • スキャナーがビルドやテストを実行するためのDockerfile。
  • スキャン対象のリポジトリURLと連絡先メールアドレス。
  • （推奨）プロジェクトのセキュリティ方針を示すthreat_model.md。

• インストール/導入:

  リポジトリanthropics/oss-scannerに対して、以下のようなprojects/<name>/project.yamlを追加するPull Request（PR）を作成する。

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

• クイックスタート: ローカルでスキャナーが機能するか確認するため、リポジトリ内のツールを使用可能。

  tools/validate.py projects/<name>/
  tools/check <name>
  

6. 特徴・強み (Pros)

• AIによる高度な分析により、従来の静的解析ツールでは検出が難しい論理的な脆弱性や複雑なエクスプロイトチェーンを発見可能。
• 脆弱性レポートには修正用パッチや再現コード（PoC）が含まれるため、メンテナーは即座に検証し、迅速に修正対応が可能。
• 対象として選定されたオープンソースプロジェクトには完全に無償で提供される。
• スキャン環境がオフライン化されたVMであるため、プロジェクトのデータや環境が外部に漏洩するリスクが抑えられている。

7. 弱み・注意点 (Cons)

• AIが生成した未検証のレポートが直接送られるため、誤検知（フォールスポジティブ）が含まれる可能性がある（ただしAnthropicによる初期テストでは誤検知率は低いとされている）。
• すべてのプロジェクトが対象となるわけではなく、「インフラストラクチャやユーザーセキュリティに重大な影響を与える」と判断されたプロジェクトに限定される。
• ビルドやテストに用いるDocker環境をメンテナー側で正確に設定し維持する必要がある。
• 現状、レポートの送信はメールのみである。

8. 料金プラン

プラン名	料金	主な特徴
無料	無料	オープンソースプロジェクト向けに無料で提供

• 課金体系: 完全無料（ただしAnthropicによる審査あり）
• 無料トライアル: -

9. 導入実績・事例

• 導入企業: PostgreSQL, OpenSSL, wolfSSL, HotCRP などの主要なオープンソースプロジェクト（パイロットプログラム時）
• 導入事例: 初期パイロットプログラムにおいて、数十のオープンソースプロジェクトでテストを実施。数百のバグレポートと、それらをチェーンしたRCEエクスプロイトなどが発見され、PostgreSQLやwolfSSL等のメンテナーから高い評価を受けた。
• 対象業界: ソフトウェア基盤、インフラ、セキュリティライブラリなど

10. サポート体制

• ドキュメント: GitHubのREADMEおよびAnthropicの公式サイト（FAQ、ローンチ記事等）が提供されている。
• コミュニティ: 特にフォーラム等は公開されていない。
• 公式サポート: 登録プロジェクトからのフィードバック用メールアドレス（oss-scanner-questions@anthropic.com）が用意されている。

11. エコシステムと連携

11.1 API・外部サービス連携

• API: 非公開。
• 外部サービス連携: 現状、GitHubのPull Requestベースでの登録と、メールによるレポート送信が主体である。

11.2 技術スタックとの相性

技術スタック	相性	メリット・推奨理由	懸念点・注意点
C/C++ (Linux)	◎	OpenSSLやPostgreSQL等での実績が多数あり、メモリ破壊等の検出に強い	特になし
Docker	◎	スキャンの前提としてDockerfileが要求されるため、Dockerを標準で使っている環境とは極めて相性が良い	依存関係が複雑な場合、オフラインビルドが完走するように設定する手間がある

12. セキュリティとコンプライアンス

• 認証: GitHub上のPull Requestを通じて登録を行い、Anthropic側でプロジェクトのコアメンテナーであるかを検証する。
• データ管理: レポートデータは隔離されロックダウンされたクラウドアカウントに保持され、Anthropicのセキュリティスタッフのみがアクセス可能。スキャンエージェントはインターネットアクセスが無効化されたハードニング済みのサンドボックス内で実行される。
• 準拠規格: 公式サイトでは各種セキュリティ要件についての詳細なコンプライアンス認証（SOC2等）への直接言及はないが、CVDプログラムに準拠したセキュアなインフラ管理が行われている。

13. 操作性 (UI/UX) と学習コスト

• UI/UX: GUIは提供されず、GitHubリポジトリへのYAMLファイルのPR作成で完結するシンプルな設計（Configuration as Code）。
• 学習コスト: Dockerの知識とYAMLの記述方法が必要だが、設定項目が少なく学習コストは非常に低い。ローカルでの検証用ツール（tools/check等）も提供されており、動作確認は容易。

14. ベストプラクティス

• 効果的な活用法 (Modern Practices):
  • threat_model.mdを記述し、スキャナーに対してプロジェクトがどの入力データを信頼し、何を脅威と見なすか（例：認証済みのユーザーによるSQLインジェクションをどう扱うか）や、深刻度の判断基準を明確に指示する。
  • PGP公開鍵（pgpフィールド）を設定し、脆弱性レポートを暗号化して安全に受け取る。
• 陥りやすい罠 (Antipatterns):
  • Dockerfileでの依存関係のインストール時に、インターネットから動的に取得する処理を後段（オフラインになるスキャン時）に残してしまうと、ビルドやテストが失敗する。

15. ユーザーの声（レビュー分析）

• 調査対象: 公式発表およびAnthropicのブログ等
• 総合評価: （ローンチ直後のため定量的評価はなし）
• ポジティブな評価:
  • PostgreSQLのメンテナーは「発見されたバグの多くはそのまま使える修正案が付属しており、高速な対応が可能だった」と評価。
  • OpenSSLのメンテナーは「過去のAIによる低品質なレポートとは異なり、PoCエクスプロイトが添付されているため、エンジニアの検証作業が事実上完了しているレベル」と評価。
  • wolfSSLのメンテナーは「74のレポートのうち2つを除いてすべて有効であり、5つはCVEとして登録された」と精度を高く評価している。
• ネガティブな評価 / 改善要望:
  • 一部のメンテナーからは、深刻度（Severity）の評価が膨らみがちであったり、プロジェクトの脅威モデルを誤解している場合があるとの指摘があった（これを改善するためにthreat_model.md機能が推奨されている）。
• 特徴的なユースケース:
  • 高度に複雑な権限モデルを持つソフトウェア（HotCRPなど）に対しても、その複雑な権限モデルを理解し、適切なバグの優先順位付けと明確なレポート生成ができている。

16. 直近半年のアップデート情報

• 2026-10-08: OSS Scannerの正式ローンチを発表。オプトイン形式でオープンソースプロジェクトの登録受付を開始。

(出典: Anthropic News )

17. 類似ツールとの比較

17.1 機能比較表 (星取表)

機能カテゴリ	機能項目	本ツール	OSV-Scanner	Trivy	Tsunami Security Scanner
スキャン対象	対象領域	◎ ロジック・未知の脆弱性	◯ 既知のOSS依存関係	◯ 既知の脆弱性・IaC・コンテナ	◯ ネットワーク・アプリケーション
技術基盤	AIの活用	◎ 高度なLLMエージェント	× OSVデータベース参照	× 脆弱性DB参照	× プラグインベースの動的スキャン
修復支援	パッチ提案	◎ 自己完結型PoCとパッチ同梱	△ アップデートの提示	△ 安全なバージョンの提示	× レポートのみ
提供形態	スキャン実行環境	◯ SaaS（無償提供）	◎ ローカル/CI	◎ ローカル/CI	◯ ネットワーク経由実行

17.2 詳細比較

ツール名	特徴	強み	弱み	選択肢となるケース
本ツール	LLMエージェントを用いた未知の脆弱性探索	ゼロデイや複雑なロジックバグの発見能力、具体的な修正パッチの提示	既知の依存関係の包括的なスキャンには向かない、対象プロジェクトに制限がある	オープンソースプロジェクトで、高度な静的解析では見つからないロジックバグを発見したい場合
OSV-Scanner	Googleが主導するオープンソース脆弱性（OSV）DBを利用したスキャナー	正確で最新の脆弱性データベースとの照合が高速に行える	未知の脆弱性は検出できない	依存するパッケージに既知の脆弱性がないかCIで検査したい場合
Trivy	コンテナ、ファイルシステム、IaCなど広範な対象の脆弱性スキャナー	セットアップが極めて簡単で対応フォーマットが多い	未知のロジックバグは検出不可	アプリケーションのコンテナ化やデプロイ時に既知のリスクを網羅的に検査したい場合
Tsunami Security Scanner	Google製の大規模ネットワーク向け脆弱性スキャナー	高い確度（誤検知の少なさ）で重大なネットワーク露出バグを動的に検出する	アプリケーションのソースコード内部の論理的なバグは見つけられない	デプロイ済みのインフラ全体に対して外部からの攻撃面をスキャンしたい場合

18. 総評

• 総合的な評価: OSS Scannerは、既存のパターンマッチングやデータベース参照型の脆弱性スキャナーとは異なり、最新のLLM（Claude Mythos等）の高度な推論能力を活用してソースコードの論理的な欠陥や未知のゼロデイ脆弱性を発見する、全く新しいアプローチのツールである。誤検知の多さが課題になりがちなAI生成レポートにおいて、PoC（概念実証コード）と具体的なパッチをセットで提供することで、メンテナーの検証コストを劇的に下げている点は高く評価できる。
• 推奨されるチームやプロジェクト: ユーザーベースが大きく、インフラやセキュリティの基盤として利用されるオープンソースプロジェクトのコアチーム。
• 選択時のポイント: TrivyやOSV-Scannerのような「既知の脆弱性（CVE）」の検出ツールとは役割が根本的に異なるため、既存のスキャナーを置き換えるものではなく、従来のツールでは発見できなかった複雑なロジックバグに対する「高度な防御層の追加」として併用することが推奨される。