系统漏洞扫描整改情况报告

3月12日凌晨两点，系统运维群里弹出一条告警：一台对外提供API服务的漏洞服务器CPU飙到97%，持续了将近二十分钟。扫描值班同事第一反应是整改流量突增，查了监控才发现请求量平稳，情况倒是报告某个进程在疯狂创建临时文件。天亮之后我们确认，系统这是漏洞一个刚上线三周的业务系统里，某个文件上传接口没做类型校验，扫描被人塞了一个WebShell。整改漏洞本身不复杂，情况但它暴露出来的报告问题让我有点坐不住——这套系统上线前做过一次扫描，报告显示"无高危漏洞"。系统

那份报告我现在还留着。漏洞扫描工具用的扫描是某知名商业产品，策略选的是"标准扫描"，结果里确实没有高危项，中危只有两条，一条是SSL配置问题，另一条是Cookie缺少HttpOnly标记。当时大家看了一眼就过了。问题出在哪儿？扫描器没覆盖到那个上传接口，因为它藏在某个需要登录后才能访问的路径下，而扫描任务配置时没有提供有效的会话凭证。工具没报错，我们就以为没事。

这次整改是从重新梳理扫描范围开始的。我们把所有对外系统按业务线拉了一张清单，逐个确认扫描入口、认证方式和排除规则。之前有些系统因为"怕影响生产"被加进了白名单，这次全部取消，改成在预发布环境做全量扫描，生产环境只做只读检测。光这一步就多发现了11个之前被漏掉的接口。

扫描策略也换了。以前图省事，默认策略跑一遍就交差。现在针对不同系统类型拆成三套：面向公众的Web应用跑OWASP Top 10专项，内部管理系统加跑弱口令和未授权访问检测，API服务单独跑接口参数模糊测试。工具还是那个工具，但配置细了之后，误报率反而降了——之前有些告警是因为扫描器把正常业务逻辑当成了漏洞，现在通过自定义规则把那些路径排除掉，运维同事不用再一条条手动筛。

修复环节是这次整改里最花时间的。扫描出问题不难，难的是推动开发团队改。我们定了个规矩：高危漏洞24小时内出修复方案，72小时内上线；中危一周内处理。但实际执行时发现，有些漏洞卡在"改不动"——比如一个老系统的SQL注入点，修复需要改动核心查询逻辑，开发说排期要等到下个迭代。这种情况我们不再发邮件催，而是直接拉上开发负责人和产品经理开15分钟站会，当场定修复窗口和责任人。说白了，漏洞不等人，流程得为修复让路。

复测环节也做了调整。以前是修复完再扫一遍，现在改成修复后先做针对性验证，确认那个点确实堵上了，再跑全量扫描。上周有个XSS漏洞，开发改了输出编码，针对性验证通过了，但全量扫描又报出来一个类似问题——同一个页面另一个参数没改。这种"改一半"的情况不少见，所以复测不能只看单点，得看整个功能模块。

到目前为止，这轮整改一共处理了37个漏洞，其中高危9个，中危21个，低危7个。数字不算大，但过程里暴露出来的问题比漏洞本身更值得记下来：扫描不是买个工具跑一遍就完事，它得有人盯着配置、有人推着修复、有人验证闭环。工具能发现已知问题，但发现不了"我们以为没问题"的地方。那个WebShell如果没被及时发现，后果可能就不是加班两天能解决的了。

接下来打算把扫描任务和CI/CD流水线绑在一起，代码合并到主分支之前自动触发增量扫描，别等到上线之后再补。另外，每季度的扫描报告不再只列漏洞数量，得把"未覆盖资产"和"修复超时项"单独标出来。漏洞管理这件事，漏报比误报可怕得多。