security-audit

安全审计工作流

执行全面的安全审计，结合自动化静态分析、威胁建模和多视角评审。此技能会生成一份按优先级排序的审计报告，其中包含可执行的修复步骤。

范围排除项

重要

本次审计仅涵盖应用级安全。生产基础设施（TLS 终止、反向代理、网络分段、防火墙规则、DNS）由单独的项目管理，不在审计范围内。不要将缺少 TLS、反向代理配置、网络层 MITM 风险或生产部署拓扑列为审计发现。

步骤 1：定义审计范围

询问用户：

• 范围：整个代码库还是特定区域？（例如，apps/api/src/auth/、apps/web/src/）
• 触发原因：是什么促使开展此次审计？（例行审计、发布前、安全事件、新功能、依赖项更新）
• 重点领域：身份验证、API 安全、数据保护、前端安全，还是全部？

CHECKPOINT：在继续之前，与用户确认审计范围和重点领域。

步骤 2：自动化 SAST 扫描

对已定义的范围调用 /security-scanning:security-sast。

扫描以下问题：

• 注入：SQL 注入、NoSQL 注入、命令注入、LDAP 注入
• XSS：反射型、存储型和基于 DOM 的跨站脚本攻击
• CSRF：状态变更端点缺少 CSRF 防护
• 身份验证：密码策略薄弱、身份验证流程存在缺陷、会话固定
• 机密信息：硬编码的 API 密钥、密码、令牌、连接字符串
• 依赖项：npm 包中的已知漏洞（CVE）
• 反序列化：不安全的反序列化模式
• 原型污染：特定于 JavaScript 的对象操作攻击

记录每项发现，包含：

• 严重性：严重 / 高 / 中 / 低 / 信息
• 类别：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 配置（算法、过期时间、刷新）
• 会话管理（超时、失效、轮换）
• 强制执行基于角色的访问控制
• OAuth/OIDC 配置（如适用）

数据保护

• 静态存储的 PII 已加密
• 传输中的敏感数据已加密（TLS 1.2+）
• 日志不包含敏感数据
• 错误消息不会泄露内部细节
• 数据库连接使用 SSL

环境变量

• 代码或日志中没有硬编码的机密信息
• 启动时验证会拒绝生产环境中薄弱或默认的机密信息

步骤 4：STRIDE 威胁建模

调用 /security-scanning:stride-analysis-patterns，系统地建模威胁：

欺骗

• 用户身份是否可能被伪造？（绕过身份验证、令牌窃取）
• 服务身份是否可能被仿冒？（服务间身份验证）

篡改

• 请求数据在传输过程中是否可能被修改？
• 数据库记录是否可能在未授权的情况下被篡改？
• 客户端数据（localStorage、Cookie）是否可能被篡改？

抵赖

• 是否记录了所有与安全相关的操作？
• 用户是否可以否认执行过某项操作？
• 数据变更是否有审计跟踪？

信息泄露

• 敏感数据是否可能通过错误消息泄露？
• 未授权用户是否能够访问其他用户的数据？
• 是否存在计时攻击或侧信道泄漏？

拒绝服务

• 系统是否会因请求过多而不堪重负？
• 是否存在未实施速率限制的高资源消耗端点？
• 大型负载是否会导致内存耗尽？

权限提升

• 普通用户是否可以访问管理员功能？
• 是否可能发生水平权限提升（访问其他用户的资源）？
• 是否存在 IDOR（不安全的直接对象引用）漏洞？

请为每项威胁记录：

• 可能性：高 / 中 / 低
• 影响：严重 / 高 / 中 / 低
• 风险评分：可能性 x 影响
• 现有缓解措施：目前已有的措施
• 缺口：缺少的措施

步骤 5：攻击树分析

针对 STRIDE 中识别出的风险最高的 3 项威胁：

调用 /security-scanning:attack-tree-construction，构建攻击树，展示：

• 攻击目标：攻击者想要实现什么
• 攻击路径：实现目标的不同途径
• 子目标：所需的中间步骤
• 所需资源：攻击者所需的技能水平、工具和访问权限
• 现有防御措施：各条路径上的现有缓解措施
• 薄弱环节：防御最薄弱之处

步骤 6：架构委员会安全审查

启用架构委员会（定义于 .claude/councils/architecture-council.md）中的一部分成员进行安全审查：

模型选择：有关将 Agent 模型规格映射到 Task 工具参数的信息，请参阅 README.md 中的模型选择部分。

安全工程师（负责人）——咨询：security-scanning

• 验证自动化发现结果（识别误报）
• 根据实际风险确定修复优先级
• 评估整体安全态势
• 评估：强 / 适当 / 需要改进 / 存在严重风险

首席工程师——咨询：full-stack-orchestration

• 评估所需修复措施对架构的影响
• 识别导致漏洞的系统性模式
• 建议通过纵深防御进行架构调整
• 评估：架构合理 / 需要重构 / 存在根本性问题

后端专家——咨询：backend-development

• 评估后端特定的安全模式
• 评估 API 安全实现的质量
• 检查数据库访问模式是否存在注入风险
• 评估：安全性良好 / 存在一些缺口 / 存在重大隐患

步骤 7：提交审计报告

