修不完的漏洞，找不到的主人

每一家公司都有一张修不完的漏洞清单，但几乎没有一家公司能说清：这张清单上每一行，究竟归谁管。

过去十几年，漏洞管理这门生意建立在一个朴素的假设上：扫得越全、报得越准，企业就越安全。于是 Tenable、Qualys、Rapid7 这些扫描器厂商把检测能力卷到了极致，资产探查、无代理扫描、云原生覆盖，功能列表一年比一年长。但一个尴尬的现实是：绝大多数组织的漏洞积压量并没有随着扫描器的进化而下降，反而在缓慢上涨——Nucleus Security 历年的《State of Vulnerability Management》调查持续呈现同一个图景：企业修复漏洞的速度，追不上新漏洞入库的速度（来源：Nucleus Security, The State of Vulnerability Management）。

问题的答案可能很反直觉——这不是一个技术问题，而是一个所有权问题。组织缺的不是更好的扫描器，而是知道自己有哪些资产、谁对这些资产有修复权限、以及谁真的有能力把它修掉。

📉 扫得越多，修得越少

扫描器的进步，追不上它自己制造积压的速度。

先看一个几乎所有安全团队都熟悉的场景：周一早上，扫描任务跑完，安全运营的群里弹出一份几百条的漏洞报表。安全工程师花一上午去重、分级、翻译成工单，分发给研发和运维。到了周五复盘，真正关掉的可能不到两成，剩下的被标记“暂缓”，静静躺在下个月的报表里——直到下一次扫描把它们重新捞出来，甚至更多。

这个循环背后有几个被反复验证的事实。第一，扫描器的覆盖面在持续扩大：云主机、容器镜像、SaaS 应用、代码依赖，每一类新资产接入扫描，都会带来新一轮发现。第二，CVE 的产出速度常年保持在高位——NVD 的年度统计显示，新增 CVE 数量从 2023 年的约 2.9 万条跃升至 2024 年的约 4 万条，同比增幅接近四成（来源：NIST NVD 年度统计）；一个中型企业的周度新增漏洞条目动辄数百条，而安全团队的人力是恒定的。第三，大量扫描结果存在重复、误报和不可达问题——同一个漏洞，被基础设施扫描器、容器镜像扫描器、SAST 工具各报一次，三条工单指向同一个修复动作，却要流转三个团队。

结果就是：检测侧越努力，处置侧的噪声越大，积压池越深。扫描器厂商不会告诉你这一点，因为“修不完”恰恰是续费的燃料。但对甲方来说，这意味着一个残酷的判断：在当前的组织形态下，再买一台扫描器，边际收益趋近于零。

这一判断有公开数据可依。Edgescan 连续多年的《Vulnerability Statistics Report》显示，全球企业对已知高危漏洞的平均修复时长长期徘徊在 50–60 天区间，且多年未见实质性改善（来源：Edgescan, Vulnerability Statistics Report）。而攻击侧的时钟却在加速：Mandiant《M-Trends 2023》测得，从 CVE 公开到首次被在野利用的中位时间已缩短至 5 天（来源：Mandiant, M-Trends 2023）；Verizon《2024 数据泄露调查报告》则记录了“利用漏洞作为初始入侵手段”的占比一年内暴增 180%，达到全部入侵事件的 14%（来源：Verizon, 2024 DBIR）。修复以“月”计、利用以“天”计——这个剪刀差，就是甲方安全负责人在选型时把“每条告警的处置成本”看得比“检出率和误报率”更重的根本原因。不是工具不够好，是人修不过来。

这条流程图里最关键的一环，恰恰是绝大多数组织最薄弱的一环：归属判定。

🏷️ 没有资产清单，就没有漏洞的主人

你无法为一个不认识的资产，指派一个不存在的负责人。

漏洞修复的第一步不是打补丁，而是回答一个问题：这台机器、这个应用、这个依赖库，是谁的？听起来像是个常识，但在真实的企业环境里，这个问题往往问不出答案。Flexera 的年度漏洞调研反复给出同一个结论：全球范围内，对自身资产清单完整性抱有信心的安全从业者长期不足一半（来源：Flexera, Vulnerability Review 系列报告）。

