code-audit

コード監査スキル

専門的なコードセキュリティ監査スキル | Professional Code Security Audit 対応モード: quick / standard / deep

このスキルを使用する場面

次の場合にこのスキルを使用してください。

• ユーザーがコード監査、セキュリティ監査、または脆弱性スキャンを依頼した場合
• ユーザーがコードのセキュリティを確認する、またはセキュリティ上の問題を見つけるよう依頼した場合
• ユーザーが**/auditまたは/code-audit**に言及した場合
• ユーザーがデプロイ前にコードの脆弱性をレビューすることを希望した場合
• ユーザーが侵入テストの準備またはセキュリティ評価を必要としている場合

トリガーフレーズ:

• "このプロジェクトを監査して" / "Audit this project"
• "コードのセキュリティを確認して" / "Check code security"
• "セキュリティ脆弱性を見つけて" / "Find security vulnerabilities"
• "/audit", "/code-audit"

---

クイックリファレンス

スキャンモード

モード	ユースケース	対象範囲
Quick	CI/CD、小規模プロジェクト	高リスクの脆弱性、シークレット、依存関係のCVE
Standard	定期的な監査	OWASP Top 10、認証、暗号化
Deep	重要なプロジェクト、侵入テスト	全範囲、攻撃チェーン、ビジネスロジック

コアワークフロー

1. Reconnaissance   → Identify tech stack, map attack surface
2. Vulnerability Hunt → Search patterns, trace data flow
3. Verification    → Confirm exploitability, filter false positives
4. Docker Verify   → [NEW] Dynamic verification in sandbox (optional)
5. Report          → Document findings with PoC and fixes

Docker デプロイの検証

深度監査では、Docker サンドボックスを使用して動的検証を実施できます。

# 生成验证环境
code-audit --generate-docker-env

# 启动并验证
docker-compose up -d
docker exec -it sandbox python /workspace/poc/verify_all.py

詳細は references/core/docker_verification.md を参照してください。

---

実行コントローラー（実行必須パス）

⚠️ 以下の手順は監査実行に必須のパスであり、参考情報ではありません。 各手順では必須の出力があり、後続の手順は前の手順の出力に依存します。出力しない場合、ユーザーに見える形で不足が生じます。

Step 1: モード判定

ユーザーの指示に基づいて監査モードを決定します。

ユーザーの指示に含まれるキーワード	モード
"クイックスキャン" "quick" "CI チェック"	quick
"監査" "スキャン" "セキュリティチェック"（特別な指定なし）	standard
"深度監査" "deep" "侵入テストの準備" "包括的な監査"	deep
判定できない	ユーザーに確認し、独断で仮定してはなりません

モードの格下げ禁止ルール: ユーザーが指定したモードを独断で格下げしてはなりません。プロジェクトの規模が大きいことは格下げの理由ではなく、Multi-Agent を有効にする理由です。格下げにはユーザーの明示的な確認が必要です。

必須出力:

[MODE] {quick|standard|deep}

Step 2: ドキュメントの読み込み

モードに応じて必要なドキュメントを読み込みます（Read ツールを使って実際に読み取ってください。「このファイルがあると知っている」だけでは不十分です）。

モード	必ず Read するドキュメント
quick	現在の SKILL.md は読み込み済みのため、追加のドキュメントは不要
standard	+ references/checklists/coverage_matrix.md + 該当する言語のチェックリスト
deep	+ agent.md（全文を読み込み、スキップ不可） + coverage_matrix.md + 該当する言語のチェックリスト

deep モードでは agent.md の読み込みが必須です。Step 4 の実行計画テンプレートには、agent.md にしかないフィールド（次元の重み付け、Agent 分割テンプレート、ゲート条件、実行状態マシン）が含まれています。

必須出力:

[LOADED] {实际 Read 的文档列表，含行数}

Step 3: 偵察（Reconnaissance）

対象プロジェクトの攻撃対象領域をマッピングします。

必須出力:

[RECON]
项目规模: {X files, Y directories}
技术栈: {language, framework, version}
项目类型: {CMS | 金融 | SaaS | 数据平台 | 身份认证 | IoT | 通用Web}
入口点: {Controller/Router/Handler 数量}
关键模块: {列表}