生成结构化的安全审计报告：

执行摘要

• 整体安全态势：强 / 适当 / 需要改进 / 严重
• 发现总数：按严重程度统计（严重、高、中、低）
• 风险最高的 3 项：最需要处理的问题
• STRIDE 覆盖情况：各威胁类别及风险等级摘要

严重和高风险发现（必须修复）

针对每项发现：

• 严重程度、类别和 OWASP 映射
• 文件和行号
• 附有证据的描述
• 分步骤修复方案
• 工作量估算（快速修复 / 中等 / 较大）

中风险发现（应该修复）

采用上述相同格式，并按风险确定优先级。

低风险和信息类发现（跟踪）

用于跟踪技术债务的摘要列表。

威胁模型摘要

• STRIDE 分析结果表
• 风险最高的 3 项攻击树（可视化或结构化文本）
• 防御缺口分析

建议措施（按优先级排序）

1. 立即处理（严重）：必须在下次部署前修复
2. 本迭代处理（高）：在当前工作周期内修复
3. 下个迭代处理（中）：安排在接下来的工作中
4. 待办列表（低）：作为技术债务跟踪

检查点：向用户展示完整审计报告。询问他们希望现在修复哪些发现，以及哪些留待以后跟踪。

步骤 8：修复（可选）

如果用户选择立即修复发现的问题：

1. 按优先级处理问题（先处理严重问题，再处理高优先级问题）
2. 对于每项修复：
   • 应用修复措施
   • 重新运行相关的 SAST 扫描，以验证修复效果
   • 运行测试，确保没有引入回归问题
3. 使用以下内容提交每项修复：

   fix(security): remediate <finding-description>
   

修复完成后，建议用户执行下一步（见下文）。

步骤 9：为需要跟踪的问题创建 Issue

对于用户选择留待以后跟踪（而非在步骤 8 中立即修复）的问题，创建 GitHub issue，以免遗漏。

检查点：继续之前，先展示一个汇总表，列出将创建为 issue 的问题。

#	问题	严重性	预计工作量	添加 build-ready 标签？
1	<description>	Medium	S	Yes

询问用户确认哪些问题应创建为 issue。获得批准后再创建。

说明

对于修复方案明确且范围清晰的问题（已知如何修复，且不需要做架构决策），添加 build-ready 标签。对于需要通过 /plan-feature 进一步规划的问题（例如需要更改架构、搭建新基础设施或做跨领域架构决策的问题），不要添加 build-ready 标签。

1. 为每项获批的问题创建 GitHub issue：

   ISSUE_URL=$(gh issue create \
     --title "security: <finding-description>" \
     --body "<body>" \
     --label "enhancement" \
     --label "security-audit" \
     --label "build-ready")
   
   ISSUE_NUM=$(echo "$ISSUE_URL" | grep -o '[0-9]*$')
   

   对于需要进一步规划的问题（见上方注释），不要添加 --label "build-ready"。

   Issue 正文应包含：

   • 背景：识别出该问题的审计类型及审计日期
   • 问题：问题描述，以及文件路径和行号
   • 建议的修复方案：审计报告中逐步列出的修复措施
   • 优先级：严重性评级和建议的处理时间
   • 文件：受影响的文件路径

2. 将每个已创建的 issue 添加到项目看板，并设置字段：

   ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "$ISSUE_URL" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {SIZE_FIELD_ID} --single-select-option-id <size-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {START_FIELD_ID} --date <start-date>
   gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {TARGET_FIELD_ID} --date <target-date>
   

   根据问题的优先级和当前里程碑，设置阶段、工作量和日期：

   严重性	典型工作量	计划优先级
   Critical/High	M（3 天）或 L（5 天）	当前进行中的里程碑，排在队列靠前位置
   Medium	S（2 天）	当前里程碑，排在已有计划事项之后
   Low/Info	XS（1 天）	当前或下一个里程碑，排在队列末尾

3. 向用户报告所有已创建的 issue 编号（$ISSUE_NUM）和 URL。

重要

每个需要跟踪的问题都必须同时有 GitHub issue 和项目看板条目。如果创建 issue 后未将其添加到项目看板，就会产生孤立的工作项，导致 /build-feature 无法通过自动选取发现它们。

步骤 10：关闭跟踪 Issue（有条件）

如果用户提供了 GitHub issue 编号作为参数（例如 /security-audit #137）：

1. 使用 gh issue edit 勾选 issue 正文中的审计检查清单项
2. 检查点：询问用户是否要在审计完成后关闭该 issue。展示 issue 编号和标题以供确认。
3. 如果用户批准，则关闭 issue：

   gh issue close <number> --reason completed
   

如果用户未提供 issue 编号，则跳过此步骤。

步骤 11：交接

向用户说明下一步：

• 如果修改了代码（已应用修复）：运行 /review-code，结合其他更改检查修复
• 如果未修改代码（仅审计）：无需进一步操作——将发现的问题作为 issue 或技术债务跟踪
• 如果要开始新功能：运行 /plan-feature，在考虑审计发现的基础上开始规划下一项功能

流程：/plan-feature → /build-feature 或 /build-api → /review-code → /submit-pr

独立运行：可在流程中的任意阶段或单独运行 /security-audit。