Claude CodeでWebアプリを監査する: 依存脆弱性・シークレット・OWASP観点の手順

リリース前夜、自分のSaaSのリポジトリで git grep -n "sk_live" を打ったら、テスト用のはずのファイルから本番のStripeキーが出てきました。

コミット履歴をたどると、3週間前。とっくにpushされていて、GitHubのpublicリポジトリに丸見えでした。

血の気が引きました。あの夜から、僕は「リリース前に自分のアプリを攻撃者の目で一周見る」を習慣にしています。とはいえ、認証・認可・依存・ログ・シークレットを全部ひとりで追うのはしんどい。そこで相棒にしたのが Claude Code です。

先に断っておくと、これは自分が権限を持つコードを、防御目的で点検する話です。他人のサイトを勝手に攻撃する手順は一切書きません。やるのは、攻める側が見つける前に、守る側が穴を塞ぐ作業です。

この記事の要点

• Claude Code への監査依頼は「セキュリティ見て」ではなく、範囲・資産・完了条件を書いたブリーフを渡すと精度が跳ね上がる。
• 依存の穴は npm audit と Dependabot の二段構え。出た警告は「到達できるか」で優先度を分ける。
• シークレット混入は、履歴ごと疑う。見つけた値は伏せて、場所と種類とローテ要否だけ記録する。
• OWASP Top 10 は、名前を暗記するより「どの入力がどの出力に流れるか」を Claude Code に追わせるほうが当たる。特に認可漏れが一番出る。
• 監査の成果物は、きれいなレポートではなくリスク登録表と証跡。これがないとリリース判断に使えない。

まず「セキュリティ見て」をやめる

最初に正直な話を。Claude Code に「このリポジトリのセキュリティを見て」とだけ投げた頃、返ってきたのは教科書みたいな一般論でした。「入力検証をしましょう」「HTTPSを使いましょう」。知ってる。そういうことじゃない。

監査が浅くなる原因は、AIの賢さではなく、こっちが範囲を渡していないことでした。人間の専門家だって「いい感じに見て」と言われたら困ります。だからまず、1枚のブリーフを書く。これだけで結果が安定します。

そのまま貼れる監査ブリーフです。実案件では対象URL、変更差分、リリース期限、触っていいコマンドも足します。

# セキュリティ監査ブリーフ

## 目的
- リリース前に、認証・認可・シークレット・入力検証・ログ漏えいの重大な穴を見つける
- 修正案だけでなく、確認した証跡と残ったリスクを残す

## 対象範囲
- 対象リポジトリ:
- 対象ブランチ/PR:
- 対象機能:
- 触ってよいディレクトリ:
- 触らないディレクトリ:

## 重点観点
- 認証とセッション（ログイン・MFA・cookie属性）
- 認可とロール（他人のデータを触れないか）
- 入力検証と出力エスケープ（XSS・SQLi）
- シークレットと環境変数（履歴含む）
- 依存関係とライセンス
- ログとPII（個人情報）の漏えい

## 完了条件
- 発見事項をリスク登録表に記録する
- 再現に必要な最小情報だけ書く
- 実際の攻撃文字列・実シークレット・顧客データは書かない
- 実行したコマンド・結果・未確認事項を証跡として残す

PII は Personally Identifiable Information、つまり氏名やメールのような個人を特定できる情報のことです。専門用語はこんなふうに初出でほぐすようにしています。

ブリーフを渡したら、いきなり直させない。まず読ませます。「ルート、認証ミドルウェア、外部API、環境変数、ログ出力、CI設定を一覧化して。脆弱だと断定せず、ファイルパスと行番号だけ並べて」。この棚卸しが監査の地図になります。

依存の脆弱性: npm audit と Dependabot の二段構え

自分で書いたコードより、node_modules のほうが行数は桁違いに多い。攻撃者が狙うのもそこです。依存の点検は、ローカルの一発確認とリポジトリの常時監視を組み合わせます。

