去年冬天，服务一个跑了六年的器漏老项目突然报警：数据库连接池每隔几小时就爆满，重启能撑一阵，洞何然后又挂。修复运维查了三天，服务最后发现是器漏某个接口在特定参数下会创建连接却忘了释放。代码是洞何五年前写的，写它的修复人早离职了。漏洞不一定是服务黑客攻击那种，更多时候就是器漏这种自己人埋的雷。

修复漏洞的洞何第一步不是动手改代码，而是修复搞清楚它到底是什么类型。有人一上来就搜“怎么修”，服务结果把SQL注入当XSS处理，器漏白忙活。洞何我习惯先把漏洞分个类：是输入验证没做，还是权限控制有缺陷，又或者是依赖库版本太老。分类决定了修复策略，也决定了修复需要多久。

先复现，再动手

没有稳定复现步骤的漏洞修复基本靠猜。我见过一个团队花了两个月重构认证模块，上线后发现问题依旧——因为他们从头到尾没搞清楚触发条件，只是觉得“这块代码看起来有问题”。复现的意义在于：你能确认修复是否真的生效，而不是改完代码跑个单元测试就宣布胜利。

复现之后，把漏洞的影响范围划出来。同一个漏洞可能出现在多个接口、多个服务里。之前有个文件上传漏洞，修了主站，忘了后台管理端用的是同一套上传组件。三天后被人从后台传了个webshell。修漏洞不是打地鼠，得找到所有同类入口。

修复手段的选择

能改代码就改代码，别老想着在WAF上加规则。WAF规则是临时止血带，不是治疗方案。我见过太多团队用WAF挡住攻击就算“修复完成”，结果规则写得太宽，正常请求也被拦，用户投诉不断。代码层面的修复才是根治。

如果漏洞出在第三方依赖库，升级版本通常是最快的路径。但升级有风险——新版本可能改了API，可能引入了不兼容的行为。我的做法是：先在小范围灰度环境升级，跑一轮完整的回归测试，确认业务逻辑没受影响再推全量。别在生产环境直接pip install --upgrade，那是赌博。

有些漏洞没法直接改代码。比如某个老系统用的加密算法已经被证明不安全，但替换算法意味着所有历史数据要重新加密，业务停机窗口又只有两小时。这种情况下，我的选择是：在入口层加一道临时防护，同时排期做数据迁移。临时方案要写清楚过期时间，不然“临时”会变成“永久”。

验证不是跑个扫描器就完事

修复完成后，用原始复现步骤再走一遍，确认漏洞确实堵住了。然后换几种变体试试——攻击者不会按你的复现步骤来。SQL注入修了参数化查询，那试试二次注入？XSS过滤了script标签，那试试img onerror？验证的目的是确认修复的鲁棒性，不是给自己发一张合格证。

还有一点容易被忽略：修复本身不能引入新漏洞。我见过为了修文件包含漏洞，把用户输入直接拼进include路径，结果变成了目录穿越。每次改完安全相关代码，我都会让另一个人review一遍，自己看自己的代码总有盲区。

上线之后的事

补丁推上去不是终点。监控要跟上——那个漏洞对应的攻击特征有没有再出现？日志里有没有异常请求？有一次我们修了一个越权漏洞，上线后监控显示还有零星请求试图访问不该访问的资源，虽然都被拦了，但说明有人还在试探。这些信息反过来能帮我们判断修复是否彻底。

最后说个实在的：漏洞修复的速度很重要，但比速度更重要的是别慌。慌就容易跳过复现、跳过影响面分析、跳过验证，最后修了个寂寞。我自己的节奏是：小漏洞当天修完，大漏洞先出缓解方案再排期根治。修一个算一个，别想着一次把所有问题都解决。