漏洞管理这件事，运营在运营商BG里从来就不是漏理规一个纯技术问题。现阶段最现实的洞业定中段矛盾是：安全团队追着研发修漏洞，研发团队追着业务上线，现阶业务团队追着收入指标。运营三方角力之下，漏理规漏洞业务管理规定写得再漂亮，洞业定中段落地时也常常被挤到墙角。现阶

我翻过几份省级公司的运营漏洞管理细则，有个共同点：定级标准照搬集团文件，漏理规高危、洞业定中段中危、现阶低危分得清清楚楚，运营但到了"修复时限"这一栏就开始模糊。漏理规高危48小时，洞业定中段中危7天，低危30天——纸面上没问题。实际呢？一个高危漏洞从扫描器报出来，到工单派到具体研发手上，中间要经过安全室确认、平台组复核、项目经理分派，光流程就走掉一天半。研发拿到工单时，距离deadline只剩不到两天。他手里可能同时压着三个需求迭代，你让他停下一切去修漏洞？不现实。

去年某省运营商的一个案例很典型。一个对外服务的API接口存在越权漏洞，扫描器报高危，安全团队当天就发了工单。研发那边的回复是"已知晓，排期中"。三天后漏洞被外部白帽子提交到CNVD，省公司被通报。事后复盘，研发负责人说了一句大实话："这个接口下个月就要重构了，现在改代码等于白改。"这话听着像借口，但做过研发的人都懂——在快速迭代的节奏里，为一个即将下线的功能修漏洞，ROI确实低得可怜。

规定里其实留了口子。我注意到多数版本都有一条"业务下线或重构可申请延期修复"，但申请流程极其繁琐：需要研发主管、产品经理、安全接口人三方签字，还要附上下线计划书。结果是，真正走完延期流程的漏洞不到10%，剩下的要么超期硬修，要么就挂在系统里变成"僵尸漏洞"。

另一个被忽视的细节是漏洞修复的验证环节。安全团队复测时发现，研发提交的修复版本经常只改了表面——比如把报错信息里的敏感字段删了，但底层逻辑没动。复测不通过，工单打回，一来一回又是两天。研发觉得安全团队吹毛求疵，安全团队觉得研发敷衍了事。这种互不信任一旦形成，后面所有协作都会变形。

现阶段比较务实的做法，是把漏洞管理和研发现有的DevOps流程做嵌入，而不是另起一套。比如在CI流水线里加一个轻量级SCA扫描，只卡新增依赖的高危漏洞，存量漏洞走单独的季度清理计划。这样研发不会觉得安全在"卡脖子"，安全也能守住增量不恶化的底线。某地市公司试过这个路子，半年后新增高危漏洞数量降了六成，存量漏洞也按季度滚动消化掉了一部分。

当然，这需要安全团队放下"全量清零"的执念。漏洞是修不完的，尤其是在运营商这种体量下，资产盘子大、历史包袱重、业务迭代快。管理规定如果只强调"必须修完"，最后只会逼着下面的人造假——要么改扫描器策略把高危降成中危，要么在工单系统里点个"已修复"但实际没动。这种数字游戏，比漏洞本身更危险。

说到底，漏洞业务管理规定的生命力不在于条款多严密，而在于它是否承认现实约束。承认研发资源有限，承认业务优先级有高低，承认安全不是唯一正确的事——然后在这个前提下，找到一条各方都能走下去的路。现阶段，这条路的起点不是"零漏洞"，而是"漏洞不失控"。