ローカルはまず npm audit。プロジェクトの依存を npmレジストリ に問い合わせ、既知の脆弱性レポートを返してくれます。--audit-level は「どの深刻度以上で異常終了させるか」のしきい値です。CIで使うなら moderate あたりから始めると、ノイズに埋もれません。

# 本番に乗る依存だけを対象に、moderate以上を検出する
npm audit --omit=dev --audit-level=moderate

--omit=dev を付けると devDependencies を外せます。テストツールの脆弱性まで全部ブロックすると開発が止まるので、本番に届くものを優先するわけです。自動で直せるものは npm audit fix が拾いますが、これは内部で install を走らせます。メジャー更新は破壊的変更を含むので、fix 後は必ずテストを通す。ここを飛ばして本番が壊れた失敗は、後で書きます。

リポジトリ側の常時監視が Dependabot alerts です。デフォルトブランチを継続的にスキャンし、GitHub Advisory Database に新しい脆弱性が載るか、依存が変わったタイミングで通知してくれます。「アラートで気づく」のがDependabot、「今この瞬間の状態を見る」のが npm audit。役割が違うので両方使います。

ここで Claude Code の出番。npm audit の生の出力をそのまま渡して、こう頼みます。

このaudit結果を、(1)直接依存か推移的依存か、(2)該当コードから到達可能か、(3)代替やパッチの有無、で整理して。HighでもアプリのコードパスにないものはMediumに落として理由を書いて。

警告の数字に振り回されず、到達可能性で優先度を引き直すのがコツです。使っていない依存の奥深くにあるHighより、ログイン処理が踏むMediumのほうが怖い。Claude Code はコードを読んで呼び出し元をたどれるので、この仕分けが得意です。

シークレット混入は「履歴ごと」疑う

冒頭の僕の事故がこれです。.env をちゃんと .gitignore に入れていても、サンプル設定、テストデータ、README、CIのログ、スクリーンショットから漏れます。

Claude Code に探させるときの鉄則は、実シークレットをチャットに貼らせないこと。見つけたら値は伏せて、場所・種類・ローテ要否だけ記録させます。

# よくある秘密のパターンを履歴も含めて走査する（防御目的の自己点検）
# 注意: 出力に実キーが混じるので、結果は安全な場所で扱う
git grep -nIE "sk_live|sk_test|AKIA[0-9A-Z]{16}|-----BEGIN (RSA|OPENSSH) PRIVATE KEY-----" $(git rev-list --all) \
  | head -50

このコマンドは全コミットを横断するので重いですが、「今のファイルには無いけど履歴に残っている」典型を炙り出せます。出てきたら、ファイルを消すだけでは不十分。push済みのキーは漏れたものとして即ローテーションします。GitHubを使っているなら secret scanning を有効にし、push protection でコミット時点で止める運用に寄せると、同じ事故を繰り返しません。

Claude Code への依頼はこう。「.env.example、テストフィクスチャ、CI設定、READMEに、実値らしき文字列が無いか確認して。見つけたら値はマスクして、種類とローテ要否だけ表にして」。これで、僕が見落とした「サンプルのつもりの本物」を拾ってくれます。

OWASP Top 10 を「丸暗記しない」レビュー

OWASP Top 10 は、Webアプリで起きやすいリスクをまとめた、世界共通の物差しです。ただ、XSSだのSQLiだの名前を並べても監査は進みません。僕がやるのは、Claude Code に入力から出力への流れを追わせることです。

主要な観点と、Claude Code に投げる狙いを表にしておきます。

OWASP観点	何を見るか	Claude Codeへの頼み方
アクセス制御の不備（認可漏れ）	他人のIDを受け取るAPI、管理機能、ファイルDL	「リソース所有者チェックの無いルートを列挙して」
インジェクション（SQLi/XSS）	生クエリ、innerHTML、テンプレ埋め込み	「ユーザー入力がDBクエリやDOMに直接届く箇所を追って」
認証の不備	パスワードリセット、セッション期限、MFA	「セッション無効化漏れとcookie属性を確認して」
設定ミス	CORS全開、デバッグ有効、デフォルト権限	「本番で危険な設定値をデフォルトと比較して」
脆弱な依存	古いライブラリ、放置パッケージ	「audit結果を到達可能性で再優先度付けして」

