扫描报告怎么读？Deepsec 漏洞严重性分级、误报率真相与修复优先级完整指南
扫描报告怎么读？Deepsec 漏洞严重性分级、误报率真相与修复优先级完整指南
Deepsec 是一个由 AI 编码智能体驱动的代码库漏洞扫描工具，专为大型仓库的按需深度审查而设计。跑完一轮扫描后，你手里会得到一份漏洞扫描报告——但怎么读报告？CRITICAL 和 HIGH 差在哪？误报率到底有多高？先修哪条、后修哪条？本文用一篇讲透 Deepsec 报告的严重性分级、误报判定与修复优先级排序，帮你把报告真正变成可执行的修复清单。
📋 报告总览怎么读：先看这 5 个数字
deepsec report 生成的 Markdown 报告以一张总览表开场（见 report.ts）：
| 字段 | 含义 |
|---|---|
| Project | 项目 ID |
| Files tracked | 纳入跟踪的文件总数 |
| Files analyzed | 已被 AI 实际分析的文件数 |
| Total findings | 待处理（actionable）漏洞总数 |
紧接着是一张按严重性分档的汇总表。新手最容易踩的坑：Total findings 不含 LOW 档——报告代码中只有 CRITICAL、HIGH、MEDIUM、HIGH_BUG、BUG 五档计入可处理数量（见 ACTIONABLE_SEVERITIES），LOW 只出现在导出目录里，不占用你的处理精力。
💡 阅读顺序建议：先看总览表判断规模 → 再按严重性从高到低逐档处理 → 最后用
deepsec metrics核对统计。
🚨 六档严重性分级：安全漏洞与非安全缺陷分开打
Deepsec 的严重性模型定义在 types.ts 中，共 6 档：CRITICAL、HIGH、MEDIUM、HIGH_BUG、BUG、LOW。AI 智能体在研判每条候选漏洞时，严格按 core.ts 中的分类标准打档：
安全漏洞档（攻击者可利用）
| 档位 | 典型场景 |
|---|---|
| 🔴 CRITICAL | 远程代码执行（RCE）、可完全绕过的认证、敏感数据的 SQL 注入、可致 RCE 的任意文件上传、指向内部服务的 SSRF |
| 🟠 HIGH | XSS、SSRF、权限提升、源码中硬编码密钥、不安全反序列化、敏感操作缺少鉴权 |
| 🟡 MEDIUM | 开放重定向、弱加密算法、缺少限流、信息泄露、不安全的直接对象引用（IDOR）、竞态条件 |
非安全缺陷档（值得顺手修）
| 档位 | 典型场景 |
|---|---|
| 🟣 HIGH_BUG | 可能引发数据丢失、数据损坏、服务宕机等重大非安全缺陷 |
| 🔵 BUG | 逻辑错误、竞态、资源泄漏等显著但不至 HIGH_BUG 的非安全缺陷 |
| ⚪ LOW | 低危观察项，不计入报告待处理总数 |
这个设计的用意很明确：安全团队和产品团队可以各取所需——安全同学盯前三档，工程团队顺手把 HIGH_BUG/BUG 档的数据丢失风险一起修掉。
🔍 单条漏洞怎么读：5 个关键字段详解
报告中每条漏洞（finding）的结构如下（生成逻辑见 report.ts）：
### 漏洞标题
- File: 命中文件路径
- Lines: 命中行号
- Slug: 漏洞类别（如 sql-injection、auth-bypass）
- Confidence: high / medium / low，AI 自报的把握程度
- Revalidation: confirmed / ~~false positive~~ / uncertain
- Reasoning: 复核推理过程
三个新手最容易忽略的字段：
- Confidence（置信度）：AI 对"这是真漏洞"的把握。severity 相同但 confidence 为 low 的条目，可排后处理。
- Revalidation（复核结论）：跑过
deepsec revalidate后，每条漏洞会被二次核验（含检查 git 历史是否已修复），报告里直接标注confirmed、false positive或uncertain——这等于把复核结论内嵌进了报告，不用你自己逐条复现。 - Recent committers：报告附带近期提交人（
enrich后数据更丰富），方便你直接把工单 @ 给对的人。
完整的漏洞类别清单（auth-bypass、xss、rce、ssrf 等几十种 slug）可参考 core.ts 中的分类表。
⚖️ 误报率真相：为什么官方建议先 revalidate 再修漏洞
官方 FAQ 给出的答案很直接（见 faq.md）：经过 revalidate 复核后，HIGH 及以上档位的误报率约为 10%–29%。
为什么首扫误报偏多？因为第一层 scan 是正则模式匹配——故意"撒大网"，很多候选位只是形似漏洞。真正过滤噪声靠的是后两步：
| 阶段 | 命令 | 作用 | 成本 |
|---|---|---|---|
| 候选扫描 | deepsec scan |
正则匹配，快速圈定候选文件 | 免费 |
| AI 研判 | deepsec process |
深度调查，产出 findings | 主要成本 |
| 复核 | deepsec revalidate |
二次核验，检查 git 历史中的修复 | 与 process 相当 |
复核的六种判定（定义见 schemas.ts）：
- ✅ true-positive：确认真漏洞
- ❌ false-positive：确认误报，默认从导出中隐藏
- 🛠 fixed：git 历史显示已修复，默认隐藏
- ❓ uncertain：存疑，报告中如实标注
- 📌 accepted-risk：人工标记"确认是真漏洞但团队选择接受"，默认也隐藏
- 🔗 duplicate：与同文件另一条漏洞重复，指向主条目
官方给出的两条降低误报的最有效建议：
- 动手修复前先对 HIGH+ 档位跑
revalidate——值得花这笔钱； - 检查 setup 阶段的
INFO.md和文件清单——正确的鉴权原语描述和代表性文件能同时提升研判质量和覆盖度。
📊 修复优先级：P0/P1/P2 分诊 + 自动排序
修不过来是正常的——Deepsec 为此提供了两层优先级机制：
第一层：deepsec triage 轻量分诊（triage.ts）。它用更便宜的模型对 MEDIUM 及以上档做 P0/P1/P2/skip 分类，约 1 美分/条，依据两个维度打分：
- 可利用性：trivial（直接利用）/ moderate / difficult
- 影响面：critical / high / medium / low
一条 "trivial + critical" 的漏洞就是 P0，半夜也该爬起来修的那种；"difficult + medium" 则可以排进下个迭代。
第二层：导出时自动按严重性排序。deepsec export 输出的顺序是 CRITICAL → HIGH → HIGH_BUG → MEDIUM → BUG → LOW（排序规则见 export.ts），并且：
- 默认隐藏所有已解决项（fixed / false-positive / accepted-risk / duplicate），你看到的每一条都值得处理；
--format md-dir模式会按严重性建立子目录（CRITICAL/、HIGH/…），再次导出时自动清掉已消失的旧文件，目录永远反映当前真实状态；- 支持
--min-severity HIGH、--only-true-positive、--since、--only-slugs等过滤参数，可以精确切出"本周新发现的真漏洞"。
deepsec metrics 则给出跨项目统计：各档数量、TP/FP 复核计数、各漏洞类别的真实命中率先行表（True Positives by Vulnerability Type），能帮你判断哪类漏洞在你的技术栈里最"能打"。
🛠 上手示例：4 条命令生成可读报告
在仓库根目录初始化后（npx deepsec init 会自动建好 .deepsec/ 工作区），日常流程就是这四步（完整说明见 getting-started.md）：
cd .deepsec
pnpm deepsec scan # ① 快速模式扫描，免费
pnpm deepsec process # ② AI 深度研判新候选
pnpm deepsec revalidate --min-severity HIGH # ③ 复核，压低误报率
pnpm deepsec export --format md-dir --out ./findings # ④ 导出可读报告
如果中途被中断（Ctrl-C、断网、额度用完），直接重跑同一命令即可，deepsec 会跳过已分析的文件从断点继续。想控制预算可以加 --max-cost-usd 100。
✅ 小结：三句话读懂 Deepsec 报告
- 看总览：Total findings 不含 LOW，先按严重性汇总定位大头；
- 看单条：Confidence 定可信度，Revalidation 定真伪，Slug 和 Recommendation 定修法；
- 定优先级：HIGH+ 先
revalidate再动手，用triage的 P0/P1/P2 决定修复顺序，export的输出顺序就是你的工作队列。
掌握这套读法，Deepsec 给你的就不只是一份"漏洞清单"，而是一张可以直接开工的修复路线图。