漏洞处理流程

去年冬天，漏洞流程一个做电商的处理朋友半夜给我打电话，声音都是漏洞流程抖的。他们系统里一个优惠券接口被人扒了出来，处理有人写了个脚本，漏洞流程十分钟刷了三千多张无门槛券。处理等他发现的漏洞流程时候，损失已经六位数了。处理他说了句话我记到现在：“我知道有漏洞，漏洞流程但我不知道发现之后该先干嘛。处理”

这就是漏洞流程问题所在。大部分团队不是处理没有漏洞，而是漏洞流程漏洞来了之后手忙脚乱。有人先跑去群里喊，处理有人直接重启服务器，漏洞流程还有人第一反应是删日志——删日志这事我真见过，问就是“怕被领导看到”。结果呢？攻击路径断了，复盘都做不了。

我后来帮他们理了一套流程，不复杂，但每一步都有明确的动作和责任人。核心就一条：先止血，再查伤，最后堵口子。

确认漏洞是真的，不是自己吓自己

很多人一看到异常告警就慌了，直接拉群叫所有人。没必要。先花五分钟确认三件事：漏洞能不能复现、影响范围有多大、有没有正在被利用。我见过一个团队把测试环境的配置错误当成生产漏洞，全组加班到凌晨三点，最后发现虚惊一场。确认环节省不得，但也不能拖太久。超过十五分钟还判断不了，就按真实漏洞处理。

止血动作要快，但别乱

确认是真漏洞之后，第一件事不是修，是断。把受影响的接口下线、把被利用的账号封掉、把异常流量拦掉。哪怕暂时影响正常用户，也比继续被人薅强。那个电商朋友当时犯的错就是先跑去改代码，改到一半发现攻击者还在刷，因为旧接口没关。止血和修复是两件事，别混着做。

止血的时候有个细节：保留现场。别急着重启服务，别删日志，别清理临时文件。攻击者的IP、请求特征、利用的Payload，这些都是后面复盘的命根子。我习惯让团队先做快照，再动手。快照花不了几分钟，但能省掉后面几天的扯皮。

定位根因，别只盯着表面

止血完了，开始查。查的时候容易犯一个错：只修那个被利用的点。比如SQL注入，加个参数化查询就完事了？不一定。那个注入点是怎么进来的？代码审计漏了？还是第三方组件带的？还是开发图省事直接拼字符串？根因不找到，下个月换个接口又来一次。

我一般会问三个问题：这个漏洞是什么时候引入的？为什么测试没发现？还有没有类似的代码？第三个问题最关键。一个注入点背后，往往藏着十几个同样写法的接口。只修一个，等于没修。

修复和验证，别自己骗自己

修复方案要写清楚，谁改、改什么、什么时候改完。改完之后必须验证。验证不是让开发自己说“好了”，而是让另一个人用同样的攻击方式再打一遍。打不通，才算过。我见过太多“已修复”的漏洞，换个参数又通了。

验证通过之后，把这次漏洞的细节写下来。不用长篇大论，就写：什么漏洞、怎么发现的、影响多大、怎么修的、以后怎么防。这份记录比任何安全培训都管用。下次再有人问“这个接口安全吗”，直接把文档甩过去。

最后说点实在的

漏洞处理没有银弹。流程再顺，也架不住有人不按流程走。我见过最离谱的，开发发现漏洞之后自己偷偷修了，没告诉任何人。结果修复方案有缺陷，两周后同一个地方又被打穿。问他为什么不走流程，他说“怕被骂”。

所以流程之外，还得有个氛围：发现漏洞不丢人，藏着掖着才丢人。那个电商朋友后来把流程贴在工位上，第一句话就是“先别慌，按步骤来”。半年后他们又遇到一次漏洞，从发现到止血，十二分钟。他说这次手没抖。