漏报从哪里来
扫描没报不等于没有问题。漏报有五个常见来源：未登录导致看不到登录后才暴露的功能、目录与路径字典覆盖不足、扫描出口被 WAF 拦截导致后续请求全被吞掉、速率过高造成丢包与服务识别不完整、规则库滞后于新披露的问题。补强的思路是用多种手段交叉覆盖，而不是把某一轮结果直接当结论。
基本信息
| 常见来源 | 未认证扫描、字典不足、出口被拦截、速率过高、规则库滞后 |
|---|---|
| 补强手段 | 登录态扫描、业务特征字典、多源多时段复扫、规则库更新 |
| 前置条件 | 认证凭据来自受控保管的专用账号 |
| 结果校验 | 抽取样本人工复核，确认「无异常」是真无异常 |
| 复扫时机 | 新系统上线、更换框架、开放新端口等重大变更后 |
| 留痕要求 | 记录扫描参数、时间窗口与出口地址 |
漏报来源与补强动作
| 来源 | 表现 | 补强动作 |
|---|---|---|
| 未认证扫描 | 登录后的功能完全看不到 | 使用受控凭据做认证扫描 |
| 字典不足 | 深路径与业务路径未命中 | 基于业务特征定制字典 |
| 出口被拦截 | 后续请求返回拦截页 | 核对响应特征，更换出口地址 |
| 速率过高 | 端口与服务识别不完整 | 降低速率并分层重扫 |
| 规则库滞后 | 新披露问题没有对应模板 | 更新模板库后再跑一轮 |
| 入口单一 | 备用域名与直连地址未覆盖 | 补全全部对外入口清单 |
漏报常见来源
漏报常见来源
1. 未登录扫描：看不到登录后才暴露的功能
2. 目录字典不足：深路径与业务自定义路径未被枚举
3. 出口被 WAF 拦截：后续请求全部被误判为「无异常」
4. 速率过高：丢包导致端口与服务识别不完整
5. 规则库滞后：新披露问题在旧模板库中不存在
6. 只扫单一入口：备用域名、IP 直连与测试环境未覆盖补强动作
补强动作
# 登录态扫描（凭据来自受控保管的专用账号）
nuclei -u https://example.com -H 'Cookie: session=<受控凭据>' -severity high
# 目录补充：基于业务特征定制字典，而不是通用大字典
# 分层复扫：不同出口地址、不同时段、不同速率参数各跑一轮
# 结果校验：抽查样本人工复核，确认无异常是真无异常典型使用场景
- 扫描报告的结论复核与可信度说明
- 重大变更后的针对性复扫
- 扫描出口被封禁的排查
- 认证扫描能力的建设与验证
- 规则库更新后的回归扫描
- 向上汇报时说明覆盖范围与已知局限
重大变更（新上线系统、更换框架、开放新端口）后安排针对性复扫，能覆盖例行节奏之外的盲区，成本远低于全量重扫。
扫描出口被 WAF 封禁后，后续所有请求都返回拦截页，很容易被当成「目标很干净」。结果异常整齐、报告全绿时，先怀疑出口。