去年冬天，漏洞一个做电商的扫描朋友给我打电话，声音发紧。安全他说后台突然多了几十个异常订单，加固收货地址全是漏洞乱码。我让他别急着删数据，扫描先跑一遍漏洞扫描。安全结果出来，加固一个三年前的漏洞Struts2漏洞还挂在服务器上，补丁从来没打过。扫描攻击者用现成的安全EXP工具包，五分钟就拿到了shell权限。加固这件事让我再次确认一个事实：绝大多数被攻破的漏洞系统，不是扫描因为遇到了多高明的黑客，而是安全自己门上的锁早就锈死了，却没人去检查。

漏洞扫描这件事，很多人理解成"买个扫描器，点一下开始，等报告"。真这么干，报告出来几百页，高危中危低危列一堆，然后呢？然后就没有然后了。扫描本身不产生安全，它只是把问题摊在桌面上。真正让系统变结实的，是扫描之后的加固动作。没有加固的扫描，跟体检完把报告塞抽屉里没区别。

我见过一个运维团队的做法值得参考。他们每周三凌晨两点跑一次全量扫描，用Nessus加OpenVAS交叉验证。为什么用两个？因为单一扫描器的误报率能到30%以上，两个都报的漏洞才值得优先处理。扫描结果自动导入Jira，每个漏洞必须有人认领，修复期限按CVSS评分卡死：9分以上24小时，7到9分72小时，5到7分一周。超期未修，系统自动把该服务器从负载均衡里摘掉。这招狠，但有效。半年后他们的平均修复时间从17天压到了2.3天。

加固不是简单打补丁。补丁解决的是已知漏洞，配置问题才是隐藏的深水区。举个例子，扫描器报"SSH支持弱加密算法"，你改了sshd_config，重启服务，扫描通过。但你可能没注意，同一台机器上跑着一个内部API，它的TLS配置允许SSLv3回退。扫描器没报，因为那个端口只对内网开放。可内网就不出事吗？横向移动的攻击者最喜欢这种"内网信任"的盲区。所以加固要分两层：一层是扫描器能看见的，另一层是扫描器看不见的，得靠人工审计配置基线。

还有个坑：加固之后必须复扫。我见过有人改完防火墙规则，忘了保存配置，重启后规则全丢，扫描报告却还是"已修复"状态。复扫不是为了交差，是为了确认修复动作真的生效了。另外，复扫还能发现"修复引入的新问题"。比如你为了堵一个端口，把某个服务依赖的通信链路也切断了，业务挂了，扫描器不会告诉你这个。

说点实在的经验。小团队没那么多预算买商业扫描器，可以用Nmap加NSE脚本做基础发现，再配合OpenVAS做深度检测。关键是建立"扫描-修复-复扫-归档"的闭环。每次扫描的原始数据留着，三个月后回头看，能发现哪些漏洞反复出现——那通常意味着某个开发习惯或部署流程有系统性问题，不是单个补丁能解决的。

最后说个反直觉的判断：漏洞扫描报告里的"低危"不一定真低危。一个信息泄露漏洞，单独看确实危害有限，但如果它泄露的是内网拓扑和版本号，攻击者拿这些信息去精准匹配EXP，低危立刻变高危。所以加固的优先级不能只看扫描器的评分，得结合资产重要性和暴露面来定。核心数据库的一个低危配置错误，可能比边缘服务器的一个高危漏洞更值得先修。

安全这件事，没有一劳永逸。扫描和加固是持续动作，不是项目节点。你今天修完所有漏洞，明天新代码上线可能又引入三个。保持节奏，比追求完美更重要。