Back to Details

fp-check

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

False Positive Check

误报核查

When to Use

适用场景

  • "Is this bug real?" or "is this a true positive?"
  • "Is this a false positive?" or "verify this finding"
  • "Check if this vulnerability is exploitable"
  • Any request to verify or validate a specific suspected bug
  • 「这个漏洞是真实存在的吗？」或「这是真实有效漏洞吗？」
  • 「这是误报吗？」或「验证这条发现结果」
  • 「检查这个漏洞是否可被利用」
  • 任何要求验证特定疑似漏洞的请求

When NOT to Use

不适用场景

  • Finding or hunting for bugs ("find bugs", "security analysis", "audit code")
  • General code review for style, performance, or maintainability
  • Feature development, refactoring, or non-security tasks
  • When the user explicitly asks for a quick scan without verification
  • 寻找或挖掘漏洞（「找漏洞」、「安全分析」、「代码审计」）
  • 针对代码风格、性能或可维护性的常规代码评审
  • 功能开发、重构或非安全类任务
  • 用户明确要求仅进行快速扫描无需验证的场景

Rationalizations to Reject

应当避免的错误认知

If you catch yourself thinking any of these, STOP.
RationalizationWhy It's WrongRequired Action
"Rapid analysis of remaining bugs"Every bug gets full verificationReturn to task list, verify next bug through all phases
"This pattern looks dangerous, so it's a vulnerability"Pattern recognition is not analysisComplete data flow tracing before any conclusion
"Skipping full verification for efficiency"No partial analysis allowedExecute all steps per the chosen verification path
"The code looks unsafe, reporting without tracing data flow"Unsafe-looking code may have upstream validationTrace the complete path from source to sink
"Similar code was vulnerable elsewhere"Each context has different validation, callers, and protectionsVerify this specific instance independently
"This is clearly critical"LLMs are biased toward seeing bugs and overrating severityComplete devil's advocate review; prove it with evidence
如果你发现自己有以下任何想法，请立刻停止。
错误认知错误原因正确操作
「快速分析剩余漏洞」每个漏洞都需要完整验证返回任务列表，按全流程验证下一个漏洞
「这个模式看起来有风险，所以是漏洞」模式识别不等于分析在得出任何结论前完成数据流追踪
「为了效率跳过完整验证」不允许进行部分分析按照选定的验证路径执行所有步骤
「代码看起来不安全，不追踪数据流就上报」看起来不安全的代码可能有上游校验追踪从源头到接收点的完整路径
「其他地方的类似代码存在漏洞」每个上下文的校验逻辑、调用方和防护机制都不同独立验证当前这个特定实例
「这明显是严重漏洞」LLM 倾向于过度识别漏洞、高估严重程度完成反向质疑评审，用证据证明结论

Step 0: Understand the Claim and Context

第0步：理解声明与上下文