Step 4: 実行計画 → STOP

Step 1〜3 の出力に基づいて実行計画を生成します。出力後に一時停止し、ユーザーの確認を待ってから続行してください。

quick/standard テンプレート:

[PLAN]
模式: {mode}
技术栈: {from Step 3}
扫描维度: {计划覆盖的 D1-D10 维度}
已加载文档: {from Step 2}

deep テンプレート（すべてのフィールドが必須 — 情報源のドキュメントを明記）:

[PLAN]
模式: deep
项目规模: {from Step 3}
技术栈: {from Step 3}
维度权重: {from agent.md 状态机 → 项目类型维度权重，如 CMS: D5(++), D1(+), D3(+), D6(+)}
Agent 方案: {from agent.md Agent 模板 → 每个 Agent 负责的维度和 max_turns}
Agent 数量: {from agent.md 规模建议 → 小型(<10K) 2-3, 中型(10K-100K) 3-5, 大型(>100K) 5-9}
D9 覆盖策略: {若项目有后台管理/多角色/多租户 → D9 必查，D3 Agent 须同时覆盖 D9a(IDOR+权限一致性+Mass Assignment)}
轮次规划: R1 广度扫描 → R1 评估 → R2 增量补漏(按需)
门控条件: PHASE_1_RECON → ROUND_N_RUNNING → ROUND_N_EVALUATION → REPORT
预估总 turns: {Agent数 × max_turns}
已加载文档: {from Step 2}

⚠️ STOP — 実行計画を出力した後に一時停止してください。ユーザーの確認後にのみ監査を開始できます。

Step 5: 実行

ユーザーの確認後、実行計画と読み込み済みドキュメントに従って実行します。

• quick: 高リスクパターンのマッチングスキャンを実施し、そのまま出力します
• standard: Phase 1→5 の順に実行します
• deep: agent.md の実行状態マシンに厳密に従います
  • Multi-Agent を起動して並列実行します（Step 4 で確認された Agent 構成に従います）
  • 各 State のゲート条件を遵守します
  • 各ラウンドの評価では agent.md の三問ルールを使用します

Step 6: レポートのゲート判定

レポートを生成する前に、次の条件を確認します。

前提条件	quick	standard	deep
高リスクパターンのスキャン完了	✅	✅	✅
D1-D10 のカバレッジ表示（✅カバー済み/⚠️一部カバー/❌未カバー）	—	✅	✅
すべての Agent が完了、またはタイムアウトの注記あり	—	—	✅
各ラウンドの評価で三問を通過	—	—	✅

前提条件を満たしていない場合 → 最終レポートを生成してはなりません。

---

幻覚防止ルール（必ず遵守）

⚠️ Every finding MUST be based on actual code read via tools

✗ Do NOT guess file paths based on "typical project structure"
✗ Do NOT fabricate code snippets from memory
✗ Do NOT report vulnerabilities in files you haven't read

✓ MUST use Read/Glob to verify file exists before reporting
✓ MUST quote actual code from Read tool output
✓ MUST match project's actual tech stack

基本原則: 偽陽性を報告するより、脆弱性を見逃すほうが望ましいです。

---

確証バイアス防止ルール（必ず遵守）

⚠️ Audit MUST be methodology-driven, NOT case-driven

✗ Do NOT say "基于之前的审计经验，我将重点关注..."
✗ Do NOT prioritize certain vuln types based on "known CVEs"
✗ Do NOT skip checklist items because they seem "less likely"

✓ MUST enumerate ALL sensitive operations, then verify EACH one
✓ MUST complete the full checklist for EACH vulnerability type
✓ MUST treat all potential vulnerabilities with equal rigor

基本原則: 見慣れたパターンだけでなく、潜在的な脆弱性をすべて見つけてください。

---

2 層チェックリスト

Layer 1: coverage_matrix.md — Phase 2A 後に読み込み、10 のセキュリティ次元のカバレッジを検証します Layer 2: 言語別の意味論ヒント — 未カバーの次元に限り、必要に応じて該当するセクションを読み込みます

