用途
security-audit 是一个服务上线前的 AI 安全审查 skill，目标是发现需要理解代码语义和业务逻辑才能识别的问题，例如数据流追踪与业务逻辑安全。它与 CI/CD 流水线互补：CI/CD 拦截确定性问题（依赖漏洞、硬编码密钥），本 skill 负责需要理解力的审查，两者不重复。
审计范围与深度
收到审计请求后先确定范围与深度：
- 快速扫描：适用于单模块、局部改动或敏感模块修改后，选 1-2 个最相关的维度检查，产出为终端输出结果，不生成报告。
- 完整审计：适用于 release 发版前、新服务首次上线或重大安全相关改动，5 个维度全量检查，产出报告到 docs/audits/YYYY-MM-DD-<服务名>-audit.md。
范围识别包括：确定审计目标（哪些目录/模块/服务，需与用户确认而非猜测）；识别技术栈（检测 package.json / requirements.txt / pyproject.toml / tsconfig.json）；识别敏感区域（路由定义与认证鉴权中间件、数据库操作层、用户输入处理、配置文件如 CORS/安全头/环境变量引用、支付订单与用户数据相关模块）。
五个审查维度
维度 1：注入防护
审查用户可控输入是否经过正确处理后才进入危险操作。检查清单包括：SQL 注入（原生 SQL 拼接、ORM raw query，安全做法为参数化查询、预编译语句）；命令注入（exec()、child_process、os.system()、subprocess，应避免拼接用户输入，使用参数数组）；XSS（innerHTML、dangerouslySetInnerHTML、模板未转义输出，应输出转义、设置 CSP 头）；路径遍历（用户输入拼接文件路径、../ 未过滤，应路径规范化、白名单校验、path.resolve 后检查前缀）；SSRF（用户输入作为 URL 发起服务端请求，应 URL 白名单、禁止内网地址、DNS rebinding 防护）；模板注入（用户输入直接进入模板引擎渲染，应避免动态模板编译、使用沙箱）。
审查方法：找到所有用户输入入口（路由参数、query、body、header、cookie）；追踪每个输入的数据流向及最终到达的危险函数；确认中间是否经过校验/转义/参数化处理。
维度 2：认证与授权
审查每个需要保护的资源是否有正确的认证与授权检查。检查项包括：认证覆盖（是否存在应登录却未加认证中间件的"裸奔"接口）；授权粒度（能否通过改 ID 访问他人数据，即 IDOR）；JWT/Session（密钥强度、过期时间、刷新机制、注销是否真正失效）；CORS 策略（Access-Control-Allow-Origin 是否过于宽松，credentials 模式下的 origin 检查）；密码策略（是否 bcrypt/argon2 哈希存储、是否有强度要求）；权限绕过（前端隐藏不等于后端鉴权）。
审查方法：列出所有路由/接口并标注认证中间件情况；找出"裸奔"接口并判断是否应加认证；检查授权逻辑是否限制当前用户只能操作自己的资源。
维度 3：敏感数据处理
审查敏感数据在存储、传输、日志中是否得到正确保护。检查项包括：密码存储（是否 bcrypt/argon2，是否明文或 MD5/SHA1）；加密算法（是否使用已知弱算法如 DES、RC4、MD5 用于加密）；日志脱敏（日志是否打印密码、token、手机号、身份证号）；错误信息（异常响应是否泄露堆栈、SQL 语句、内部路径）；数据传输（敏感 API 是否强制 HTTPS，cookie 是否设置 Secure 与 HttpOnly）；前端存储（token 存 localStorage 还是 httpOnly cookie）。
审查方法：搜索密码/token 相关的存储与比对逻辑；搜索日志输出（console.log、logger.、print）检查敏感字段；检查错误处理中间件，确认生产环境不返回堆栈信息。
维度 4：配置安全
审查安全相关配置是否合理、生产环境是否加固。检查项包括：安全响应头（X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、CSP）；Debug 模式（生产环境是否关闭 debug/详细错误输出）；默认凭证（是否存在默认密码、测试账号、admin/admin）；速率限制（登录、注册、验证码等接口是否有 rate limit）；文件上传（是否限制类型与大小，存储路径是否在 web 可访问目录外）；环境隔离（生产与开发配置是否分离、环境变量是否正确引用）。
维度 5：业务安全
识别需要理解业务语义才能发现的风险。检查项包括：越权访问 IDOR（修改请求中的 ID/参数能否访问他人数据）；批量枚举（用户名/邮箱是否可通过注册/登录/找回密码的不同返回被枚举）；竞态条件（余额、库存、优惠券核销是否有并发保护）；逻辑绕过（支付金额是否可前端篡改、流程步骤是否可跳过）；重放攻击（关键操作是否有幂等性保护或 nonce 机制）；信息泄露（API 响应是否返回多余字段）。
审查方法：站在攻击者视角思考"如果想偷数据/薅羊毛/搞破坏会怎么做"；检查关键业务操作的参数校验与权限检查；关注前端校验但后端未校验的情况。
风险分级与报告
每个发现按标准分级：高危（可直接导致数据泄露、未授权访问、代码执行，必须修复后才能上线，给出具体修复代码）；中危（存在利用条件但风险可控，或防御纵深不足，建议修复并给出方向）；低危（最佳实践缺失、短期风险较小，记录待改进，不阻断上线）。分级原则：不确定时往高分级；不把所有发现都标高危；已有其他防御措施的可适当降级。
完整审计生成报告到 docs/audits/YYYY-MM-DD-<服务名>-audit.md，包含审计概览（审计日期、范围、技术栈、风险摘要）、审计结论（通过/有条件通过/不通过）、按 5 个维度的详细发现、修复清单表格（等级、维度、问题描述、文件位置、修复建议）与历史审计。每个发现必须包含具体代码位置（文件:行号）、问题描述、攻击场景、修复建议（高危给代码，中危给方向）。
修复与复查
高危问题给出具体修复代码并协助当场修复；修复后复查对应维度确认有效；在修复清单中标记已修复项。
与其他流程的衔接
流程顺序为：CI/CD 安全流水线（pre-commit 用 gitleaks 拦截敏感信息，PR Check 做依赖漏洞与静态规则扫描）→ 自动化通过后进入 security-audit → 审计通过后 release 发版。task-finish 在涉及敏感模块时建议快速扫描，release 在发版前强制完整审计。
限制与注意事项
不替代 CI/CD：依赖漏洞扫描（npm audit）、敏感信息 grep（gitleaks）属于自动化流水线，本 skill 不重复做。不过度报告：只报告真实风险。理解业务再审：建议先用 code-walkthrough 或快速阅读理解业务逻辑。保持攻击者思维：找不到攻击路径的问题不算高危。