---

name: find-bugs description: 查找本地分支变更中的 Bug、安全漏洞和代码质量问题。当被要求审查变更、查找 Bug、安全审查或审计当前分支代码时使用。 risk: unknown source: community

查找 Bug

审查当前分支的变更，查找 Bug、安全漏洞和代码质量问题。

何时使用

• 您需要专注于 Bug、安全问题或高风险代码变更的审查。
• 任务涉及审计当前分支的 diff 而非实现新功能。
• 您需要一个结构化的审查流程，使用检查清单对变更文件进行验证。

第一阶段：完整输入收集

1. 获取完整 diff：git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD
2. 如果输出被截断，逐个读取每个变更文件，直到您看到每一行变更
3. 在继续之前列出此分支中所有修改的文件

第二阶段：攻击面映射

对于每个变更文件，识别并列出：

• 所有用户输入（请求参数、头部、请求体、URL 组件）
• 所有数据库查询
• 所有认证/授权检查
• 所有会话/状态操作
• 所有外部调用
• 所有加密操作

第三阶段：安全检查清单（对每个文件检查每一项）

• [ ] 注入：SQL、命令、模板、头部注入
• [ ] XSS：模板中的所有输出是否正确转义？
• [ ] 认证：所有受保护操作是否有认证检查？
• [ ] 授权/IDOR：是否验证了访问控制，而不仅仅是认证？
• [ ] CSRF：状态变更操作是否受保护？
• [ ] 竞态条件：读取-写入模式中是否存在 TOCTOU？
• [ ] 会话：固定、过期、安全标志？
• [ ] 加密：安全随机数、正确算法、日志中无密钥？
• [ ] 信息泄露：错误消息、日志、时序攻击？
• [ ] DoS：无界操作、缺少速率限制、资源耗尽？
• [ ] 业务逻辑：边界情况、状态机违规、数值溢出？

第四阶段：验证

对于每个潜在问题：

• 检查是否已在变更代码的其他地方处理
• 搜索覆盖该场景的现有测试
• 阅读周围上下文以验证问题是否真实存在

第五阶段：结论前审计

在最终确定之前，您必须：

1. 列出您审查的每个文件并确认已完整阅读
2. 列出每个检查清单项目并注明是否发现问题或确认无问题
3. 列出您无法完全验证的任何区域及原因
4. 然后才提供最终发现

输出格式

优先级：安全漏洞 > Bug > 代码质量

跳过：风格/格式问题

对于每个问题：

• 文件:行号 - 简要描述
• 严重程度：严重/高/中/低
• 问题：哪里出了问题
• 证据：为什么这是真实问题（未被修复、无现有测试等）
• 修复：具体建议
• 参考：OWASP、RFC 或其他适用标准

如果没有发现重大问题，如实说明 — 不要捏造问题。

不要进行修改 — 只报告发现。由我决定处理哪些问题。

限制

• 仅在任务明确符合上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少必要的输入、权限、安全边界或成功标准，请停下来要求澄清。