Code Security Audit

Code Security Audit

Overview

Systematic security audit of any codebase using parallel domain exploration. Launch independent review agents across three security domains simultaneously, then synthesize findings into a structured audit report with severity ratings and concrete remediation steps.

Core principle: Coverage through parallelization. Three focused agents catch more than one broad agent — each domain has different grep patterns, different mental models, and different blind spots.

场景判定（先定深度，再走流程）

默认是全面审计。用户要求"快扫/quick"才降级 L1；"修漏洞"走 security-fix、"再审计/检查修复"走 Phase 4。场景不清时按全面审计走，深度宁高勿低。

Slash Commands / Modes

/audit 与 /reaudit 的入口说明见 references/reaudit-modes.md（含各模式逐步操作、报告路径探测、退出码约定）。

When to Use

Trigger when the user asks to:

• Audit a repository or codebase for security issues
• Perform a security review or vulnerability assessment
• Check if security fixes were properly applied (re-audit)
• Find vulnerabilities before a release or deployment

Do NOT use for:

• Reviewing a single PR diff (use dev-workflow)
• Checking one specific function for bugs (use systematic-debugging)
• General code review for style/architecture (use dev-workflow, which ships its own code-review checklist)

Audit Workflow

Full per-phase protocol: references/audit-workflow.md

Required before Phase 1:

1. Read references/vulnerability-patterns.md
2. Run git rev-parse HEAD and record the audit commit
3. Probe the project language/framework
4. Check for a prior docs/SECURITY_AUDIT.md report

Phase summary:

• Phase 1 — Parallel Exploration: launch 3 domain agents (secrets, injection, auth/crypto/deps)；L2/L3 另加 Agent D（业务逻辑 / 功能滥用 / 链式信任边界 / Wildcard）；并行失败时回退到单个综合 agent。
• Phase 2 — Deep-Dive Verification: 先过 vulnerability-patterns.md 的「不算 Finding 判别表」，读回被标记的代码，去重，跑 5 点 Self-Check；Critical/High 由没参与该条发现的新 agent 回读源码复核（可再叠加 review.py 跨模型对抗）；最后定严重度、稳定前缀 ID 与 VERDICT。
• Phase 3 — Report Compilation: write the report with references/audit-report-template.md；必须含非空 ## Coverage 段；every finding carries <!-- AUDIT:... --> annotations.
• Phase 4 — Re-Audit: parse annotations, diff-filter to changed files, verify each changed finding, update status and commit.

Vulnerable Patterns Reference

Grep patterns and remediation templates per category live in references/vulnerability-patterns.md — read it before Phase 2 (Pre-Flight requires it). 它的「不算 Finding 判别表」是 Phase 2 的第一道闸：先过表，再谈严重度。

references/attack-surfaces.md 覆盖另外 5 个面（AI/LLM、供应链/CI、桌面/本地 IPC、资源耗尽、数据隔离）—— 主流程三域不查这些。按需懒加载：只在侦察发现对应边界时才读那一段，不要一次性读全文。

认识态（VERDICT）不是修复态（STATUS） —— 两者正交，见 references/vulnerability-patterns.md §18：

Do NOT — Negative Heuristics

These actions are FORBIDDEN during an audit. They are the most common ways audits silently degrade:

• Do NOT skip the Pre-Flight checks even on a "quick scan." The gate is unconditional.
• Do NOT accept an agent finding without reading the flagged code yourself. Agents summarize; you verify.
• Do NOT assign Critical or High severity from a single grep match. Must be confirmed by a different method.
• Do NOT suppress a finding because confidence is low. That decision belongs to Phase 2, not Phase 1.
• Do NOT close a finding because "it's probably fine." See Meta-Cognition Trap.
• Do NOT write the audit report before completing Phase 2 verification. Phase 3 only after Phase 2.
• Do NOT skip status annotations on findings. Without <!-- AUDIT:STATUS=... -->, mark-fixed and incremental re-audit break.
• Do NOT use sequential IDs (N1, N2...). Use category-prefixed IDs (SSRF-1, PATH-1).
• Do NOT 给 needs-validation / rejected 定严重度。 不确定就不许定级 —— 把"证据不足的严重问题"降级成"证据充分的轻微问题"，是审计里最贵的错误。
• Do NOT 丢掉 rejected 记录。 留档（附 REASON=）才能让下一轮不重打同一枪。
• Do NOT 让发现者复核自己。 Critical/High 必须由一个没参与该条发现的新 agent 回读源码复核。
• Do NOT 省略 ## Coverage 段。 没交代"哪些面没审计"，报告就是在暗示完整覆盖。

Critical Reminders — read before every audit phase

These rules are NON-NEGOTIABLE and take precedence over all other considerations:

1. Gate before code: Pre-Flight checks are unconditional. Never touch a file before they complete.
2. Verify before reporting: Every finding passes the 5-point Self-Check. Fail any check → not a finding.
3. Two methods for severity: Critical/High cannot rest on a single grep hit. Independent confirmation or downgrade.
4. Rationalization = escalation: "probably fine" / "won't reach this code" / "obvious fix" → STOP and re-verify.
5. Confidence is reported, not filtered: Low-confidence findings enter Phase 2. Phase 2 decides, not Phase 1.
6. Stable IDs always: Category-prefixed, sequential within prefix. Never shift existing IDs in re-audits.
7. 不确定不许定级: needs-validation / rejected 不带 SEVERITY —— 只有 confirmed 配严重度。
8. 单次运行 ≠ 完整覆盖: 报告只声明 ## Coverage 表所列范围，不写"仓库已安全"。

After the Audit

• Report location: Place the report at docs/SECURITY_AUDIT.md by default. Add it to .gitignore so it stays local.
• Contract check: 收工前跑 python bin/security_audit_tools.py validate —— 校验 VERDICT/SEVERITY 互斥、FILE 存在且是仓库根相对路径、LINES 不越界、fixed 的 COMMIT 是 HEAD 祖先、## Coverage 段非空。
• Follow-up: Offer to fix the highest-priority findings (P1 items)。VERDICT=confirmed 的才进修复队列。
• Pattern collection: After the audit, review references/vulnerability-patterns.md. Add any new patterns you discovered 以及它的排除条件（不算 Finding 判别表里补一行）—— 没有排除条件的模式是误报来源。This is how the skill evolves.

自进化日志

每次审计实践吸收的模式记录于此，skill 随之进化：