关于 fp-check
用于核实具体疑似漏洞是真实问题还是误报的安全技能。它引导分析者澄清漏洞主张、追踪数据流，并选择标准或深入验证，最后汇总结论和证据。
主要功能
- 01澄清漏洞主张及上下文
- 02追踪从来源到汇点的数据流
- 03选择标准或深入验证流程
- 04批量分流问题并检查利用链
- 05汇总真实问题和误报
适用场景
- 01在报告前验证疑似漏洞
- 02评估已报告的问题是否可利用
- 03分流多个疑似漏洞并评估可能的利用链
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/fp-check确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/bug-class-verification.mddeep-verification.mdevidence-templates.mdfalse-positive-patterns.mdgate-reviews.mdstandard-verification.md详细介绍
误报检查
适用情况
- “这个漏洞是真的吗？”或“这是真阳性吗？”
- “这是误报吗？”或“验证一下这个发现”
- “检查这个漏洞是否可利用”
- 任何要求验证或确认某个具体疑似漏洞的请求
不适用情况
- 查找或搜寻漏洞（“查找漏洞”“安全分析”“审计代码”）
- 针对风格、性能或可维护性的一般代码审查
- 功能开发、重构或非安全相关任务
- 用户明确要求快速扫描，不需要验证
应拒绝的自我开脱
如果你发现自己在想以下任何一种说法，立即停止。
| 自我开脱 | 错误原因 | 必须采取的行动 |
|---|---|---|
| “快速分析剩余漏洞” | 每个漏洞都必须经过完整验证 | 返回任务列表，按照所有阶段验证下一个漏洞 |
| “这种模式看起来很危险，所以它是个漏洞” | 模式识别不等于分析 | 得出结论前，完成数据流追踪 |
| “为了提高效率，跳过完整验证” | 不允许部分分析 | 按照所选验证路径执行所有步骤 |
| “代码看起来不安全，不追踪数据流就直接报告” | 看起来不安全的代码可能在上游经过了验证 | 追踪从源到汇的完整路径 |
| “类似代码在别处存在漏洞” | 每种情况的验证、调用方和防护措施都不同 | 独立验证这个具体实例 |
| “这显然是严重漏洞” | LLM 容易倾向于发现漏洞并高估严重性 | 完成反方审查，并用证据证明 |
步骤 0：理解漏洞主张和上下文
开始分析前，用自己的话重述漏洞。如果无法清楚地做到这一点，请向用户澄清。误报中有一半会在这一步消失——精确重述后，漏洞主张往往缺乏逻辑。
记录：
- 具体的漏洞主张是什么？（例如，“当
content_length超过 4096 时，parse_header()中发生堆缓冲区溢出”） - 据称的根本原因是什么？（例如，“第 142 行
memcpy前缺少边界检查”） - 据称的触发方式是什么？（例如，“攻击者发送带有超大 Content-Length 标头的 HTTP 请求”）
- 声称的影响是什么？（例如，“通过受控堆损坏实现远程代码执行”）
- 威胁模型是什么？ 这段代码以什么权限级别运行？是否在沙箱中？触发这个漏洞前，攻击者已经能做什么？（例如，“未经身份验证的远程攻击者与具有特权的本地用户”；“运行在 Chrome 渲染器沙箱内”与“以 root 身份运行且没有沙箱”）
- 漏洞类别是什么？ 对漏洞分类，并查阅 bug-class-verification.md，了解可补充以下通用阶段的特定类别验证要求。
- 执行上下文：正常执行期间，何时以及如何进入这条代码路径？
- 调用方分析：哪些函数会调用这段代码？它们对输入施加了哪些限制？
- 架构上下文：这是否属于具有多层防护措施的更大安全系统？
- 历史上下文：此代码区域近期是否有改动、已知问题或先前的安全审查？
路径：标准验证或深入验证
完成步骤 0 后，选择一条验证路径。
标准验证
以下条件全部满足时使用：
- 漏洞主张清晰且具体（不含糊或模棱两可）
- 涉及单个组件，漏洞路径中没有跨组件交互
- 漏洞类别明确且易于理解（缓冲区溢出、SQL 注入、XSS、整数溢出等）
- 触发过程中不涉及并发或异步操作
- 从源到汇的数据流简单明了
遵循 standard-verification.md。无需创建任务——按照线性检查清单逐项进行，并在过程中记录发现。
深度验证
符合以下任一条件时使用：
- 存在可能有多种解读的模糊说法
- 跨组件 Bug 路径（数据流经 3 个或更多模块或服务）
- 触发机制中存在竞态条件、TOCTOU 或并发问题
- 缺少明确规范可供核验的逻辑 Bug
- 标准验证未能得出结论或已升级处理
- 用户明确要求完整验证
遵循 deep-verification.md。将工作拆分为完整的任务依赖图，并按阶段有条不紊地执行；如果宿主环境支持，则委派给子 Agent。
默认方式
从标准验证开始。标准验证内置了两个升级检查点，当复杂度超出线性检查清单的范围时，会转入深度验证。
批量分诊
同时验证多个 Bug 时：
- 先对所有 Bug 执行步骤 0——重述每项说法通常就能立即排除明显的误报
- 分别为每个 Bug 选择验证路径（有些走标准验证，有些走深度验证）
- 先处理所有分流到标准验证的 Bug，再处理分流到深度验证的 Bug
- 验证完所有 Bug 后，检查是否存在漏洞利用链——单独来看未通过门槛审查的发现，组合后可能形成可行攻击
最终摘要
处理完所有疑似 Bug 后，提供：
- 计数：X 个真阳性，Y 个假阳性
- 真阳性列表：简要说明每项漏洞
- 假阳性列表：简要说明排除原因
参考资料
- Standard Verification — 用于简单 Bug 的线性单次检查清单
- Deep Verification — 用于复杂 Bug 的完整任务式编排
- Gate Reviews — 六个强制门槛及判定格式
- Bug-Class Verification — 内存损坏、逻辑 Bug、竞态条件、整数问题、加密、注入、信息泄露、DoS 和反序列化的分类验证要求
- False Positive Patterns — 用于识别常见误报模式的 13 项检查清单和警示信号
- Evidence Templates — 数据流、数学证明、攻击者控制和反方审查的文档模板
评论
支持 Markdown