Claude Securityプラグインとは?既存SASTとの違いと実務での使い方
Claude Securityプラグインとは
Claude Securityプラグインは、Claude Codeのセッション内で複数のエージェントが脆弱性スキャンを行う、ベータ版のプラグインです。
エージェントがアーキテクチャを把握し、脅威モデルを作り、脆弱性を探し、各指摘を独立して検証したうえでレポートを書きます。
名前が似たものに、Enterprise向けのマネージドサービス「Claude Security」があります。こちらはGitHubリポジトリを接続して継続的に監視するホスト型のサービスで、Claude Mythos 5.1でスキャンできます。一方、プラグインは手元のClaude Codeで使えるモデルだけを使い、GitLabやBitbucketのリポジトリなど、マネージド版では届かないコードもスキャンできます。本記事で扱うのはプラグイン版です。
既存静的解析ツールとの構造的な違い
両者の違いは、ルールとの一致を見るか、コードの意味を推論するかにあります。そのため、どちらかを選ぶのではなく、併用するのが前提です。
ルールベースの静的解析の特徴
従来の静的解析は、定義されたパターンとの一致を判定します。既知のパターンは決定的かつ高速に検出できます。一方で、文脈を考慮しないため誤検知が出やすく、複数ファイルにまたがるロジックの問題は見逃しがちです。
推論ベースの検知の特徴
Claude Securityは、データの流れを追い、ビジネスロジックを理解したうえで脆弱性を評価します。Anthropicによれば、複数ファイルの理解が必要な、文脈に依存する脆弱性の検出が得意とされています。ただし、これは提供元の説明であり、効果は自分のコードベースで確かめる必要があります。
置き換えではなく併用
公式ドキュメントは、このプラグインが既存のソースコード向けセキュリティツールを置き換えるものではないと明記しています。言語ごとのルール、依存関係やサプライチェーンのチェックは、引き続き既存の静的解析や依存関係スキャナーの役割です。
マルチエージェント構成と検証の仕組み
ノイズを減らす要は、見つけるエージェントと確かめるエージェントを分けている点です。独立した検証者が分析した指摘だけがレポートに載るため、レポートは短く、読む価値のあるものに絞られます。
スキャンはおおむね次の流れで進みます。
- リポジトリを読み込み、アーキテクチャを把握する
- コンポーネントごとに脅威モデルを作る
- 複数の調査エージェントで並行して脆弱性を探す
- 別の検証エージェントが各指摘を独立して確認する
- 確認できた指摘だけをレポートにまとめる
指摘ごとに、影響、攻撃シナリオ、深刻度、確信度、推奨対応が付きます。ただし、検証を経ても誤検知をゼロにはできません。また、同じコードを2回スキャンしても結果が変わることがあるため、最終判断は人間が行う前提で運用します。
導入要件とインストール
有料プラン(またはAnthropic APIや対応するクラウドプロバイダー)、Python 3.9以上、Gitがあれば始められます。
| 項目 | 要件 |
|---|---|
| プラン | 有料プラン、Anthropic API、またはAmazon Bedrock等のサードパーティプロバイダー。Proプランは/configでDynamic workflowsを有効にする |
| Python | python3としてPATHが通った3.9以上。標準ライブラリのみ使用 |
| OS | Linux、macOS、Windows |
| Git | 差分スキャンとパッチ生成に必要。フルスキャンはGitがなくても動く |
| APIキー | 不要。セッションのモデルをそのまま使う |
Claude Codeのプロンプトで、公式マーケットプレイスからインストールします。
/plugin install claude-security@claude-plugins-official
マーケットプレイスが見つからないと言われたら、先に/plugin marketplace add anthropics/claude-plugins-officialを実行します。インストール後に/reload-pluginsを求められた場合は、それを実行して有効化します。
3つの機能と出力
/claude-securityを実行すると、3つの機能を選ぶメニューが開きます。/claude-security scan my branchのように引数で指示したり、「scan commit abc1234」のように自然な文で頼んだりもできます。
Scan Codebase:リポジトリ全体のスキャン
自分が書いていないコードも含めて、リポジトリ全体を対象にします。最初にリポジトリを読み込み、全体か特定の領域(API層や認証まわりなど)かを選ばせてくれます。各選択肢にはファイル数と相対的なコストが表示されます。大きなリポジトリでは、領域を絞って順にスキャンするのが現実的です。
Scan Changes:差分のスキャン
ブランチの差分、プルリクエスト、単一のコミットを対象にします。差分だけを見るわけではなく、文脈を得るためにエージェントはリポジトリ全体を読みます。対象はコミット済みの変更だけなので、作業中の編集は先にcommitかstashします。
Suggest Patches:修正パッチの提案
レポートの中から修正したい指摘を選ぶと、パッチを作ります。パッチは作業用のコピー上で作られるので、元のソースは変わりません。
各パッチは、作ったエージェントとは別のエージェントがレビューします。テストがあれば実行し、次の3点をすべて保証できる場合にだけパッチを出力します。
• その指摘を修正していること
• 新しい脆弱性を入れていないこと
• それ以外の挙動を変えていないこと
保証できない場合は、パッチの代わりに理由を書いたメモが出ます。つまり、パッチはリファクタリングを含むものではなく、1つの指摘を最小限の変更で直すものです。パッチが自動で適用されることはなく、git applyで自分で適用します。1パッチにつき1つのプルリクエストに分けて、個別にレビュー・テストするのが推奨です。
出力されるファイル
スキャン結果は、リポジトリ内のCLAUDE-SECURITY-<timestamp>/ディレクトリに書き出されます。
| ファイル | 内容 |
|---|---|
CLAUDE-SECURITY-RESULTS.md |
人が読むレポート(ID、影響、攻撃シナリオ、深刻度、確信度、推奨対応) |
CLAUDE-SECURITY-RESULTS.jsonl |
同じ内容を1行1件のJSONで |
CLAUDE-SECURITY-RESULTS.sarif |
SARIF 2.1.0形式。GitHub code scanningなどで読める。CWEで分類 |
CLAUDE-SECURITY-REVISION-<commit>.json |
スキャンしたコミットや設定の記録 |
patches/F<n>.patch |
指摘ごとの修正パッチと説明メモ |
このディレクトリには独自の.gitignoreが入っているため、うっかりgit addしてもコミットに混ざりません。
他ツールとの位置づけとCI連携
このプラグインは、多層防御の中で「必要なときに実行する深いスキャン」を担う層です。PRごとのレビューや、コードを書く最中のチェックは別のツールの役割です。
| 段階 | ツール | 役割 |
|---|---|---|
| コーディング中 | security guidanceプラグイン | Claudeが書くコードの一般的な脆弱性を、その場で指摘・修正 |
| 随時(1回) | /security-review |
現在のブランチを1回チェック |
| 随時(深いスキャン) | Claude Securityプラグイン | リポジトリや差分を複数エージェントでスキャンし、検証済みの指摘とパッチを出す |
| PR時 | Code Review(Team・Enterpriseプラン) | コードベース全体を踏まえたPRレビュー |
| 継続監視 | Claude Security(Enterpriseプラン) | 接続したリポジトリを監視するホスト型サービス |
| CI | 既存の静的解析・依存関係スキャナー | 言語ごとのルール、サプライチェーンのチェック、ポリシーの適用 |
CIに組み込む場合のトレードオフ
Scan ChangesはCIでも実行できます。結果をSARIFで出力できるので、GitHub code scanningなど既存の仕組みに指摘を取り込みやすい点は利点です。
一方で、スキャンには時間とトークンがかかり、実行中はClaude Codeを開いておく必要があります。結果も毎回同じとは限りません。そのため、すべてのコミットで即座に結果を返すゲートとして使うよりも、マージ前のブランチや重要な変更に絞って使うほうが現実的です。高速で決定的なチェックは、既存の静的解析に任せます。
運用上の注意点
導入でつまずきやすいのは、コスト、結果のばらつき、人間によるレビューの3点です。
1.コストを見積もってから実行する:スキャンはClaude Codeの使用量にカウントされ、トークンを大量に使うことがあります。実行前に確認が求められるので、表示される範囲とコストを見てから始めます。まずは認証まわりなど1つの領域で試すのがおすすめです。
2.結果は毎回同じとは限らない:同じコードでも、スキャンごとに異なる指摘が出ることがあります。定期的にスキャンし、リビジョンの記録でどのコードの結果かを管理します。
3. パッチは必ず人がレビューする:パッチは自動で適用されません。テストのないコードでは、レビューがテストなしで行われたことがメモに書かれます。
4.他人のコードを扱うときは扱いを決めておく:受託開発などでは、レポートやパッチの保管・共有方法を事前に関係者と取り決めておくと安心です。
5.autoモードとの兼ね合い:プラグインはautoモードで最もスムーズに動きますが、エージェントに許可なく操作させることになります。信頼できるリポジトリで使い、外部から取り込んだコード中の指示に従わせない設計を意識します。
コラム:アラート疲れを防ぐコツ
すべての指摘を同じ重みで扱うと、開発者は警告に埋もれてしまいます。
レポートの深刻度と確信度をもとに優先度を付け、高い深刻度かつ高い確信度のものから対応する運用がおすすめです。
低い確信度の指摘は、次のスキャンで再び出るかどうかを見てから判断するのも一つの方法です。
