没有 CVE 不代表你安全——有 CVE 也不代表就一定很糟

首先，请允许我声明——请修复你的 CVE。

说真的！！如果你发布的软件带有已知的、未修复的 CVE，你就是在玩火，并且正在制造真实且不容忽视的风险。到了那个地步，你无异于把通往王座的地图亲手交给了攻击者，还天真地以为他们不会使用它。这是不负责任、不可接受且完全可以避免的。

但接下来这部分，是大多数人要么不敢大声说出来，要么只能对着虚空呐喊，却无人听闻，在痛苦和悲伤中沉沦：

仅仅修复 CVE 是不够的。

大多数公司像对待一张检查清单一样处理软件安全。他们运行扫描器，拉取报告，追踪 CVE。当一个红色的 CVE 出现时，相关人员就会被呼叫，他们会放下手头的一切，像无头苍蝇一样乱窜。一份干净的报告则意味着可以安全部署。

但这种心态本身就是个问题。

安全并非始于或终于 CVE。一份干净的扫描器输出可能隐藏着危险的行为。一个看起来很吓人的 CVE 在你的系统中可能永远无法被利用。而且，许多造成了毁灭性后果、有着花哨名称的安全漏洞，根本就没有任何 CVE。其中许多漏洞仅仅是代码做了一些它本不该做的事情。

我将用我的时间来解释 CVE 到底代表什么，它们遗漏了什么，以及为什么它们不能成为你唯一的防线——愿上帝助我。

CVE 的真正含义

一个可悲但真实的事实是，CVE 只是一个标签。是的，你没听错！当有人发现一个安全问题并公开发布时，他们就可以申请一个 CVE 标识符。CVE 本身不修复任何东西，不解释上下文，也不说明这个缺陷在你的系统里到底有多严重。它只是记录了某人，在某地，发现了某个在某些条件下可能被利用的东西。

一旦 CVE 被发布，扫描器就可以使用这个标签来匹配软件版本和文件哈希值。这些匹配结果会填充到仪表盘和警报中。然后，组织会分配严重性、修复截止日期和风险评分。这是一个为规模化而生的系统。

但这个系统在广度上得到的一切，都在深度上失去了。

CVE 是一个狭隘的视角

CVE 只分配给那些遵循正式披露流程的问题。如果一个漏洞被私下发现并修复——可能由内部安全团队或在重构过程中完成——就不会发布 CVE。如果一个不当行为不明显是软件缺陷，它可能永远没有资格获得 CVE。一些安全漏洞关乎错误的配置、不安全的默认设置、不安全的假设，或是跨系统的复合行为。

CVE 数据库不会追踪这些问题。

由于延迟，一些漏洞也会被遗漏。报告、分类和分配 CVE 的过程可能需要数天或数周。在此期间，攻击者可以利用该漏洞。团队可能已经部署了修复程序。但在该 ID 被分配和发布之前，扫描器不会标记任何东西。

此外还存在可见性差距。并非所有生态系统都被同等覆盖。小众工具、内部代码分支或没有公开披露流程的企业软件通常不会被追踪。这些系统可能带有同样大的风险——但它们不会出现在 CVE 的视野中。

许多安全漏洞的开端并无 CVE

现实世界的攻击不按规则出牌。

一台服务器向公网暴露了调试端口。一个开发者将密钥硬编码到容器镜像中。一个脚本接受用户输入并以不安全的方式执行它。一个配置错误的防火墙让攻击者能够与内部服务通信。这些事情都不会触发 CVE 警报，但它们都可能导致系统被完全攻陷。

看看第一资本（Capital One）的泄露事件——没有 CVE，只有一个配置错误的 WAF 和权限过大的 IAM 角色。或者多年来发生的数十起 S3 存储桶泄露事件，原因不过是默认设置和人为错误。没有扫描器能救你。

安全事件常常源于行为——即系统做了什么，而不是它包含了什么。但 CVE 关注的是内容：存在哪个软件包的哪个版本。攻击的发生方式与漏洞的追踪方式之间存在脱节。

并非每个 CVE 都值得按下那个红色恐慌按钮

在你的代码库中有一个 CVE 并不总是意味着你很脆弱。比方说，一个库可能在一个你从未调用的函数中存在缺陷。受影响的代码可能受到沙箱保护，或者以有限的权限运行。环境可能不满足利用所需的条件。一些 CVE 需要特殊的输入、对特定 API 的访问权限或多个步骤才能触发。

但扫描器对此一无所知。它们看到一个匹配，就拉响警报。

我们曾经因为一个图形界面（GUI）库中的严重 CVE 而收到警报……而它存在于一个纯命令行（CLI-only）的镜像中。那个代码路径根本无法被访问到。但扫描器看到了版本匹配，还是触发了警报。几个小时白白浪费，安全性上没有任何增益。

这导致了警报疲劳、浪费了分类工作的精力，有时还会因为打上那些对风险态势毫无实质性改善的补丁而导致不必要的停机。

延迟、沉默与阴影

CVE 的创建和共享速度也存在实际限制。这个过程依赖于负责任的披露：研究人员或报告者必须找到正确的渠道，CNA（CVE 编号授权机构）必须评估报告，并且记录必须被发布。与此同时，威胁依然存在。

有时修复先于 CVE 到来。有时 CVE 来得太晚。有时最危险的问题根本从未被报告——因为缺陷未被识别为安全问题，或者因为软件很冷门，或者因为没有报告的激励。

那些等待 CVE 出现才采取行动的安全团队，默认就在扮演追赶者的角色。

干净报告带来的虚假安全感

上面的例子并不罕见。在许多环境中，危险的行为并非来自已知的漏洞——它们来自意想不到的交互、被忽视的默认设置、代码中那些本无意造成风险的小失误。

但是，当团队看到一个绿色的仪表盘——0个严重 CVE——他们就认为系统是安全的。这才是真正的危险：那种“如果没有报告任何问题，就说明一切正常”的假设。

这就是为什么安全需要多重视角。静态和动态分析工具可以帮助及早发现危险的代码路径。运行时监控解决方案——特别是那些设计时就考虑到强隔离的方案——可以在非预期行为发生时检测到它们。一些现代平台甚至更进一步，实时追踪执行路径、系统调用和权限边界，而不仅仅依赖于已知的签名。

我的咆哮到此为止——我保证

请修复你的 CVE。但要明白，一个系统的安全性，并不取决于是否存在 CVE。

扫描器永远不会知道你的系统实际上在做什么。它们抓不住非预期的行为。它们看不到滥用、逻辑炸弹或架构腐化。

安全不是对别人已经贴上标签的东西做出反应，而是要理解你到底构建了什么。

如果你的系统正在做一些你意想不到的事情——它有没有对应的 CVE 根本不重要。那就是你的漏洞。

因为最危险的缺陷，并不总是那些有名字的。而是那些无人关注的。

👉 关注「玄月调查小组」，解剖硬核技术！

原文链接

https://www.linkedin.com/pulse/just-because-theres-cve-doesnt-mean-youre-safe-one-its-kavitha-daula-lkrqe