原因是资产和组织的漂移是双向的。资产在漂移：容器跑完了就销毁，测试环境用完没人回收，部门偷偷采购的 SaaS 挂在某个个人账号下——影子 IT 从来没有消失，只是从影子服务器变成了影子订阅。组织也在漂移：业务线重组、团队合并、核心开发离职，资产登记表上的责任人字段半年没更新，成了技术债务里的“幽灵字段”。CMDB 曾经被寄予厚望，但几乎所有安全从业者都心知肚明：CMDB 的数据质量衰减速度，比任何其他系统都快，因为它依赖人来维护，而人天然不爱维护台账。

于是出现了一个荒诞的闭环：扫描器能发现漏洞，却把漏洞派给一个已经离职的邮箱；工单在系统里显示“已派发”，SLA 时钟在走，补丁却永远打不上。漏洞不是没人修，是没人有资格修。

这背后的产业逻辑值得展开说一句。传统漏洞管理产品解决的是“看见”，而“看见”和“修复”之间隔着资产治理这道坎。这道坎不是安全团队能独立迈过去的——它要求 CMDB、云控制台、CI/CD 流水线、代码仓库的元数据打通，要求每当一个应用变更 owner，漏洞归属同步变更。近几年 Wiz 这类云原生安全平台的爆发，以及暴露面管理概念的走红，本质上都是同一个判断的产物：客户真正缺的不再是一份更全的漏洞列表，而是一条从“资产”到“责任人”的、可信的、自动维护的映射链路。

换句话说，漏洞管理正在从一个安全工具品类，退化——或者说升维——成一个资产数据治理品类。

🔑 发现的不管修，修的没权限

漏洞处置链条上最贵的一公里，是组织架构造成的。

就算资产归属查清楚了，第二个断层立刻浮现：权与能的错位。

安全团队有“发现”的权力，通常没有“修复”的能力——他们不掌握代码库，没有生产环境变更权限，也不该有。研发团队有能力修复，但漏洞修复天然排在功能迭代之后：业务版本赶工期，补丁永远排不上 sprint。运维团队有权限执行变更，却既不知道这个漏洞的业务影响，也不敢在冻结期动生产环境。三方各持一半拼图，谁也拼不出完整图案。

更微妙的是激励结构。修复漏洞对研发来说是没有 KPI 加分的苦役——修好了没人表彰，修崩了要背事故。在这种激励下，理性的选择就是拖延、降级、在工单系统里用“风险评估中”四个字无限循环。安全团队则用“漏洞积压率”考核自己，于是把精力花在报表美化上，而不是真正推动修复。两个团队都在完成各自的指标，漏洞却纹丝不动。

这张表的核心结论只有一句话：漏洞修复的责任必须落在资产所有者身上，而不是安全团队身上。 安全团队的角色应该是定规则、给情报、验结果，而不是替业务扛下所有修复义务。这和财务上的逻辑一样：预算是业务负责人的，合规是财务部门的——财务部门不会替业务部门挣钱，也不该替它还债。

近两年一些走在前面的企业开始做机制实验：把高危及以上的漏洞修复率写进研发团队 OKR，把“存在未修复高危”设为发布流水线的硬门禁，用自动化把“修复—验证—关单”压缩到小时内闭环。这类机制改造的价值，在 Cyentia Institute 与 Kenna Security 合作的《Prioritization to Prediction》系列研究中得到了量化印证：把修复排序从 CVSS 评分转向“实际被利用概率＋资产重要性”之后，团队在同等资源下消除真实风险的效率出现了成量级的提升（来源：Kenna Security / Cyentia Institute, Prioritization to Prediction）。原因不复杂——它改变的是人的行为，而不是机器的输出。

⚙️ 修不修得动，最终是个产能问题

权责理顺之后，剩下的拦路虎是时间。

很多讨论止步于“落实责任”，但落实责任解决不了最后一个问题：修复是需要产能的。一个团队手上有三条在途需求、两个线上问题，突然收到 40 条中危工单，就算他百分之百认领，也修不完。

这就是为什么修复归属问题有三个层次，缺一不可：知道谁拥有资产，确认谁有权限修复，确认谁有产能修复。 第三个层次最容易被忽视，却最真实。补丁窗口、变更冻结期、灰度策略、回滚预案，每一个都是产能约束。一个不做可达性分析和风险排序的组织，会把宝贵的修复产能均匀洒在几千条漏洞上——结果是最危险的 5% 和最无害的 5% 得到了同等对待，等于谁也没被对待。

