查漏洞自查报告

上周三凌晨两点，查漏查报我盯着屏幕上的洞自日志文件，发现了一个不该存在的查漏查报API调用记录。来源IP是洞自我们自己的测试服务器，但调用时间戳显示它每17秒就向生产数据库发一次请求——持续了整整四个月。查漏查报没人注意到，洞自因为监控面板只报警了三次，查漏查报每次都被值班同事标记为“测试流量误报”。洞自

这就是查漏查报我写这份自查报告的起因。不是洞自公司要求的，是查漏查报我自己觉得该查了。

一、洞自漏洞不是查漏查报“找到”的，是洞自“撞上”的

很多人以为查漏洞是拿着扫描器跑一遍，然后对着报告修修补补。查漏查报我干了六年运维，可以负责任地说：那玩意儿只能查出三成问题，剩下七成都藏在逻辑缝隙里。

比如我们那个API泄漏，扫描器扫不出来。因为从技术角度看，它就是一个合法的内部调用，权限对、格式对、频率也不算离谱。问题出在四个月前的一次配置变更——有人把测试环境的定时任务指向了生产库，改完就忘了。更离谱的是，这个定时任务的代码是三年前写的，当时为了“临时调试”硬编码了生产库地址。

三年前的临时，变成了四个月的常态。没人发现，因为没人会去翻一个“正常运行”的定时任务。

二、自查要查“人”，不是查“机器”

我列了一份清单，把过去半年所有变更记录翻出来。一共327条，其中43条没有关联工单，11条没有回滚方案。最要命的是，有6条变更的操作人已经离职了。

这不是技术问题，是流程烂了。但流程烂了不能怪流程，得怪执行流程的人——包括我自己。上个月我改了一个Nginx配置，想着“就加一行，不用走工单”，结果那行配置和另一个模块的规则冲突，导致部分移动端用户被拒之门外。两小时后才有人反馈，我查了半天才想起来自己改过什么。

所以自查报告的第一条结论：别光盯着代码和服务器，先看看自己最近干了什么“顺手”的事。

三、具体查了什么，查出什么

我把自查范围划成三块：权限、日志、依赖。

权限这块最吓人。 我们有一个内部管理后台，理论上只有5个人有超级管理员权限。实际查下来，有17个账号拥有同等权限，其中3个是离职员工遗留的，2个是测试账号被误加了角色，剩下7个是“为了方便”临时提权后忘了收回。最老的一个临时权限，2019年加的，备注写着“临时用一周”。

日志的问题不是没记，是记了没人看。 我们每天产生约2.3GB的访问日志，保留30天。但过去半年，真正被人工翻阅的日志不到总量的0.1%。也就是说，99.9%的日志写进去就等着被自动删除。那个API泄漏能藏四个月，就是因为日志里全是“正常”记录，没人去比对频率和来源。

依赖更离谱。 项目里引了142个第三方库，其中23个超过两年没更新，8个已经停止维护。有一个JSON解析库，官方去年就发了安全公告，我们还在用旧版本。为什么？因为升级要改代码，改代码要测试，测试要排期——排着排着就忘了。

四、改了什么，还没改什么

已经动手的：清理了14个冗余权限账号，给定时任务加了来源校验，把日志分析接入了自动告警——不是那种“有错误才报警”，而是“行为模式偏离基线就报警”。比如那个17秒一次的调用，基线是每小时一次，偏离超过5倍就触发。

还没改的：第三方库升级排期排到了下个季度。我知道这很慢，但贸然升级可能引入新问题。我的做法是先给所有过时库加了一层代理，记录调用情况，等排期到了再逐个替换。

另外，我给自己定了个规矩：任何变更，哪怕只改一个字符，也要写进共享文档。不是给领导看的，是给三个月后的自己看的。因为我记性没那么好。

查漏洞这件事，说到底不是技术活，是耐心活。你得承认自己会犯错，会忘事，会偷懒。然后想办法用流程和工具把这些“人性弱点”兜住。兜不住的时候，至少留个记录，方便后面的人骂你的时候知道骂什么。

报告写完了。我要去把那个17秒的定时任务彻底删掉，然后睡一觉。