security-code-audit

セキュリティコード監査（FIND フェーズ）

概要

ソースコードを読み、パターンに基づいて脆弱性を見つけます。アプリを実行する必要はなく、あらゆる AI コーディングツールで利用できます。信頼できない入力が、そのソース（入力される場所）からシンク（危険な形で使用される場所）に至るまでを追跡します。

基本原則： 脆弱性とは、信頼できないデータが、適切な検証やエンコードを受けずに危険なシンクに到達することです。ソースからシンクに至る経路を見つけてください。

手法：ソースからシンクへの追跡

1. 脅威モデル（またはエントリーポイントのスキャン）から、信頼できない入力のソースを選びます。
2. データがコード内を通って、どこで使用されるか（シンク）を追跡します。
3. そのシンクに対して、入力が検証、サニタイズ、パラメーター化、またはエンコードされているかを確認します。されていなければ、指摘事項です。
4. 深刻度、file:line、正確なデータ経路、および悪用方法を記録します。

OWASP Top 10 — 検索するパターン

リスク	検索する危険なパターン／シンク
インジェクション（SQL／NoSQL／コマンド）	文字列で組み立てるクエリ、exec、eval、system、クエリ内のテンプレート補間
アクセス制御の不備（IDOR）	所有権の確認をせず、ユーザー指定の ID でオブジェクトを検索する
認証の不備	独自の暗号化、脆弱なセッション管理、MFA の欠如、URL 内のトークン
暗号化の失敗	パスワードへの md5／sha1 の使用、ハードコードされたキー、トークンへの Math.random の使用、TLS の欠如
SSRF	サーバーがユーザー指定の URL をフェッチする（requests.get(input)、fetch(input)）
セキュリティ設定ミス	debug=true、デフォルトの認証情報、許可範囲の広い CORS *、詳細すぎるエラー
XSS	innerHTML、dangerouslySetInnerHTML、v-html、エスケープされていないテンプレート出力
安全でないデシリアライゼーション	pickle.loads、yaml.load、入力に対するネイティブなデシリアライズ
脆弱な依存関係	ロックファイルとアドバイザリーを照合する（npm audit、pip-audit、osv）
SSTI／パストラバーサル	入力のテンプレートレンダリング、入力から得たファイルパス内の ../

ドメイン別のリファレンス（一致するスタックのものを読み込んでください）

• references/web-frontend.md — XSS、CSRF、CSP、クライアント側のシークレット、クリックジャッキング
• references/api-backend.md — 認可／IDOR、インジェクション、SSRF、JWT、レート制限、マスアサインメント
• references/database.md — SQLi／NoSQLi、アクセス制御、データ漏えい、ORM の落とし穴

出力：指摘事項一覧

ID	深刻度	タイトル	場所	ソース→シンク	悪用可能性	修正の参照先
F1	High	ユーザー検索における SQLi	api/users.py:42	?q= → 生の SQL	認証不要、DB をダンプ可能	パラメーター化 → security-hardening

深刻度は脅威モデルのリスクスコアを基準とし、コードの実際の悪用可能性に応じて調整します。

引き継ぎ

実行中のアプリで深刻度の高い指摘事項を検証するには、active-pentest に引き継ぎます。 すべての指摘事項の修正には、security-hardening に引き継ぎます。

よくある間違い

• 入力が実際に攻撃者によって制御されているかを確認せず、シンクのパターンだけで判断する（誤検知）。
• 最初のシンクで調査を止める。1 つのソースが複数のシンクに到達することはよくあります。
• クライアント側の検証を信頼する。回避可能なため、サーバー側で検証する必要があります。
• 認可を見落とす。現実の侵害の大半は、目新しいインジェクションではなく、アクセス制御の不備によるものです。