建立漏洞审查制度

去年某电商平台被拖库，建立八千万用户数据挂在暗网叫卖。漏洞事后复盘，审查根子不在防火墙，制度而在于一个三年前就被白帽子提交过的建立SQL注入漏洞——当时开发团队觉得"业务紧急"，把修复排期压到了版本迭代末尾，漏洞然后就没有然后了。审查这不是制度孤例。漏洞本身不可怕，建立可怕的漏洞是没人盯着它什么时候被修、谁来修、审查修没修完。制度

漏洞审查制度要解决的建立，恰恰是漏洞这个"然后"的问题。

别把扫描器当万能药

很多团队买了商业扫描工具，审查每周跑一次报告，觉得这就是审查了。我见过一家金融公司，扫描器报告里高危漏洞常年挂着两百多个，安全负责人说"都是误报"。我让他随机抽十条人工验证，七条是真的。扫描器的问题在于它只告诉你"这里可能有问题"，不告诉你"这个问题在当前业务场景下能不能被利用"。一个内网测试环境的弱口令和一个生产环境支付接口的越权，在报告里都是"高危"，但优先级差了十万八千里。

审查制度的第一步，是有人对漏洞做人工研判。不是看CVSS评分，是看这个接口谁在调、数据流向哪、攻击面暴露程度多大。这活儿累，但省不掉。

修复要有"死线"，不能有"排期"

"排期"这个词在研发流程里意味着弹性。业务需求插进来，漏洞修复往后挪，挪着挪着就没了。我观察到一个规律：凡是把漏洞修复和业务需求放在同一个池子里排期的团队，漏洞修复率几乎没有超过40%的。

有效的做法是给漏洞单独设SLA。严重漏洞24小时内出修复方案，72小时上线补丁；高危一周；中低危按月批量处理。到期没修完，自动升级到技术VP那儿。听着粗暴？某头部短视频公司就是这么干的，他们的漏洞平均修复周期从47天压到了6天。关键不是惩罚谁，是让"不修"这件事变得有成本。

复审不是走过场

修完就完了？不行。我见过太多"修了但没修干净"的案例。一个文件上传漏洞，开发加了后缀名白名单，但没校验文件内容，攻击者改个Content-Type照样传webshell。复审要有人实际构造payload去验证，不是看代码diff里有没有加过滤函数就点"已修复"。

复审的人最好不是修漏洞的人。自己验自己，心理上就不容易发现问题。小团队做不到完全独立？至少换个人点确认按钮。

把漏洞变成资产而不是负担

每个修完的漏洞都应该进知识库。什么类型的漏洞、什么业务场景下出现的、修复方案是什么、复审时怎么验证的。下次同类型业务上线，开发自己就能对照检查。某互联网公司的安全团队把三年积累的漏洞案例做成了内部检索工具，新项目安全评审时直接匹配相似场景，漏洞复发率降了六成。

漏洞审查制度说到底就三件事：有人看、有人修、有人验。流程不用复杂，但每个环节都得有明确的责任人和时间点。做不到这三点，买再贵的扫描器也是自欺欺人。