経験上、ダントツで出るのが認可漏れです。「ログインしているか」と「その操作をしていいか」は別物。/api/users/:id で、ログイン中の本人かどうかを確かめずに :id をそのまま信じてしまう、あれです。Claude Code には「認証は通っているが、リソースの所有者確認をしていないルートだけ」と狭く聞くと、本質的な穴が浮きます。

XSSやSQLiは、危険な実攻撃文字列を書かせる必要はありません。「どの入力がどの出力（DOM・SQL・shell）に、エスケープなしで流れているか」を追わせ、バリデーション・正規化・パラメータ化クエリ・型チェックを提案させれば十分です。

実際に手を動かす: 監査スクリプト一式

毎回コマンドを思い出すのは面倒なので、最初の一周を機械に任せる小さなスクリプトを置いています。コピペして audit.sh で保存、bash audit.sh で動きます。各チェックは落ちても止まらず、最後にまとめて結果を出します。

#!/usr/bin/env bash
# 自分のWebアプリの一次セキュリティ点検（防御目的）
# 失敗しても止めずに走り切り、最後にサマリを出す
set -uo pipefail

REPORT="audit-$(date +%Y%m%d-%H%M%S).log"
echo "監査開始: $(date)" | tee "$REPORT"

run() {
  local label="$1"; shift
  echo "" | tee -a "$REPORT"
  echo "### $label" | tee -a "$REPORT"
  # 実行コマンドも証跡として残す
  echo "\$ $*" | tee -a "$REPORT"
  "$@" 2>&1 | tee -a "$REPORT" || echo "(終了コード $? / 要確認)" | tee -a "$REPORT"
}

# 1. 依存の脆弱性（本番依存・moderate以上）
run "依存監査" npm audit --omit=dev --audit-level=moderate

# 2. シークレットらしき文字列（現時点のソース）
run "シークレット走査" git grep -nIE "sk_live|AKIA[0-9A-Z]{16}|BEGIN (RSA|OPENSSH) PRIVATE KEY" -- src

# 3. 危険になりがちなコードパターン（脆弱性ではなく要レビュー候補）
run "危険パターン" git grep -nIE "innerHTML|dangerouslySetInnerHTML|eval\(|child_process|process\.env" -- src

# 4. 改行・空白の壊れた差分（混入チェック）
run "差分の健全性" git diff --check

echo "" | tee -a "$REPORT"
echo "完了。結果は $REPORT に保存。次は Claude Code にこのログを渡して優先度付けを依頼する。" | tee -a "$REPORT"

大事なのは、このスクリプトが出すのは容疑者リストであって、有罪判決ではないこと。process.env は正しい使い方でも出ますし、innerHTML もサニタイズ済みなら問題ありません。だから最後に Claude Code へログを渡し、「危険と断定せず、根拠・前提・確認方法を分けて優先度を付けて」と頼みます。機械で集める→AIで仕分ける→人間が判断する、の三段で回すと速くて漏れにくいです。

成果物はレポートじゃない: リスク登録表と証跡

監査の価値は、文章量ではありません。リリース判断に使えるかどうかです。だから僕は、発見を必ずこの2つに落とします。

ひとつめがリスク登録表。AIの出力は流れて消えるので、最後にここへ集約します。

| ID | リスク | 影響 | 根拠 | 推奨対応 | 優先度 | 状態 | 担当 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SEC-001 | 管理APIに所有者チェックなし | 他ユーザー情報の閲覧・改ざん | routes/admin.ts:42 | middleware追加+テスト | High | Open | backend |
| SEC-002 | Webhookログにメール出力 | PIIの不要保存 | logs/webhook.ts:18 | マスク+保持期間見直し | Medium | Open | platform |
| SEC-003 | lodash 推移的依存にHigh | 到達不可（CLIのみ） | npm audit | 次回更新でまとめて | Low | Open | platform |

ふたつめが証跡レシート。「やったつもり」を防ぐ短い記録です。何を見て、何を見ていないかを書くことが、実は一番効きます。

