False Positive Check

---
name: false-positive-check
title: 漏洞误报核验
description: 当需要核验某个疑似安全漏洞是真阳还是误报时使用；做系统化数据流追踪+可利用性证明+影响评估+六道闸门评审，产出带证据的「真阳/误报」裁决；不适用于挖掘漏洞、风格/性能代码评审或非安全任务；触发词：误报核验、这个漏洞是真的吗、是否可利用、是否误报、验证安全发现、false positive、true positive、verify finding、exploitable、triage
domain: 安全/audit
triggers: [误报核验, 这个漏洞是真的吗, 是否可利用, 是否误报, 验证安全发现, false positive, true positive, verify finding, exploitable, triage]
tags: [security, audit, false-positive, vulnerability, triage, verification, exploitability, data-flow]
level: 进阶
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: [Read, Grep, Glob, LSP, Bash, Task, Write, Edit]
requires: []
related: [vulnerability-variant-analysis, codeql-scanner, semgrep-rule-creator, security-audit-toolkit]
combines_with: [codeql-scanner, vulnerability-variant-analysis, security-audit-toolkit]
license: CC-BY-SA-4.0
source: trailofbits/skills
source_license: CC-BY-SA-4.0
---
## 何时使用

当你拿到一条**具体的疑似安全漏洞**，需要判定它是「真阳（TRUE POSITIVE）」还是「误报（FALSE POSITIVE）」时使用。典型请求：

- 「这个 bug 是真的吗 / 是不是真阳？」
- 「这是误报吗 / 帮我核验这条发现」
- 「检查这个漏洞能不能被利用」
- 任何针对**单条已知漏洞**的核验、验证、复核请求。

**不该用的边界（命中则改用别的技能）：**

- 主动挖洞、做安全分析、审计整份代码（这是「找 bug」，不是「核验某个 bug」）。
- 通用代码评审：风格、性能、可维护性。
- 功能开发、重构等非安全任务。
- 用户明确只要快速扫描、不要核验。

**先拒绝这些自我合理化**（出现任一立即停手，回到流程）：

- 「剩下的 bug 快速过一遍就行」→ 每个 bug 都要走完整核验。
- 「这模式看着危险，所以是漏洞」→ 模式识别不等于分析，必须先追完数据流。
- 「为了效率跳过完整核验」→ 不允许部分分析。
- 「这代码看着不安全，直接报」→ 上游可能已有校验，必须从 source 追到 sink。
- 「别处类似代码有洞，所以这里也有」→ 每处上下文的校验/调用方/防护都不同，独立核验。
- 「这显然是 critical」→ LLM 天然倾向于看到 bug 并高估严重性，必须做唱反调评审、用证据证明。

## 步骤

**Step 0 — 复述主张与上下文。** 分析前先用自己的话重述这个漏洞主张；说不清就用提问澄清。约一半误报在这一步就崩了——主张被精确复述后根本讲不通。记录：

- 确切漏洞主张（如「`parse_header()` 在 `content_length>4096` 时堆缓冲区溢出」）。
- 所称根因、所称触发方式、所称影响。
- **威胁模型**：代码以什么权限运行？是否沙箱化？攻击者在触发前已能做什么？（如「未认证远程攻击者」vs「特权本地用户」；「跑在渲染器沙箱内」vs「以 root 运行无沙箱」）
- **漏洞类别**：分类后按类别套用专属核验要求。
- 执行上下文、调用方约束、架构上下文、历史上下文（近期改动 / 已知问题 / 既往评审）。

**选路 — 标准核验 vs 深度核验。** 默认从标准开始；标准流程内置两个升级检查点，复杂度超出线性清单时自动转深度。

- **标准核验**（需同时满足）：主张清晰具体；单组件、无跨组件；漏洞类别成熟（溢出 / SQLi / XSS / 整数溢出等）；触发不涉并发/异步；数据流从 source 到 sink 直白。
- **深度核验**（满足任一）：主张含糊有多种解读；跨组件路径（数据流经 3+ 模块/服务）；触发涉竞态 / TOCTOU / 并发；无明确规约的逻辑漏洞；标准核验不确定或被升级；用户明确要求完整核验。深度核验为每个 bug 建任务依赖图，用 `data-flow-analyzer`、`exploitability-verifier`、`poc-builder` 等 agent 并行跑各 Phase（Phase 3 影响、Phase 5 唱反调、Gate Review 不外包）。

**标准核验六步清单：**

1. **数据流**：从 source 追到所称 sink。标出跨越的信任边界；找出全部校验/净化；核对 API 契约（很多 API 自带边界保护）；核对环境防护（编译器/运行时/OS/框架）是否**彻底阻止**利用。关键坑：孤立看漏洞代码——上游条件逻辑可能让它在数学上不可达。**升级检查**：若有 3+ 信任边界、回调/异步控制流、或校验链含糊 → 转深度。
2. **可利用性**：证明攻击者能触发。证明攻击者控制到达危险操作的数据（可信组件写入的内部存储**不算**攻击者可控）；整数/边界类做显式代数证明（`IF 校验通过 THEN 边界保证成立`）；竞态类证明并发访问确实可能（单线程初始化、同步上下文无竞态）。
3. **影响**：区分真实安全影响（RCE / 提权 / 信息泄露）与运维健壮性问题（崩溃恢复、清理失败）；区分主防护与纵深防御——纵深防御失效在主防护完好时不算漏洞。
4. **PoC 草图**：写伪代码 PoC 展示攻击路径（标准核验下可执行/单测 PoC 可选）。
5. **唱反调抽查**：回答 7 问，任一产生无法消解的真实不确定 → 转深度。
6. **闸门评审**：套用六道闸门 + 13 条误报清单，得出裁决。

