漏洞是被关闭的，不是被抹掉的
当人们问漏洞都去哪儿了，诚实的回答是：大多数都被解决了。一项针对模型上下文协议（Model Context Protocol）开发框架中漏洞的研究，考察了已解决的漏洞、它们的成因，以及自动修复的效果如何[1]。这个视角很重要：漏洞并不是自己停止存在的——是某个人（或某个工具）发现了它们并修好了它们，而修复记录正是让它们显得“消失”的原因。
这是一种维护活动，而不是一次性的清理。同一项研究把用户使用这些框架时出现的漏洞与其他类型的漏洞区分开来，这说明被跟踪和修复的漏洞与软件的实际使用方式有关[1]。换句话说，那些“消失”的漏洞，是经由真实使用暴露出来、随后得到处理的漏洞。
有些漏洞要等软件跑起来才现身
并不是每个漏洞都能靠提前检查代码抓到。一个名为幽灵猎手的运行时系统，通过检查生产环境中的路由器在运行时是否真正遵守协议，来检测 BGP（路由器用来交换路由信息的协议）中的漏洞[2]。研究发现，这类实现层面的漏洞数量很多，也就是说，大量漏洞躲过了部署前的各种检查。
实际启示是：“漏洞去哪儿了”取决于你什么时候去看。静态检查抓不到的漏洞不会消失；它们待在运行中的系统里，直到运行时检测器或一次真实故障把它们暴露出来[2]。所以答案并不是“它们全被修好了”——有些只是还没被发现而已。
修复漏洞不等于杜绝漏洞
证据表明，主要机制是解决问题，而不是彻底消除。那项模型上下文协议研究把自动修复作为漏洞解决方式的一部分来评估[1]，而 BGP 的研究则表明，即使有了检测手段，实现层面的漏洞依然很多[2]。这两项结果都不支持“漏洞正被彻底设计掉”这种想法。
所以，如果你想知道漏洞都去哪儿了，最准确的图景是一条流水线：漏洞出现，有些被早早抓住，另一些只在运行时才暴露，而我们已知的那些会被修复并关闭[1][2]。我们不知道的那些仍然在外面——只是还没进入“已解决”那一栏。
本文引用的文献
理解模型上下文协议开发框架中的漏洞：一项实证研究
一项针对模型上下文协议开发框架的实证研究分析了已解决的漏洞、它们的根本原因以及自动修复的有效性，并把用户侧的漏洞与其他类型的漏洞区分开来。
当静态验证不够用时：在运行时揭示 BGP 漏洞
幽灵猎手是一个运行时系统，通过验证协议合规性来检测生产路由器中的 BGP 漏洞，其分析发现 BGP 实现层面的漏洞数量很多。