Before any analysis, restate the bug in your own words. If you cannot do this clearly, ask the user for clarification using AskUserQuestion. Half of false positives collapse at this step — the claim doesn't make coherent sense when restated precisely.
Document:
  • What is the exact vulnerability claim? (e.g., "heap buffer overflow in 
    parse_header()
    when 
    content_length
    exceeds 4096")
  • What is the alleged root cause? (e.g., "missing bounds check before 
    memcpy
    at line 142")
  • What is the supposed trigger? (e.g., "attacker sends HTTP request with oversized Content-Length header")
  • What is the claimed impact? (e.g., "remote code execution via controlled heap corruption")
  • What is the threat model? What privilege level does this code run at? Is it sandboxed? What can the attacker already do before triggering this bug? (e.g., "unauthenticated remote attacker vs privileged local user"; "runs inside Chrome renderer sandbox" vs "runs as root with no sandbox")
  • What is the bug class? Classify the bug and consult bug-class-verification.md for class-specific verification requirements that supplement the generic phases below.
  • Execution context: When and how is this code path reached during normal execution?
  • Caller analysis: What functions call this code and what input constraints do they impose?
  • Architectural context: Is this part of a larger security system with multiple protection layers?
  • Historical context: Any recent changes, known issues, or previous security reviews of this code area?
在开展任何分析前，用自己的话重述漏洞。如果你无法清晰表述，使用 AskUserQuestion 向用户索要澄清。一半的误报在这一步就会被排除——当你精准重述时，漏洞声明本身就站不住脚。
记录以下信息：
  • 准确的漏洞声明是什么？（例如：「当 
    content_length
    超过4096时，
    parse_header()
    存在堆缓冲区溢出」）
  • 声称的根本原因是什么？（例如：「第142行执行 
    memcpy
    前缺失边界检查」）
  • 假定的触发条件是什么？（例如：「攻击者发送 Content-Length 头过大的HTTP请求」）
  • 声称的影响是什么？（例如：「通过可控堆破坏实现远程代码执行」）
  • 威胁模型是什么？ 这段代码运行的权限级别是什么？是否在沙箱中运行？触发漏洞前攻击者已经具备哪些权限？（例如：「未认证远程攻击者 vs 高权限本地用户」；「运行在Chrome渲染器沙箱内」 vs 「无沙箱以root权限运行」）
  • 漏洞类型是什么？ 对漏洞进行分类，查阅 bug-class-verification.md 获取特定漏洞类型的验证要求，作为以下通用阶段的补充。
  • 执行上下文：正常执行过程中，这个代码路径何时、如何被触发？
  • 调用方分析：哪些函数调用这段代码，它们施加了哪些输入约束？
  • 架构上下文：这段代码是否属于带有多层防护的大型安全系统的一部分？
  • 历史上下文：该代码区域最近是否有变更、已知问题，或此前做过安全评审？

Route: Standard vs Deep Verification

路径选择：标准验证 vs 深度验证

After Step 0, choose a verification path.
完成第0步后，选择一条验证路径。

Standard Verification

标准验证

Use when ALL of these hold:
  • Clear, specific vulnerability claim (not vague or ambiguous)
  • Single component — no cross-component interaction in the bug path
  • Well-understood bug class (buffer overflow, SQL injection, XSS, integer overflow, etc.)
  • No concurrency or async involved in the trigger
  • Straightforward data flow from source to sink
Follow standard-verification.md. No task creation — work through the linear checklist, documenting findings inline.
当以下所有条件都满足时使用：
  • 漏洞声明清晰具体（不模糊、无歧义）
  • 仅涉及单个组件——漏洞路径不存在跨组件交互
  • 漏洞类型被充分了解（缓冲区溢出、SQL injection、XSS、整数溢出等）
  • 触发逻辑不涉及并发或异步操作
  • 从源头到接收点的数据流简单直接
遵循 standard-verification.md。无需创建任务，按照线性检查清单推进，在行内记录发现结果。

Deep Verification

深度验证

Use when ANY of these hold:
  • Ambiguous claim that could be interpreted multiple ways
  • Cross-component bug path (data flows through 3+ modules or services)
  • Race conditions, TOCTOU, or concurrency in the trigger mechanism
  • Logic bugs without a clear spec to verify against
  • Standard verification was inconclusive or escalated
  • User explicitly requests full verification
Follow deep-verification.md. Create the full task dependency graph and execute phases with the plugin's agents.
当满足以下任一条件时使用：
  • 声明存在歧义，可被多种方式解读
  • 漏洞路径跨组件（数据流经过3个及以上模块或服务）
  • 触发机制存在竞态条件、TOCTOU 或并发问题
  • 逻辑漏洞没有明确的规范可用于验证
  • 标准验证无法得出结论或需要升级处理
  • 用户明确要求完整验证
遵循 deep-verification.md。创建完整的任务依赖图，通过插件的Agent执行各个阶段。

Default

默认规则

Start with standard. Standard verification has two built-in escalation checkpoints that route to deep when complexity exceeds the linear checklist.
从标准验证开始。标准验证内置两个升级检查点，当复杂度超出线性检查清单的处理范围时，会切换到深度验证。

Batch Triage

批量分诊

When verifying multiple bugs at once:
  1. Run Step 0 for all bugs first — restating each claim often collapses obvious false positives immediately
  2. Route each bug independently (some may be standard, others deep)
  3. Process all standard-routed bugs first, then deep-routed bugs
  4. After all bugs are verified, check for exploit chains — findings that individually failed gate review may combine to form a viable attack
同时验证多个漏洞时：
  1. 先对所有漏洞执行第0步——重述每一条声明通常会立刻排除明显的误报
  2. 为每个漏洞独立分配验证路径（部分用标准验证，部分用深度验证）
  3. 先处理所有分配了标准验证的漏洞，再处理深度验证的漏洞
  4. 所有漏洞验证完成后，检查利用链——单独未通过评审的发现项可能组合形成可行的攻击路径

Final Summary

最终总结

After processing ALL suspected bugs, provide:
  1. Counts: X TRUE POSITIVES, Y FALSE POSITIVES
  2. TRUE POSITIVE list: Each with brief vulnerability description
  3. FALSE POSITIVE list: Each with brief reason for rejection
处理完所有疑似漏洞后，提供以下内容：
  1. 统计数量：X个真实有效漏洞，Y个误报
  2. 真实有效漏洞列表：每条附带简短的漏洞描述
  3. 误报列表：每条附带简短的驳回理由

References

参考资料

  • Standard Verification — Linear single-pass checklist for straightforward bugs
  • Deep Verification — Full task-based orchestration for complex bugs
  • Gate Reviews — Six mandatory gates and verdict format
  • Bug-Class Verification — Class-specific verification requirements for memory corruption, logic bugs, race conditions, integer issues, crypto, injection, info disclosure, DoS, and deserialization
  • False Positive Patterns — 13-item checklist and red flags for common false positive patterns
  • Evidence Templates — Documentation templates for data flow, mathematical proofs, attacker control, and devil's advocate reviews
  • 标准验证 — 适用于简单漏洞的线性单轮检查清单
  • 深度验证 — 适用于复杂漏洞的全任务编排流程
  • 门禁评审 — 六项强制门禁与判定结果格式
  • 漏洞类型验证 — 针对内存破坏、逻辑漏洞、竞态条件、整数问题、加密、注入、信息泄露、DoS、反序列化等类型的特定验证要求
  • 误报模式 — 包含13项内容的检查清单，以及常见误报模式的危险信号
  • 证据模板 — 用于数据流、数学证明、攻击者可控性、反向质疑评审的文档模板