security-audit

セキュリティ監査スキル

セキュリティが重要なシステムを対象とする、包括的で手動による詳細なコード監査プロトコルです。AI を活用した開発でよくある落とし穴を防ぐ、迅速な「バイブコーディングのガードレール」も含まれています。

使用するタイミング

• 大規模リリースの前
• セキュリティレビューの依頼を受けたとき
• 認証や決済のフローを監査するとき
• 「audit」または「security」という言葉が出てきたとき
• AI で新しいプロジェクトのひな形を作成した後（バイブコーディングの健全性チェック）
• ユーザー向けアプリを初めてデプロイする前

監査フェーズ

フェーズ 0：スコープの定義

範囲を定義します。

• FULL_SCAN：コードベース全体
• FEATURE_SCAN：特定の機能（docs/features/[Name].md）
• DIFF_SCAN：git diff --staged または git diff HEAD~1

フェーズ 1：探偵（静的解析）

# 1. Detect package manager & run dependency audit
# Auto-detect: check which lockfile exists
# pnpm-lock.yaml → pnpm audit
# package-lock.json → npm audit
# yarn.lock → yarn audit
# bun.lockb → bun pm audit (or bunx audit)
pnpm audit  # ← swap for your package manager

# 2. Secret scanning (use jstar if available)
jstar detect

# 3. Manual grep patterns:
# Secrets
grep -rE "(api_key|secret|password|token)\s*[:=]\s*['\"\`][a-zA-Z0-9_\-\.]{10,}['\"\`]"

# RCE/Injection
grep -rE "(dangerouslySetInnerHTML|eval\(|exec\(|\.queryRaw)"

# Debugging
grep -rE "(console\.log|debugger|todo)"

フェーズ 1.5：バイブコーディングのガードレール（AI 固有のチェック）

よくあるバイブコーディングのセキュリティ上のミスを見つけるための、迅速で事前予防的なチェックです。 詳細な分析を行う前に実施してください。各チェックにかかる時間は約 2 分です。

1.5.1 — 存在しない／架空のパッケージの検出（サプライチェーン）

リスク： AI モデルがパッケージ名を幻覚することがあります。攻撃者はその名前でマルウェアを登録します。

注： npm view は npm レジストリに直接問い合わせるため、パッケージマネージャー（pnpm、yarn、bun など）にかかわらず動作します。npm をインストールする必要はありません。単にレジストリを検索するだけです。

# For each unfamiliar dependency in package.json:
# 1. Verify it exists on the real registry (works with ANY package manager)
npm view <package-name> version  # Should return a version, not 404
# Alt for pnpm users: pnpm info <package-name>
# Alt for bun users: bunx npm-cli view <package-name>

# 2. Check download stats (low downloads = suspicious)
npm view <package-name> --json | grep -E "downloads|modified"

# 3. Look for typosquatting (e.g., "lodahs" instead of "lodash")
# Compare against known-good package names

対応： npm／PyPI に存在しないパッケージ、またはダウンロード数が不自然に少ないパッケージを削除します。公式ドキュメントと照合してください。

1.5.2 — AI が構築した認証の検出

リスク： AI は、動作するように見えても目に見えない脆弱性（CSRF 対策がない、ハッシュ化が弱い、セッションの有効期限がないなど）を抱えた独自のログインシステムを、簡単に生成します。

# Scan for custom auth patterns (red flags):
grep -rE "(bcrypt\.hash|jwt\.sign|createHash|crypto\.createCipher)" --include="*.ts" --include="*.tsx" --include="*.js"
grep -rE "(password.*=.*req\.(body|query)|session\[|cookie\[)" --include="*.ts" --include="*.tsx" --include="*.js"

# Check if a battle-tested auth provider is installed:
grep -E "(next-auth|@auth/|@clerk|@supabase/auth|auth0|lucia|better-auth)" package.json

対応： 独自の認証が見つかり、確立されたプロバイダーが存在しない場合：

• 重大度を高として報告します
• 次のいずれかへの移行を推奨します：Clerk、NextAuth/Auth.js、Supabase Auth、Auth0、Lucia、または Better Auth
• 独自の認証が許容されるのは、チームに専任のセキュリティ専門知識がある場合に限ります

1.5.3 — .gitignore の確認

リスク： バイブコーディングは迅速に進みます。.gitignore のエントリーが 1 つ欠けているだけで、シークレットが GitHub に公開される可能性があります。ボットは公開されたキーを 24 時間 365 日スキャンしています。

# 1. Check .gitignore exists
test -f .gitignore && echo "EXISTS" || echo "MISSING — CRITICAL"

# 2. Verify essential entries are present:
for pattern in ".env" ".env.local" ".env.*.local" "node_modules" "*.pem" "*.key" ".DS_Store"; do
  grep -qF "$pattern" .gitignore || echo "MISSING from .gitignore: $pattern"
done

