网站漏洞扫描工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6d174f1e08e9.html
📄
网站漏洞扫描工具，一次全站扫描被中断后怎样判断已覆盖范围
结论先给：扫描被中断后，不能凭“扫描到一半”这个印象判断覆盖范围，最可靠的做法是回到工具自身留下的任务记录、时间戳和已产出结果，把“已发起请求的目标”和“已形成有效判定”的目标分开统计。如果工具只记录了任务状态而没有逐目标进度，那么覆盖范围只能按可核对的证据保守估算，不能直接沿用为一次完整全站结论。反例是：若中断发生在扫描引擎完成目标枚举之前，那么即使结果里出现了大量条目，也可能只覆盖了枚举阶段已发现的部分资产，而不是全站。
先分清“任务中断”和“覆盖中断”是两件事
任务状态显示失败、超时或被手动停止，只能说明这次执行没有正常收尾，不能直接推出哪些目标被扫过。真正需要核对的是覆盖链路：目标枚举是否完成、每个目标是否进入检测阶段、检测结果是否已落盘。假设一个场景：扫描任务在运行到第 40 分钟时被终止，日志里已有 300 条发现，但目标清单原本可能包含 800 个入口。此时 300 条只能证明这些条目所在的目标被处理过，不能证明剩余 500 个入口被扫过或未被扫过。
判断时优先看三类证据：任务日志中的阶段标记、结果文件里的目标标识、以及扫描开始与中断的时间戳。如果这三类信息能互相对齐，覆盖范围才有讨论基础；如果只有一条“任务已停止”的状态，结论就只能停留在“覆盖范围未知”。
用目标清单做差集，而不是用发现数量猜进度
发现数量容易被误读。漏洞多不等于扫得全，漏洞少也不等于没扫到。更稳的做法是拿扫描前的目标清单与结果中的目标标识做差集：
- 结果中出现且带有完整检测标记的目标，可计入已覆盖。
- 结果中出现但只有请求记录、没有判定结果的目标，只能算部分覆盖。
- 清单中存在但结果中完全未出现的目标，属于未覆盖或覆盖不明，不能算已扫。
这个差集动作会直接影响下一步：如果未覆盖目标集中在某个子域、某个端口或某类路径，重新扫描时可以只补这部分，而不是整站重跑；如果差集无法计算，说明目标清单本身不完整，此时应先修复清单来源，再谈覆盖范围。
哪些证据能让结论成立，哪些会让结论失效
能让覆盖结论成立的证据通常包括：带时间戳的任务日志、逐目标的检测状态、以及中断前最后一次成功写入的结果记录。三者能对应上同一批目标时，可以按“已处理目标集合”给出有条件的覆盖判断。
会让结论失效的反例至少有两种。第一种是扫描工具在中断时丢失了缓冲区里的结果，日志显示处理过但结果文件没有对应记录，此时不能把日志里的目标算作已覆盖。第二种是目标枚举本身依赖外部输入，比如站点地图、接口清单或人工导入的地址列表，如果这些输入在中断前没有完整加载，那么扫描范围从一开始就被截断，结果再多也不代表全站。遇到这两种情况，正确动作是标记覆盖范围不可确认，并重新执行一次带断点记录或分批执行的扫描，而不是在原有结果上继续推断。
中断后重新扫描时，怎样把覆盖范围变成可核对的记录
如果决定补扫，建议把下一次执行拆成可核对的批次，而不是直接重跑整站。具体动作是：先导出中断前的目标清单和已有结果，按目标标识去重，得到待补目标列表；再按子域、目录或资产类型分批执行，每批结束后立即保存结果和目标状态。这样做的结果是，下一轮判断覆盖范围时不再依赖单次任务是否完整，而是依赖每批的完成记录。对于无法拆分的目标，至少要在任务配置中开启逐目标日志或结果落盘，确保中断后仍能还原处理到哪一步。
需要提醒的是，不同工具对“已覆盖”的定义并不一致：有的以发起请求为准，有的以完成检测规则为准，有的只记录发现而不记录未发现的目标。具体到某一款工具，其日志字段和结果结构需要以实际版本和当前配置为准进行核对，不能套用其他工具的判断方式。覆盖范围判断的最终依据，始终是你能拿出的、可逐条对应的目标处理记录，而不是任务是否跑完这一状态本身。