ファイル	用途
references/checklists/coverage_matrix.md	カバレッジマトリックス (D1-D10)
references/checklists/universal.md	汎用のアーキテクチャ／ロジックレベルの意味論ヒント
references/checklists/java.md	Java の意味論ヒント (10 次元)
references/checklists/python.md	Python の意味論ヒント
references/checklists/php.md	PHP の意味論ヒント
references/checklists/javascript.md	JavaScript/Node.js の意味論ヒント
references/checklists/go.md	Go の意味論ヒント
references/checklists/dotnet.md	.NET/C# の意味論ヒント
references/checklists/ruby.md	Ruby の意味論ヒント
references/checklists/c_cpp.md	C/C++ の意味論ヒント
references/checklists/rust.md	Rust の意味論ヒント

基本原則: チェックリストは監査を主導するものではなく、カバレッジを検証するものです。LLM がまず自由に監査し（Phase 2A）、次にマトリックスを使って見落としを確認します（Phase 2B）。

---

モジュールリファレンス

コアモジュール（最初に読み込む）

モジュール	パス	目的
能力ベースライン	references/core/capability_baseline.md	能力低下を防ぐ回帰テストフレームワーク
ハルシネーション対策	references/core/anti_hallucination.md	誤検出を防止します
監査方法論	references/core/comprehensive_audit_methodology.md	体系的なフレームワーク、カバレッジの追跡
汚染解析	references/core/taint_analysis.md	データフローの追跡、LSP による追跡強化、スロット型の分類
PoC 生成	references/core/poc_generation.md	検証テンプレート
外部ツール	references/core/external_tools_guide.md	Semgrep/Bandit の統合

言語モジュール（技術スタックに応じて読み込む）

言語	モジュール	主な脆弱性
Java	references/languages/java.md	SQL インジェクション、XXE、デシリアライゼーション
Python	references/languages/python.md	Pickle、SSTI、コマンドインジェクション
Go	references/languages/go.md	競合状態、SSRF
PHP	references/languages/php.md	ファイルインクルージョン、デシリアライゼーション
JavaScript	references/languages/javascript.md	プロトタイプ汚染、XSS

セキュリティ領域モジュール（必要に応じて読み込む）

領域	モジュール	読み込むタイミング
API セキュリティ	references/security/api_security.md	REST/GraphQL API
LLM セキュリティ	references/security/llm_security.md	AI/ML アプリケーション
サーバーレス	references/security/serverless.md	AWS Lambda、Azure Functions
暗号技術	references/security/cryptography.md	暗号化、TLS、JWT
競合状態	references/security/race_conditions.md	並行処理

---

ツールの優先順位戦略

Priority 1: External Professional Tools (if available)
├─ semgrep scan --config auto          # Multi-language SAST
├─ bandit -r ./src                      # Python security
├─ gosec ./...                          # Go security
└─ gitleaks detect                      # Secret scanning

Priority 2: Built-in Analysis (always available)
├─ LSP semantic analysis                # goToDefinition, findReferences, incomingCalls
├─ Read + Grep pattern matching         # Core analysis
└─ Module knowledge base                # 55+ vuln patterns

Priority 3: Verification
├─ PoC templates from references/core/poc_generation.md
└─ Confidence scoring from references/core/verification_methodology.md

---

詳細ドキュメント

完全な監査方法論、脆弱性パターン、検出ルールについては、以下を参照してください。

• 完全なワークフロー：agent.md — 監査プロセス全体と検出コマンド
• 脆弱性の詳細：references/ — 言語／フレームワーク固有のパターン
• ツールの統合：references/core/external_tools_guide.md
• レポートテンプレート：references/core/taint_analysis.md

---

バージョン

• 現在：1.0
• 更新日：2026-02-13

v1.0（初回一般公開）

• 9言語、143項目の必須検査チェックリスト（references/checklists/）
• 二軌並行監査フレームワーク：Sink 主導 + Control 主導 + Config 主導
• Docker デプロイ検証フレームワーク（references/core/docker_verification.md）
• WooYun の 88,636 件の事例データベースとの統合
• セキュリティ制御マトリックスフレームワーク