# 3. Check if .env is already tracked (damage already done):
git ls-files --cached | grep -E "\.env$|\.env\.local$|\.pem$|\.key$"
# If output exists → secrets are already in git history. Rotate ALL keys immediately.

対応： .gitignore が存在しない、または不完全な場合は重大として報告します。.env がすでに追跡対象になっている場合は、重大として報告し、git filter-branch または BFG Repo-Cleaner の使用と、直ちにキーをローテーションすることを推奨します。

1.5.4 — レート制限の確認

リスク： レート制限のない公開 API ルートは、ボットに悪用されます（スパム、ブルートフォース攻撃、API コストの急増など）。

# Check if rate limiting middleware is installed:
grep -E "(rate-limit|@upstash/ratelimit|express-rate-limit|limiter)" package.json

# Check if it's actually applied to API routes:
grep -rE "(rateLimit|rateLimiter|Ratelimit|slidingWindow)" --include="*.ts" --include="*.tsx" --include="*.js" src/app/api/ app/api/ pages/api/

対応： 公開 API ルートにレート制限が見つからない場合：

• 重大度を高として報告します
• 次を推奨します：@upstash/ratelimit（サーバーレス）、express-rate-limit（Express）、またはカスタムミドルウェア
• 最低限の基準：フォームは IP あたり 1 時間に 100 リクエスト、認証エンドポイントは 1 分に 10 リクエスト
• AI を利用するエンドポイント（LLM 呼び出し）には、コスト攻撃を防ぐため、さらに厳しい制限を設ける必要があります

1.5.5 — 行レベルセキュリティ（RLS）の確認

リスク： データベースはデフォルトで、誰でも他の人のデータを閲覧できるようになっています。RLS を設定し忘れると、即座にデータ漏えいにつながります。

# Check if Supabase is used (most common vibe-coding DB):
grep -E "(supabase|@supabase)" package.json

# If Supabase: verify RLS is mentioned in migration files or setup:
grep -rE "(enable_rls|row_level_security|CREATE POLICY|ALTER TABLE.*ENABLE ROW LEVEL SECURITY)" --include="*.sql" --include="*.ts"

# For Prisma: check for tenant/user scoping in queries:
grep -rE "where:.*userId|where:.*user_id|where:.*tenantId" --include="*.ts" --include="*.tsx"

# For raw SQL: check for user-scoped WHERE clauses:
grep -rE "(SELECT|UPDATE|DELETE).*FROM" --include="*.ts" --include="*.tsx" | grep -v "WHERE.*user"

対応： データベースを使用していて、RLS またはユーザー単位のスコープ設定が見つからない場合：

• 重大度を重大として報告します
• Supabase の場合：すべてのテーブルで RLS を有効にし、SELECT、INSERT、UPDATE、DELETE のポリシーを作成します
• Prisma／生 SQL の場合：ユーザーデータにアクセスするすべてのクエリに、userId／tenantId のフィルターが含まれていることを確認します
• 経験則：ユーザーが別のユーザーのデータを閲覧できるなら、それはデータ侵害です

---

フェーズ 2：グラフ（データフロー）

• エントリーポイントを特定します（ルート、アクション、CLI）
• **入力を追跡：**ユーザー入力 → サービス → データベース
• **バリデーションを確認：**境界での Zod／Typebox

フェーズ 3：監査担当（仕様とコードの比較）

• スコープを確認するため、docs/features/*.md を読みます
• **ギャップ分析：**ドキュメントにはあるが、コードには存在しない機能
• **孤立コード分析：**ドキュメントに記載されていないコード（ゾンビコード）

Phase 4: 判定者（ロジックの検証）

最もリスクの高いファイルを選び、次のケースをシミュレーションします。

• 「null を送ったらどうなるか。空文字列では。負の ID では。」
• 「2 つのリクエストが同時にここへ届いたらどうなるか。」（競合状態）
• 「この Service 関数に直接アクセスできるか。」（認証の迂回）

Phase 5: アーキテクト（品質）

• パフォーマンス：ループ内の await → N+1 クエリ
• 肥大化：200 行を超えるファイルはあるか。50 行を超える関数はあるか。
• 型：any または as unknown を使用している箇所はあるか。
• 構成：Feature-Sliced Design に準拠しているか。

Phase 6: レポート

.jstar/audit_report.md を作成します。

重大度	カテゴリ	場所	問題	推奨事項
CRITICAL	SECURITY	api/auth	...	...
HIGH	LOGIC	service.ts:42	...	...
HIGH	GUARDRAIL	package.json	レート制限ツールがインストールされていません	@upstash/ratelimit を追加

重大度：CRITICAL、HIGH、WARNING、INFO カテゴリ：SECURITY、LOGIC、COMPLETENESS、QUALITY、GUARDRAIL

Phase 7: 修正

各 CRITICAL/HIGH について：

1. 修正を実装する
2. ビルド／テストを実行する
3. grep／ロジックチェックで再検証する
4. 変更をステージする