核心要点（TL;DR）

• 扫描频率按资产分级：核心系统每周、一般业务每月、边缘资产每季度。
• 认证扫描能显著减少漏报，务必配置只读凭据并验证提权成功。
• 误报处理要留痕：复现、标记、加例外规则，定期复核例外清单。
• 扫描不止于出报告，必须绑定修复责任人与复测时间才算闭环。

很多团队装了扫描器、跑了报告，却依然在应急时被打穿：要么一个月才扫一次，新上线的服务根本没进扫描范围；要么只做外部扫描，主机内部的过期组件完全看不见；要么被几百条误报淹没，真正的高危被埋在第 37 页。漏洞扫描的价值不在“扫过”，而在“扫得准、修得动”。下面按频率、认证、误报三条主线给出可直接落地的做法。

一、先定扫描频率：按资产分级，而不是拍脑袋

频率的本质是“暴露面变化速度”。对外服务每天都在变，内部资产相对稳定。建议先做资产分级，再套周期：

落地时先确认资产清单是否完整，否则频率再高也是漏扫。可用一条命令快速核对网段存活主机：

nmap -sn 10.10.0.0/24 -oG - | awk '/Up$/{print }' | sort > alive.txt
diff <(sort assets.txt) alive.txt   # 找出清单外的新增主机

把“清单外主机”纳入扫描范围，比提高扫描频率更能降低风险。同时给扫描任务设置业务低峰窗口，避免高峰期限流误伤。

二、认证扫描：配置对了，漏报才会降下来

非认证扫描只能看到端口和指纹，主机上装了哪个版本的 OpenSSL、有没有缺失补丁，基本靠猜。认证扫描通过登录读取包管理器和配置文件，结果才可信。以 Linux 主机为例，标准流程是：

1. 创建只读扫描账号，禁止交互登录，仅允许密钥认证；
2. 确认该账号可通过 sudo 读取必要信息；
3. 在扫描器中录入凭据，执行一次凭据测试；
4. 扫描后在报告中核对“认证状态：成功”。

# 创建扫描专用账号
useradd -r -s /sbin/nologin scanuser
mkdir -p /home/scanuser/.ssh && chmod 700 /home/scanuser/.ssh
# 写入扫描器公钥后验证
ssh -i scan_key scanuser@10.10.0.5 "sudo -n rpm -qa | head -3"

常见坑有三个：凭据过期后扫描器静默退化为非认证模式，报告看起来正常但漏报激增；sudo 需要密码导致提权失败；Windows 侧未开启远程注册表或 WMI 权限。建议每次扫描后抽查 3 台主机，确认认证成功且软件清单非空。

三、误报处理：用证据定性，用例外留痕

误报不可怕，可怕的是“一键忽略”。正确流程是复现、定性、留痕、复核：

• 复现：拿到告警后先确认实际版本与配置，例如 nginx -v、openssl version、dpkg -l | grep 包名；
• 定性：版本命中但补丁已回移（backport）的，属于误报；配置项确实存在的，属于真实风险；
• 留痕：在平台标记误报，写明证据、责任人和例外到期时间；
• 复核：例外清单每月过一遍，到期自动恢复告警。

不要直接关闭检测规则来“消灭”误报，那会同时制造漏报。优先补充版本识别和指纹规则，让扫描器自己判断更准。

对高频误报类型，可维护一份内部对照表，把“包版本—实际补丁状态—结论”固定下来，新人也能快速判断。

四、扫描执行检查清单

每次正式扫描前后对照执行，能避免大部分翻车：

• 扫描前：确认资产清单、维护窗口、凭据有效期、业务方知会；
• 扫描中：监控目标 5xx 与负载，异常立即暂停并降并发；
• 扫描后：核对认证状态、导出高危清单、去重合并同类项；
• 修复后：复测并留存截图或命令输出，更新例外清单。

在防护侧，AegisX 可将扫描发现的暴露面与主机基线纳入统一视图，配合认证采集减少“扫不到”的盲区，让修复优先级更容易判断。

五、从报告到闭环：把结果变成工单

扫描的终点是修复，不是 PDF。建议按 CVSS 叠加资产重要性排序，高危 7 天内、中危 30 天内修复；每条工单绑定责任人与复测时间，无法立即修复的登记临时缓解措施和风险接受期限。每周统计修复率与超期项，在例会上过一遍未闭环清单。只有复测通过并留痕，这条漏洞才算真正关闭。

行动建议：今天先做三件事——导出资产清单与扫描结果比对找出漏扫主机；抽查最近一次扫描的认证状态；清理一遍过期未复核的误报例外。三件事做完，你的漏洞扫描才算真正开始产生安全收益。

常见问题（FAQ）

漏洞扫描多久做一次比较合适？

结论：按资产重要性和变更频率分级设定，而不是统一一个周期。核心对外系统建议每周一次认证扫描，一般业务系统每月一次，边缘或测试资产每季度一次；同时在大版本上线、端口或中间件变更后追加一次临时扫描。频率过高会带来噪声和业务影响，过低则漏掉新暴露面，关键是配合变更触发扫描。

认证扫描和普通扫描差别有多大？

结论：认证扫描能登录主机内部读取软件包与配置，漏报明显更少。非认证扫描只能从外部探测开放端口和指纹，无法发现本地补丁缺失、弱配置和内部服务。认证扫描需要提供只读账号或 SSH 密钥，并验证提权是否成功；若凭据失效，扫描器会静默退化为非认证模式，务必在报告里确认认证状态为成功。

扫描器报了很多误报，怎么处理才不浪费时间？

结论：先复现再定性，用证据决定修复还是加例外。对每条高危告警，手工用版本号、配置文件和实际请求复现一次；确认是误报后在平台标记并写明原因与到期时间，同时补充指纹或版本识别规则减少复发。例外清单要每月复核，避免真实漏洞被长期掩盖。不要直接关闭规则，那会带来漏报。

扫描会不会影响业务性能甚至打挂服务？

结论：会，尤其是全端口扫描和并发过高时。建议在业务低峰执行，限制并发线程与请求速率，对登录接口、搜索接口等易触发锁定的路径加白名单或降低强度；数据库、老旧中间件先小范围试扫。扫描前备份并确认回滚方案，出现 5xx 激增立即暂停任务，调整策略后再继续。

扫描报告出来之后应该怎么推进修复？

结论：把报告转成带责任人和时限的工单，并安排复测。按 CVSS 与资产重要性排序，高危 7 天内、中危 30 天内修复；修复后必须复测并留存证据，无法立即修复的走临时缓解措施并登记风险接受。每周跟踪修复率，把未闭环项纳入例会，否则扫描只是产生文档。