核心要点（TL;DR）

• 漏洞扫描的价值在闭环，不在报告条数：资产不全则结论必错。
• 先做资产发现与端口识别，再谈扫描策略，能减少大半无效告警。
• 误报验证优先看版本回显与手工复现，别直接照报告派单。
• 修复后必须复测并留存证据，否则漏洞会随迭代回流。

很多团队每月跑一次扫描，报告几百条，修完却仍被同一个入口打穿。问题通常不在扫描器，而在流程：资产没摸全、策略一把梭、误报直接派单、修完不复测。本文按漏洞扫描方法的真实落地顺序，从资产发现讲到误报验证与复测闭环，给出可直接照做的命令和检查项，目标是让每一条告警都能对应到真实风险。

一、资产发现：先搞清楚要扫什么

扫描结论的上限由资产台账决定。先做被动收集与主动探测两条线：

• 域名与子域：从证书透明日志、DNS 解析记录、备案信息汇总主域名，再用子域枚举工具补全。
• IP 与端口：对确认归属的网段做存活与端口探测，避免扫到云厂商共享地址。
• 旁路资产：测试环境、旧版后台、对象存储桶、API 网关常被遗漏。

# 存活与常见端口快速探测
nmap -sn 10.0.0.0/24 -oG alive.txt
nmap -sS -p 22,80,443,3306,6379,8080,8443 -iL alive.txt -oX ports.xml

检查清单：资产归属人是否明确、是否有未登记的对外端口、测试环境是否暴露公网。资产不全时，后续所有漏洞扫描结果都只是局部快照。

二、扫描器配置：策略比工具更重要

同一款扫描器，策略不同结论差异巨大。建议分三档：

认证扫描能显著降低漏报，但账号须最小权限并限制扫描源 IP。并发与请求速率按业务承受能力调低，避免把扫描变成压测。若使用 AegisX 一类平台，可把资产分组与扫描策略绑定，按组下发计划任务，减少手工配置偏差。

三、结果研判：把误报挡在派单之前

误报验证是漏洞扫描方法中最容易被跳过的一步。逐条看三类证据：

1. 请求与响应：报告里的请求包、响应头、版本回显是否与目标一致。
2. 版本核对：登录主机执行 rpm -q 包名 或 dpkg -l | grep 包名，对比实际版本与补丁号。
3. 手工复现：用最小 payload 验证，例如路径探测 curl -I https://target/admin，确认状态码与跳转行为。

无法复现、又缺少响应证据的条目，标记为「待确认」，不要直接进修复队列，否则会消耗研发信任。

对注入、越权类漏洞，务必在测试环境复现；对仅版本匹配的条目，确认是否已打补丁或存在缓解措施。研判后按「互联网可达 + 无需认证 + 有公开利用」优先排序。

四、修复与复测：闭环才算完成

修复阶段把漏洞转成可验收的任务：明确责任人、修复方式（升级、配置、代码修复、下线）、验收标准。完成后用同一策略、同一扫描器版本复测，导出前后报告对比。

# 复测前确认目标与策略未变
nmap -sV -p 443 target.example.com -oX retest.xml
# 对比修复前后端口与服务版本差异
diff 
常见问题（FAQ）
漏洞扫描多久跑一次比较合适？
结论：按资产重要性与变更频率分层设定。互联网暴露面建议每周一次全量扫描、重大变更后加扫；内网核心资产每月一次并配合认证扫描；新上线系统在发布前必扫。频率过高会淹没告警，过低则漏掉新暴露端口，关键是配合资产台账做增量扫描。
扫描器报了一堆漏洞，先修哪个？
结论：按可利用性与暴露面排序，而不是按数量。优先处理互联网可达、无需认证即可利用、且有公开利用代码的高危项；其次是可横向移动的内网高危。CVSS 分数只作参考，结合资产承载的业务数据敏感度与是否存在缓解措施（如WAF拦截）综合定级，再排修复队列。
怎样快速判断一个扫描结果是不是误报？
结论：先看扫描器的请求与响应证据，再手工复现。检查报告中的请求包、响应头与版本回显，用 curl 或浏览器访问对应路径确认；对版本类漏洞，核对实际安装版本与补丁号；对注入类，用最小 payload 手工验证。无法复现且无响应证据的，标记为待确认而非直接派单。
没有认证账号能做漏洞扫描吗？
结论：可以做，但只能覆盖外部视角，漏报率高。无认证扫描只能看到未授权可达的入口，无法发现需登录后的漏洞与缺失补丁细节。建议对核心业务配置只读认证扫描，用最小权限账号，并限制扫描源IP，既能提升准确率又降低账号泄露风险。
修复完成后如何证明漏洞真的没了？
结论：用同一扫描策略复测并留存前后对比证据。复测时保持扫描器版本、策略与目标一致，导出修复前后报告对比；对关键漏洞补充手工验证截图或命令输出；将证据归档到工单。若涉及配置类问题，同时检查基线项，避免只改表面入口。