而“最危险的那一小撮”确实很小。Kenna Security 与 Cyentia Institute 对数亿条漏洞—攻击数据的分析显示，历史上真正被武器化利用过的漏洞只占全部漏洞的约 4%–6%（来源：Prioritization to Prediction, Vol.1）。这也是风险优先级漏洞管理（Risk-based Vulnerability Management）这条产品赛道在过去几年崛起的根本原因。以 Kenna Security（后被 Cisco 收购）为代表的一批厂商，核心卖点就是把修复排序从 CVSS 评分转向实际利用风险，让有限产能先砸向真正会出事的那一小撮。方向是对的，但它有一个前提：资产和责任人数据必须先是对的。排序算法再精妙，排序的对象是一堆无主资产，输出依然是一堆无主的建议。

这张图想说明的是：修复速度不是链条末端的决定，而是链条起点的决定。资产登记的那一刻，漏洞的最终命运就已经被大半决定了。

🧭 产业的转向：从卖扫描，到卖闭环

扫描器的时代红利见顶，下一个战场是修复的所有权。

把视角拉回产业，能看到一条清晰的迁移路径。第一代漏洞管理卖的是“发现”——扫描器＋报表，客户的采购逻辑是合规驱动。第二代卖的是“优先级”——RM/ASPM 类产品帮客户在噪声里挑出真风险。而现在，头部厂商的叙事正在向第三代迁移：“暴露面管理”和“修复编排”——不只告诉你哪里有洞，还要告诉你洞在哪个资产上、该派给谁、修完怎么自动验证、整条链路的堵点在哪里。Gartner 把这一趋势收拢进“持续威胁暴露面管理（CTEM）”的框架，其核心主张同样是：暴露面清单必须与资产责任归属绑定，否则无法转化为可执行的修复动作（来源：Gartner, How to Manage Cybersecurity Threats, Not Incidents and Alerts）。

对甲方安全负责人来说，这个转向带来的采购逻辑也变了。评估一套漏洞管理方案，真正该问的问题不再是“你能检出多少漏洞”，而是：你能不能对接我的 CMDB 和云台账，实时回答“这条漏洞归谁”？你能不能把修复状态回写进研发的工单系统而不是安全团队自己的报表？当资产责任人变更时，你的归属映射多久能更新？——这三个问题的答案质量，比检测率更能预测这家企业两年后的漏洞积压水位。

📜 监管不会问你修没修完，只会问你能不能说清是谁的责任

同样的逻辑，在监管与审计侧正在从“软约束”变成“硬约束”——而这恰恰是模糊信源之外，文章本该把论证补完整的地方。

看三条已经被写进法条的脉络。在中国，2021 年施行的《网络产品安全漏洞管理规定》明确要求产品提供者在发现或获知漏洞后 2 日内报送详情，运营者须“及时组织验证并完成修补”——注意，这里的义务主体不是安全部门，而是产品与业务的责任主体。在美国，CISA 的第 22-01 号约束性指令（BOD 22-01）直接给联邦机构划了死线：KEV 目录中被确认在野利用的漏洞，须在两周内完成修复，逾期即视为不合规；2023 年底生效的 SEC 网络安全披露规则则更进一步——发生重大网络安全事件，上市公司须在 4 个工作日内提交 8-K 披露。在欧盟，2024 年落地的 NIS2 指令把“漏洞处理与披露”列为成员国的强制义务，配套的《网络弹性法案》（CRA）更是把漏洞管理责任一路压实到产品制造商。

把这三条线放在一起，监管的真实姿态已经很清楚了：监管层不打算考核你的扫描器，它要考核的是你的组织机制。 当监管要求“漏洞在 X 天内修复”时，真正被考验的不是检测能力，而是组织有没有一套能把责任落到具体人头上的机制。没有这套机制的组织，合规报告可以做得很漂亮，审计或应急时却会发现关键补丁卡在审批链的第三层——复盘报告里写“流程待优化”，罚款通知书上写的是公司法人代表的名字。换句话说，监管正在替安全团队