## 指令

**唱反调 7 问**（Step 5）——前 5 问反对漏洞、后 2 问保护防漏判（防止 false negative）：

1. 我是因为模式「看着危险」才认定漏洞，而非它真的危险吗？（模式匹配偏差）
2. 我是否错误假设攻击者能控制可信数据？（信任边界混淆）
3. 我是否严格证明了漏洞的数学条件能发生？（证明严谨性）
4. 我是否把纵深防御失效当成了主防护漏洞？（纵深防御混淆）
5. 我是否在幻觉这个漏洞？是真实可利用，还是在对吓人的代码做模式匹配？（LLM 自检）
6. 我是否因为利用「看起来复杂/不太可能」就否掉了真实漏洞？
7. 我是否凭空编造了源码里未经核实的缓解/校验逻辑？**得出结论后重读代码。**

**六道闸门**（全过才能判真阳，任一失败即误报）：

| 闸门 | 判据 |
|---|---|
| 1. 流程 | 每个 Phase 都有书面证据 |
| 2. 可达性 | 攻击者可达并控制漏洞处数据，PoC 佐证 |
| 3. 真实影响 | 利用导致 RCE / 提权 / 信息泄露（非仅运维问题） |
| 4. PoC 验证 | PoC（伪代码/可执行/单测）展示了控制+触发+影响 |
| 5. 数学边界 | 代数证明漏洞条件可能成立（而非被校验数学阻止） |
| 6. 环境 | 无环境防护**彻底**阻止利用（ASLR/栈金丝雀只抬高门槛，不消除漏洞） |

**裁决格式：**

- 真阳：`BUG #N TRUE POSITIVE — <漏洞简述>`
- 误报：`BUG #N FALSE POSITIVE — <否决理由>`

任一 Phase 核验失败：先记录失败证据，**走完其余全部 Phase**，再下误报裁决。

**批量三连（一次核验多个 bug）：** ①先对所有 bug 跑 Step 0（复述主张常当场击穿明显误报）；②各自独立选路（有的标准、有的深度）；③先处理标准路、再处理深度路；④全部核验完后检查**利用链**——单独过不了闸门的发现可能组合成可行攻击。

**最终汇总：** ①计数（X 个真阳、Y 个误报）；②真阳清单（各带漏洞简述）；③误报清单（各带否决理由）。

## 示例

误报裁决示例（数学边界闸门拦截）：

```
BUG #3 FALSE POSITIVE — packet_handler.c:142 整数下溢
  闸门 5（数学边界）失败：第 98 行校验保证 packet_size >= 16，
  故 (packet_size - header_size) >= 8，下溢在数学上不可能。
```

PoC 草图模板（Step 4）：

```
数据流: [Source] → [校验?] → [变换?] → [危险操作] → [影响]
攻击者控制: [控制什么输入、如何控制]
触发: [展示利用路径的伪代码]
```

## 注意事项

- **追完整条校验链，别看孤立片段。** 反向回溯危险操作前的**所有**校验；`buffer[length-4]` 看着不安全，但若代码仅在 `length>12` 时可达，则漏洞不可能。
- **辨别防御性编程与真漏洞。** `ASSERT(size == expected_size)` 后接受控操作是防御，不是漏洞——核实检查确实阻止了所称漏洞。
- **区分数据来源信任级。** API 返回值、编译期常量、网络数据风险画像不同；可信组件在安装/初始化期写入的内部存储**非**攻击者可控。
- **TOCTOU 需证明被检查值可在 check 与 use 之间改变**；同函数内检查后立即使用、外部无法修改，就没有 TOCTOU。
- **竞态需证明并发确实可能**；先确认线程模型与同步机制。
- **吃透 API 契约再断言溢出**；不少 API 自带边界保护，无论入参如何都无法越界写。
- **环境缓解 ≠ 消除漏洞**：区分「彻底阻止利用」（如 Rust 安全类型系统）与「只是更难」（如 ASLR、栈金丝雀）。
- 清单要**系统性**逐条套用到每个 bug，而非走过场——有清单不代表不会误报。

## 互见

- `code-reviewer`：通用代码评审（风格/性能/可维护性），与本条的安全核验定位互补。
- `dependency-auditor`：依赖与供应链安全审计，可作为漏洞来源的上游环节。
- `fact-checking`：以证据驱动的核验纪律，与本条「拿证据说话、拒绝模式匹配」一脉相承。
- `first-principles-thinking`：从第一性原理推理、对抗 LLM 看洞偏差，支撑唱反调评审。

---

本条采编自 trailofbits/skills（CC-BY-SA-4.0）。