去年有个朋友在一家做企业服务的漏洞公司当开发，他们产品上线三个月，管理被白帽子提交了四十多个漏洞。系统团队总共六个人，漏洞光处理这些漏洞就花了将近两个月。管理他跟我说，系统最崩溃的漏洞不是漏洞本身，而是管理整个处理流程——漏洞信息散落在邮件、聊天记录、系统Excel表格里，漏洞谁负责哪个、管理修到哪一步了，系统全靠问。漏洞

这不是管理个例。很多团队在漏洞管理上的系统状态，跟二十年前用文件夹管理客户资料差不多。

漏洞管理不等于漏洞扫描

不少人把这两件事混为一谈。买了个扫描器，跑一遍，出一份报告，觉得漏洞管理做完了。扫描只是入口。真正麻烦的是后面那些事：这个漏洞要不要修、谁来修、什么时候修完、修完之后怎么验证、如果暂时修不了有没有缓解措施。这些问题扫描器回答不了。

我见过一个比较极端的案例。某公司的安全团队每周跑一次扫描，报告自动发到群里，然后……就没有然后了。三个月后的一次渗透测试，发现之前扫描出来的高危漏洞一个都没修。问开发团队，回答是“不知道要修”。问安全团队，回答是“报告发过了”。

信息传递了，但管理没有发生。

一个可用的系统长什么样

漏洞管理的核心动作其实就几个：发现、记录、定级、分配、修复、验证、关闭。听起来简单，但每个环节都有坑。

记录环节，关键是统一。不管漏洞来自扫描器、渗透测试、SRC、还是客户反馈，都得进同一个池子。字段至少包括：漏洞描述、影响范围、严重等级、发现时间、来源。有些团队用Jira凑合，不是不行，但Jira不是为漏洞管理设计的，缺少CVSS评分、CVE关联、SLA追踪这些能力。

定级这件事，争议最大。安全团队觉得高危的，开发团队可能觉得无所谓。我自己的判断是，定级不能只看技术指标，得结合业务场景。一个SQL注入放在内部测试环境，和一个SQL注入放在支付接口，严重程度完全不同。CVSS能给一个基础分，但最终等级应该是安全团队和业务方一起定的。这个过程本身就是在对齐认知。

分配和修复是最容易卡住的地方。漏洞进了系统，得有人认领。很多团队的问题在于：安全团队没有权力要求开发团队优先修漏洞，开发团队又有排得满满的业务需求。这时候需要的是一个明确的SLA机制——高危漏洞24小时内响应、72小时内修复，中危一周，低危排期处理。SLA不是摆设，得有升级机制。超时了，自动通知技术负责人。

验证环节经常被忽略。开发说修好了，安全不验证就关闭，这是自欺欺人。验证必须由发现方或者独立的安全人员来做。修了但没修对的案例太多了——过滤函数写错了、只修了一个入口、绕过方式还在。

工具之外的事

我观察下来，漏洞管理做得好的团队，工具只是一部分。更重要的是两件事：一是安全团队和开发团队之间的信任关系，二是管理层对安全工作的实际支持。

信任关系怎么建立？安全团队不能只当“挑刺的人”。帮开发团队理解漏洞原理、提供修复建议、甚至在架构设计阶段就介入，这些动作比发报告有用得多。有个安全负责人跟我说过一句话：“我们团队的目标不是找漏洞，是帮业务方把漏洞修掉。”这个定位差异，结果完全不同。

管理层支持不是嘴上说说。漏洞修复排进迭代、安全指标纳入考核、SLA超时有明确的问责路径——这些才是真支持。否则安全团队再努力，也只是在推一块永远推不动的石头。

漏洞管理系统的价值，不在于它能扫描出多少漏洞，而在于它能让每一个被发现的漏洞都有明确的归宿。从发现到关闭，每一步都有记录、有责任人、有时间节点。这件事听起来不酷，但它是安全工作的地基。