用途
该技能执行一次综合安全审计，结合自动化静态分析、威胁建模和多视角委员会评审，产出按优先级排序、含可执行修复步骤的审计报告。适用于重大发布前、安全事件后，或新增功能、依赖更新等场景。
范围排除
本审计仅覆盖应用层安全。生产基础设施（TLS 终止、反向代理、网络分段、防火墙规则、DNS）由单独项目负责，不在范围内。不要将缺少 TLS、反向代理配置、网络层 MITM 风险或生产部署拓扑标记为发现项。
主要能力与使用方式
第 1 步：定义审计范围。向用户询问：范围（完整代码库或特定区域，如 apps/api/src/auth/、apps/web/src/）；触发原因（例行、发布前、安全事件、新功能、依赖更新）；重点领域（认证、API 安全、数据保护、前端安全或全部）。检查点：在继续前与用户确认审计范围和重点领域。
第 2 步：自动化 SAST 扫描。在定义范围内调用 /security-scanning:security-sast，扫描注入（SQL、NoSQL、命令、LDAP）、XSS（反射、存储、DOM 型）、CSRF、认证（弱密码策略、认证流程缺陷、会话固定）、密钥（硬编码 API 密钥、密码、令牌、连接字符串）、依赖（npm 包已知 CVE）、反序列化、原型污染。每条发现收集：严重级别（Critical/High/Medium/Low/Info）、类别（OWASP Top 10 映射）、位置（文件路径与行号）、描述、证据、修复建议。
第 3 步：安全加固审查。调用 /security-scanning:security-hardening，覆盖 HTTP 安全（安全头 HSTS、CSP、X-Frame-Options、X-Content-Type-Options；CORS 配置；Cookie 安全标志 HttpOnly、Secure、SameSite）、API 安全（限流、输入验证完整性、输出编码、API 密钥与令牌管理、请求大小限制）、认证与授权（密码哈希算法 bcrypt/argon2、JWT 配置、会话管理、RBAC 执行、OAuth/OIDC 配置）、数据保护（PII 静态加密、传输加密 TLS 1.2+、日志不含敏感数据、错误信息不泄露内部细节、数据库连接使用 SSL）、环境变量（代码或日志中无硬编码密钥、启动校验拒绝生产环境弱/默认密钥）。
第 4 步：STRIDE 威胁建模。调用 /security-scanning:stride-analysis-patterns，系统建模 Spoofing（身份伪造、令牌窃取、服务身份伪造）、Tampering（传输中数据篡改、数据库记录未授权修改、客户端数据篡改）、Repudiation（安全相关操作是否记录、用户能否否认操作、数据变更审计轨迹）、Information Disclosure（错误信息泄露、越权访问他人数据、时序攻击或侧信道）、Denial of Service（请求过载、无限制的资源密集端点、大载荷导致内存耗尽）、Elevation of Privilege（普通用户访问管理功能、横向越权、IDOR）。每条威胁记录：可能性、影响、风险评分（可能性×影响）、现有缓解措施、缺口。
第 5 步：攻击树分析。针对 STRIDE 中风险最高的前 3 个威胁，调用 /security-scanning:attack-tree-construction 构建攻击树，展示攻击目标、攻击路径、子目标、所需资源、现有防御、最薄弱环节。
第 6 步：架构委员会安全评审。激活架构委员会子集（定义于 .claude/councils/architecture-council.md）：安全工程师（负责人，咨询 security-scanning）验证自动化发现、识别误报、按实际风险排序修复、评估整体安全态势；首席工程师（咨询 full-stack-orchestration）评估修复的架构影响、识别产生漏洞的系统性模式、建议纵深防御架构变更；后端专家（咨询 backend-development）评估后端安全模式、API 安全实现质量、数据库访问模式的注入风险。
第 7 步：呈现审计报告。生成结构化报告：执行摘要（整体安全态势、按严重级别统计发现数、前 3 大风险、STRIDE 覆盖摘要）；Critical 与 High 发现（必须修复，含严重级别、类别、OWASP 映射、文件与行号、描述与证据、逐步修复、工作量估算）；Medium 发现（应修复，按风险排序）；Low 与 Info 发现（跟踪，作为技术债务）；威胁模型摘要（STRIDE 结果表、前 3 个攻击树、防御缺口分析）；建议行动（按优先级：立即/本冲刺/下冲刺/待办）。检查点：向用户呈现完整报告，询问哪些发现现在修复、哪些稍后跟踪。
第 8 步：修复（可选）。若用户选择现在修复：按优先级顺序处理（先 Critical 再 High），每个修复应用后重新运行相关 SAST 扫描验证，运行测试确保无回归，提交格式为 fix(security): remediate <finding-description>。
第 9 步：为跟踪的发现创建 Issue。对用户选择稍后跟踪的发现创建 GitHub 议题。检查点：先呈现待创建议题的汇总表（编号、发现、严重级别、估算规模、是否标记 build-ready），请用户确认后再创建。对修复方案明确、范围清晰的发现添加 build-ready 标签；需要进一步规划（如模式变更、新基础设施、跨领域架构决策）的发现省略该标签。创建命令示例：gh issue create --title "security: <finding-description>" --body "<body>" --label "enhancement" --label "security-audit" --label "build-ready"。议题正文包含：背景（哪次审计及日期）、问题（描述与文件路径行号）、建议修复（审计报告中的逐步修复）、优先级（严重级别与建议时间线）、文件（受影响路径）。将每个议题加入项目看板并设置字段（阶段、规模、开始日期、目标日期），按严重级别安排：Critical/High 用 M（3 天）或 L（5 天），排在当前活跃里程碑靠前位置；Medium 用 S（2 天），排在当前里程碑已有排期项之后；Low/Info 用 XS（1 天），排在当前或下一里程碑队尾。向用户报告所有创建的议题编号与 URL。重要：每个跟踪的发现都必须同时有 GitHub 议题和项目看板条目，否则会产生孤立工作项，/build-feature 无法通过自动拾取发现。
第 10 步：关闭跟踪议题（条件性）。若用户以参数形式提供了 GitHub 议题编号（如 /security-audit #137）：用 gh issue edit 勾选议题正文中的审计清单项；检查点：询问用户是否在审计完成后关闭该议题，展示编号与标题确认；若批准，执行 gh issue close <number> --reason completed。若未提供编号则跳过。
第 11 步：交接。向用户呈现下一步：若代码已变更（已应用修复），运行 /review-code 在其他变更上下文中验证修复；若未变更代码（仅审计），无需进一步操作，将发现作为议题或技术债务跟踪；若开始新功能，运行 /plan-feature 在考虑审计发现的情况下开始下一功能。流水线：/plan-feature → /build-feature 或 /build-api → /review-code → /submit-pr。独立使用：/security-audit 可在流水线任意节点或独立运行。
适用场景
重大发布前、安全事件后、新增功能或依赖更新时，需要对应用层代码进行系统化安全审计并产出可执行修复计划的开发团队。
限制
仅覆盖应用层安全，生产基础设施（TLS 终止、反向代理、网络分段、防火墙、DNS）不在范围内。具体收费、价格、平台支持等信息暂未提供。