# Claude Code プラグインのセキュリティ強化
プラグインは開発体験を劇的に向上させる一方で、任意コード実行の窓口にもなりうる。特に hooks は標準入力から JSON を受け取りシェルスクリプトを実行するため、設計を誤るとマシン全体を危険に晒す。本稿ではプラグインのセキュリティを強化する四つの観点を整理する。
フックのサンドボックス化
最初の要諦は、hooks を必要最小限の権限で走らせることだ。我々はすべての hooks を `bwrap`(bubblewrap)や macOS の `sandbox-exec` で包み、書き込み可能なパスをプロジェクトルート配下に限定している。ネットワークはデフォルト禁止とし、必要なものだけ個別に許可する。
Linux での典型的な起動は次の通りだ。
```bash bwrap --ro-bind / / --bind "$PWD" "$PWD" --dev /dev --proc /proc --unshare-net ./hooks/audit.sh ```
サンドボックスのコストは微小で、起動オーバーヘッドは数十ミリ秒程度だ。これだけで、誤った hook が `~/.ssh` を読みに行く事故を防げる。
権限スコープの明示
二つ目は、プラグインが必要とする権限をマニフェストに明示することだ。我々は社内拡張として `permissions` フィールドを追加し、ネットワーク到達先、読み書き可能なパス、呼び出し可能な外部コマンドを列挙するよう義務付けている。
```json { "permissions": { "network": ["api.internal.kga.example"], "write_paths": ["./.claude/cache"], "exec": ["git", "jq"] } } ```
インストール時にこの宣言をユーザーに提示し、明示的な同意を取る。不透明な権限要求はそれだけで赤旗であり、レビュー時の重要な判断材料になる。
監査証跡の設計
三つ目が監査ログだ。誰が、いつ、どのプラグインで、何を実行したかを追跡できる状態を保つ。我々は PostToolUse フックで実行ログを JSON Lines として書き出し、中央の SIEM に集約している。ログには実行者、コマンドハッシュ、終了コード、所要時間を含めるが、引数の生文字列は含めない。秘匿情報の漏洩を避けるためだ。
ログの改ざん防止も重要である。append-only のファイルシステム属性を付け、日次でハッシュチェーンを計算して別ストレージへ送る。こうすることで、侵害時に証跡が消されるリスクを下げられる。
サプライチェーン防衛
四つ目がサプライチェーン対策だ。プラグインは他のプラグインや npm パッケージに依存することが多く、依存先の侵害が直接自社環境に波及する。我々は三つの対策を組み合わせている。第一に、依存はすべてロックファイルで固定し、新規追加時は人間のレビューを必須とする。第二に、定期的に `osv-scanner` などで脆弱性を走査し、検知されたものは自動で issue 化する。第三に、署名検証を install パイプラインに組み込み、署名なしのバージョンはブロックする。
特に警戒すべきは、マーケットプレイスの URL を動的に書き換える攻撃や、タイプスクワッティングによる偽プラグインだ。`/plugin marketplace add` で購読する前に、リポジトリの所有者を目視で確認するルールを徹底している。
インシデント対応の備え
どれだけ対策しても事故はゼロにならない。重要なのはインシデントが起きたときに素早く停止できることだ。我々は中央の kill switch を用意し、特定プラグインを一斉無効化できる仕組みを持っている。実体は単純なフィーチャーフラグで、SessionStart hook が中央 API から状態を取得し、無効フラグが立っていればプラグインのロードを拒否する。
運用チェックリスト
最後に、プラグイン公開前に確認する簡易チェックリストを挙げておく。hooks はサンドボックスで動くか。ネットワークアクセスは最小か。秘匿情報をログに書いていないか。依存のライセンスは適合するか。署名を付けたか。kill switch の対象に登録したか。このリストを満たすまで公開しないと決めるだけで、事故率は体感で大きく下がる。
まとめ
プラグインのセキュリティは、サンドボックス・権限宣言・監査証跡・サプライチェーン対策の四本柱で成り立つ。どれも特別な技術ではなく、既存の運用に組み合わせるだけで効果が出る。小さく始め、継続的に強化していくのが現実解である。