# 監査 証跡レシート
- 対象 / 日付 / 担当:
- Claude Codeに渡した範囲:
- 実行したコマンド:
- 確認したファイル:
- 高リスク項目:
- 未確認・対象外:
- 人間レビューが必要な判断:
- リリース可否:

優先度の付け方はシンプルに。Highはブロック、Mediumは期限付きチケット、Lowは定期棚卸し。全部をリリースブロッカーにすると開発が止まって、結局ルール自体が形骸化します。

僕がやらかした失敗3つ

ひとつめ。npm audit fix --force を勢いで叩いて、メジャー更新が一気に入り、認証ライブラリの破壊的変更でログインが全部死にました。深夜に切り戻し。以来、fix のあとは必ずテスト、--force は差分を読むまで使わない、を鉄則にしています。

ふたつめ。Claude Code に「全部チェックして」と丸投げして、攻撃文字列の例まで本文に書かせてしまったこと。教育目的でも、再現に不要な実攻撃ペイロードや実URLは外す。発見事項は影響と修正方針を中心に書き、詳細は権限のある場所に分離する、と決めました。

みっつめ。証跡を残さなかったこと。「たぶん見た」では、リリース会議で「本当に確認した?」に答えられません。未確認事項を明記したレポートのほうが、きれいな「問題なし」より100倍価値がある、と痛感しました。

よくある質問

Q. Claude Code に脆弱性を探させるのは安全ですか? 自分が権限を持つコードを、防御目的で点検する限り問題ありません。注意点は、実シークレットや顧客データをチャットに貼らせないこと。見つけた秘密は値を伏せ、場所と種類だけ記録させます。

Q. npm audit で大量にHighが出ました。全部直すべき? いいえ、まず到達可能性で仕分けます。アプリのコードパスから呼ばれない推移的依存のHighより、ログインや決済が踏むMediumを先に直す。Claude Code に呼び出し元をたどらせて優先度を引き直すと現実的です。

Q. Dependabot があれば npm audit は要らない? 役割が違うので両方使います。Dependabot は新しい脆弱性が公開された時にアラートをくれる「常時監視」、npm audit はリリース前に今の状態を確認する「その場の健康診断」です。

Q. OWASP Top 10 のどれから見ればいい? 僕の経験では認可漏れ（アクセス制御の不備）が最頻出です。「他人のIDを受け取るAPIで所有者確認をしていない箇所」を最初に潰すと、影響の大きい穴から塞げます。

Q. AIが生成したPRも同じ手順でいい? 基本は同じですが、AI生成コードは見た目が整っていて認可・ログ・入力検証が薄いことが多いです。「この差分が、攻撃面・権限・秘密情報・PII・CIに与える影響だけ見て」と狭く依頼すると精度が上がります。レビュー観点の仕組み化は Claude Codeでコードレビューを仕組み化する も参考になります。

実際に試した結果

冒頭のStripeキー流出のあと、この型をClaudeCodeLabの公開前レビューに当てはめてみました。効果が大きかったのは、派手な脆弱性スキャナよりリスク登録表と証跡レシートでした。Claude Code にルート・ログ・環境変数・依存を棚卸しさせてから人間が確認すると、「穴探し」より先に「まだ見ていない場所」が見えるようになったんです。

ひとつ足すなら、依存監査の自動化です。Dependabot のアラートと CI の npm audit を入れてから、僕が手で気づく前に更新PRが上がるようになりました。シークレットの扱いは Claude Codeで始めるシークレット管理、過去の事故からの学びは Claude Code セキュリティ失敗事例7選、AIに渡す権限の絞り方は Claude Code 権限設定リファレンス にまとめています。

賢いAIに監査を丸投げするのではなく、攻撃者より先に自分で一周する。その一周をClaude Codeに手伝わせる。遠回りに見えて、これが一番ぐっすり眠れる方法でした。チームの既存リポジトリを前提に監査ブリーフやCIゲートを整えたい人は、研修・導入相談 でも具体的に詰められます。