最近一条看起来很技术、其实很商业的消息，被很多人轻轻滑过去了：NIST 宣布从 2026 年 4 月 15 日起，不再试图为所有 CVE 都做完整 enrichment。以后它优先处理三类：进入 CISA KEV 的、联邦政府使用的软件、以及行政令 14028 定义的关键软件。其余 CVE 仍然会被收录，但会被标成“最低优先级，不立即 enrichment”。同时，NIST 也不再常规性地为已经由 CNA 给出分数的 CVE 再打一遍自己的 severity score。理由很直接：2020 到 2025 年，CVE 提交量暴涨 263%；2026 年第一季度又比去年同期高出接近三分之一。NIST 2025 年已经 enrichment 了接近 4.2 万条 CVE，比历史任何一年都多，但还是追不上。我的判断是：这不是一条“漏洞库更新公告”，这是整个安全行业被迫补课的时刻。过去很多团队其实不是在做漏洞管理，他们是在消费 NVD 替他们加工好的判断结果。一旦这个公共加工厂开始限产，谁在裸奔，马上见光。
先把话说得难听一点：大量企业口中的“漏洞治理能力”，本质上只是把资产清单、版本信息和一个免费公共数据库勉强缝在一起，然后假装自己完成了风险判断。平时大家打开扫描器，看见 CVSS 分数、受影响产品、参考链接、CPE 映射，点几下报表，流程就像在运转。问题是，这套运转并不等于你有能力。它只说明 NVD 过去一直在替你干脏活。它帮你把原始 CVE 文本翻译成更适合机器消费的结构化信息，帮你做一层优先级整理，甚至帮你在组织内部制造一种“我们是专业的”幻觉。现在 NIST 明牌：产能不够，优先做系统性风险更高的部分，剩下的你们自己想办法。很多安全团队这才会发现，自己真正拥有的只有一个采购预算、一套流程表格和几条 Slack 告警；至于判断能力，几乎没沉淀下来。
这事为什么重要？因为漏洞管理从来不是“有没有漏洞”的问题，而是“哪些漏洞和我的真实暴露面有关、哪些需要今天处理、哪些可以接受、哪些是误报、哪些会跟业务窗口冲突”。这里面最值钱的不是数据本身，而是上下文。公共数据库能提供通用上下文，却永远提供不了你的业务上下文。一个同样的 CVE，对做离线渲染农场的公司可能只是排队修，对经营支付链路的公司可能就是今天晚上必须切流的事故。NVD enrichment 能帮你少走路，但它不可能替你判断你的系统里哪一条链路会先死。可惜过去很多团队习惯了把“公共分数”误当“本地真相”。现在 enrichment 收缩，问题终于暴露：你们把最应该内生化的能力，长期外包给了一个本就不应该承担全部责任的公共基础设施。
这背后还有一个更少人愿意承认的现实：漏洞数量正在工业化增长，而安全团队的分析方式还停留在手工作坊时代。CVE 增长 263% 不是一个温和的趋势，它意味着整个上游软件生态的复杂度、开源依赖扩张、供应链耦合、以及漏洞披露自动化程度都在上升。另一边，大量组织的漏洞处置机制却仍然靠“周报会 + 工单 + 扫描器默认规则 + 高危先修”这套老法子硬撑。平时看起来还能转，是因为 NVD 和各种商业 feed 在前面做了大量预处理。现在公共处理能力跟不上输入洪峰，行业真正的瓶颈就不再是‘信息看不见’，而是‘看见以后根本不会判断’。
更麻烦的是，很多公司根本没有把安全当作决策系统，而是把它当作合规表演。扫描必须跑，报表必须有，季度审计必须过，至于这些漏洞是否连接到真实资产、是否存在 exploit path、是否已经被 compensating control 覆盖，没人真在乎。于是“分数”变成了组织内最好用的政治语言：9.8 就 push，7.5 就排期，4.3 就忽略。它的好处不是准确，而是便于甩锅。以后如果 NVD 不再给你补齐这些 enrichment，你会看到两类公司迅速分化。第一类会抱怨数据不完整、工具误报变多、团队压力暴增；第二类会趁机把自己的漏洞管理链路重建成真正的资产化能力。前者把安全当消费品，后者把安全当生产系统。差别就在这里。
NIST 这次更新里还有一个细节很值得警惕：它不再常规性地为已经由 CNA 提供分数的 CVE 重新给出单独 severity score。很多人会把它理解为“少一个字段而已”。错了。这里被拿走的不是一个数字，而是一层公共仲裁。过去不少企业在内部其实默认相信“只要 NVD 也给了分数，这事就算被二次确认了”。现在这层确认减少，组织必须更认真地面对一个老问题：谁给分，凭什么信，分数背后的攻击前提和资产暴露条件是否成立？这会逼着团队从“消费外部分数”转向“维护内部风险画像”。如果做不到，就会出现一种很荒唐的局面：扫描结果越来越多，情报源越来越杂，但真正能指导资源投入的判断越来越少。看起来信息爆炸，实际上认知破产。
从商业角度看，这也是一个清晰的信号：未来几年，真正值钱的安全产品，不会只是继续堆更多漏洞源，而是谁能把“公共 CVE + 本地资产 + 暴露上下文 + exploit 现实性 + 修复成本”压成一条可执行的决策链。换句话说，市场不会无限奖励卖数据的人，而会更奖励能卖判断系统的人。很多所谓“下一代漏洞管理”创业项目，嘴上讲 AI，实际上还是在做更花哨的列表页。那是扯淡。列表不是产品，分数不是判断，仪表盘更不是能力。用户真正愿意付钱的，是你能不能告诉他：这 800 个新增问题里，今晚必须动的只有 6 个；另外 50 个要进灰度窗口；剩下的 744 个不要污染团队带宽。谁能把噪音压成动作，谁就有商业价值。
这也是为什么我一直觉得，安全领域最被高估的是“情报获取”，最被低估的是“处置编排”。大家总爱吹自己接了多少 feed、同步了多少源、覆盖了多少组件，好像接得越多就越先进。不是。信息入口过多而没有裁剪机制，只会让团队溺死在告警里。真正成熟的系统应该反过来：先知道自己的 crown jewels 在哪，哪些组件出问题会变成现金损失、监管风险或声誉事故；然后再根据这个业务地图决定情报如何流入、流到谁、用什么阈值触发、谁有权 override、什么情况下可以接受风险。这个顺序如果反了，你买再多 feed 也只是给恐慌加带宽。
对开发团队而言，这次变化也该让一个坏习惯早点死：把漏洞修复理解成安全团队的下游工单。事实上，随着 enrichment 覆盖收缩，最需要前移的是工程侧的组件认知。你的 SBOM 是否可信？你知道哪些服务真的加载了那个有问题的库，哪些只是镜像里存在但运行路径永远不会触发？你有没有能力在 CI/CD 阶段就把 exploitability、runtime reachability 和业务优先级一起纳入？如果没有，最后所有“不确定性”都会被倒进安全团队，而安全团队再把这些不确定性包装成高优告警扔回开发。这种互相折返跑，浪费得像一台组织级绞肉机。
很多人喜欢把公共基础设施的变化看成“供应侧问题”，仿佛只要 NIST 以后自动化做得更好，一切又会恢复正常。我的判断没那么乐观。即便 NIST 后续引入更多自动化流程，这次调整也已经把一个事实写得很清楚：漏洞情报的免费公共层，不可能无限吸收整个软件世界膨胀出来的复杂度。上游漏洞数量继续增长，下游系统越来越碎片化，靠一个中央数据库替所有人做完整分析，这条路本身就不可持续。它过去之所以看起来能跑，是因为大家低估了系统成本，也高估了公共部门兜底的范围。现在只是账单终于寄到了每家公司自己门口。
所以企业现在该怎么做？不是去群里转发一句“兄弟们 NVD 不行了”，也不是立刻加购一堆替代 feed。先做三件更朴素的事。第一，重建资产视图，别再假装 CMDB 那份年久失修的表格是事实。第二，把漏洞优先级模型从“公共分数驱动”改成“业务暴露面驱动”，至少把互联网暴露、横向移动潜力、数据敏感度、补丁可行性这些变量纳进来。第三，在组织里明确谁拥有最终风险判断权，不要再让扫描器默认配置代行治理。说白了，工具可以帮你发现问题，但只有组织能决定什么叫问题。
如果把这件事放到更大的技术史里看，它其实不只属于安全圈。几乎所有技术团队都在重复同一种幻觉：把一个稳定提供公共服务的上游，当成可以永久免费继承的能力。云平台替你兜底可用性，于是你忘了自己的架构弹性；开源社区替你维护依赖，于是你忘了自己的供应链责任；NVD 替你做 enrichment，于是你忘了自己的风险判断。等上游一收缩，大家第一反应都是“服务怎么退化了”，很少有人先问：“我是不是早就把不该外包的能力外包出去了？” 这才是最值钱的反思。技术行业最危险的，不是工具失效，而是组织在长期顺手使用中，把外部便利误认为内部能力。
所以我的结论很简单：NIST 不是突然变差了，它只是终于停止无上限地替整个行业贴补认知成本。真正该脸红的不是 NIST，而是那些一边吹自己安全成熟度，一边离开免费 enrichment 就不会排序、不会取舍、不会响应的团队。以后还能活得好的组织，不是情报最多的组织，而是最早把判断权收回自己手里的组织。安全从来不是数据堆栈比赛，而是资源稀缺条件下的决策艺术。谁还把它当作自动报表流水线，谁就等着在下一次输入洪峰里被自己淹死。
—— https://www.80aj.com