去年有个客户被拖库了。安全案原因不是漏洞0day，是扫描他们一台边缘业务服务器上跑着个三年没更新的Struts2，攻击者扫到之后直接RCE，及隐横向摸到内网核心库。患排事后复盘，查方这台机器压根不在资产清单里——运维离职时没交接，安全案CMDB里也没录。漏洞漏扫工具不是扫描没买，扫的及隐是"已知资产"，这台是患排"未知资产"。所以漏洞扫描的查方第一道坎，从来不是安全案工具够不够强，是漏洞你根本不知道自己要扫什么。

资产梳理这件事，扫描听着像废话，但真正做扎实的团队不多。我的做法是三层交叉验证：CMDB拉一份、流量镜像里扒一份、DHCP和DNS日志再对一份。三份对不上的地方，就是盲区。有个细节很多人忽略——云上临时实例。开发同学开个ECS跑测试，用完忘了关，安全组开着0.0.0.0/0，这种机器生命周期可能就几天，但足够被打穿了。我们后来写了个脚本，每天对比云API返回的实例列表和CMDB，差集自动告警。

资产清楚了，扫描策略才有意义。见过太多团队一上来就全端口全插件跑Nessus，结果扫描器自己把业务打挂了。生产环境得区分对待：Web层用被动式扫描加轻量POC验证，主机层避开业务高峰，数据库层干脆别用主动扫，靠配置核查加流量分析。扫描频率也不是越勤越好。一个面向公网的API网关，每周扫一次足够；内部办公网那些Windows机器，每月一次都嫌多，重点应该放在补丁管理流程上。

漏洞扫出来之后怎么排优先级，这才是见功力的地方。CVSS评分高不等于你要先修。一个需要本地认证才能触发的CVSS 8.8，和一个无需认证的CVSS 6.5，后者才该连夜修。我习惯加两个维度：暴露面（公网/内网/本地）和利用成熟度（PoC是否公开、是否有在野利用）。三个维度一交叉，修复顺序基本就出来了。有个反直觉的观察——很多团队修漏洞慢，不是开发不配合，是安全团队把两百个中危漏洞一股脑丢过去，开发直接躺平。挑出真正致命的五个，附上修复命令和验证方法，推进速度反而快得多。

隐患排查跟漏洞扫描是两码事。漏洞是已知CVE，隐患是配置错误、架构缺陷、流程漏洞。举几个真实例子：某业务用了Redis，没设密码，绑在0.0.0.0，这是配置隐患；某系统把Session ID放在URL里传，这是架构隐患；某团队生产环境变更不走审批，直接SSH上去改配置文件，这是流程隐患。这些东西漏扫工具扫不出来，得靠人去看、去问、去翻变更记录。我一般会做一轮"攻击者视角"的走查——假设我已经拿到了一个低权限账号，能摸到什么、能跳到哪里、哪里没有日志。这比对着Checklist打勾有用得多。

最后说个容易被忽视的点：扫描器本身的维护。插件库要更新，但别追最新——新插件误报率往往偏高，生产环境跑之前先在测试环境验证一轮。扫描器的凭据管理也要上心，见过把域管账号明文写在扫描器配置文件里的，这等于自己造了个核弹。扫描结果存哪、谁能看、保留多久，这些都得有规矩。漏扫报告里往往带着内网拓扑和未修复漏洞清单，泄露一份出去，比丢个数据库还麻烦。

(责任编辑：娱乐)