文章探讨“零 CVE”容器镜像的挑战，指出传统发行版修复滞后可能误导用户，Chainguard提供从源重建方案。同时质疑 CVE 的局限性及可能被滥用，强调需结合情境理解风险。
译自：The hunt for truly zero-CVE container images
作者：Steven J. Vaughan-Nichols
供应商在传统 Linux 发行版之上追求“零 CVE”容器镜像时，遇到了上游发布模型的结构性限制。CVE 仍然是衡量安全性的有用但不完善的指标。
我们都希望容器镜像中没有常见漏洞和暴露 (CVE)，创建此类镜像本身已成为一门生意。最初是一种激进的“左移”姿态，现在已成为容器化工作负载的基本期望。但创建这些安全镜像的最佳方式是什么？
Chainguard 作为领先的零 CVE 容器镜像供应商之一，利用其新软件 Factory 2.0 及其 DriftlessAF 开源方法，在检测到上游更改时直接从源代码重建容器和库。每个容器构建清单代表系统可复现的输出，涵盖初始构建、依赖项和漏洞驱动的重建、工具变更以及生成的 SBOM 和签名，所有这些都旨在实现默认安全状态。
其他零 CVE 镜像构建者，例如 Docker 及其 Docker 强化镜像 (DHI)，提供减少的攻击面、非 root 默认设置、SBOM 和加密来源，并采取了不同的方法。它们与 Alpine Linux 和 Debian Linux 的上游绑定。
Sam Katzen，Chainguard 的产品营销经理，在最近接受《The New Stack》采访时指出，“上游发行版维护者漫长的依赖链和较慢的发布周期 […] 根本无法跟上当今报告漏洞的爆炸式增长。由于这些供应商依赖上游发行版进行修补和重建，因此披露和修复之间存在不可避免的滞后。这使得依赖 Debian 或 Alpine 等发行版的供应商陷入困境：他们继承了并非由他们创建且无法轻易控制的漏洞。”
当非 DSA 不够时
更深入地讲，Katzen 指出，由于 DHI 直接构建在 Debian 之上，其镜像继承了 Debian 的软件包集、安全态势和发布时间表。实际上，DHI 的许多漏洞可利用性交换 (VEX) 条目——机器可读文档，告知扫描器某个 CVE 是否实际影响给定镜像——有效地反映了 Debian 自身安全公告 (DSA) 的分类状态。
Debian 的安全团队在其追踪器中使用“no‑DSA”标志来标记不值得立即发布 DSA 和非周期性重建的问题。做出这些决定通常是因为安全问题被认为是轻微的，或者太难以利用，不值得立即修复。Debian DSA 文档明确将“no‑DSA”视为一种咨询优先级机制。确切地说，“此类问题通常不会一直未修复，但仍可以通过点更新或通过将修复与未来更严重问题的更新捆绑在一起进行修复。”
这对 Debian 来说可能足够好，但 Katzen 认为这对你来说可能不够好。他说，“许多被标记为 no-DSA 的 CVE 是完全不可利用的，并且以这种方式处理是合理的。”然而，将该分类标志视为软件包“未受影响”的证据，混淆了风险优先级与漏洞不存在，并可能误导依赖 VEX 扫描器的下游消费者。
当上游维护者已经合并了修复，但这些修复尚未进入 Debian，因此也未进入 DHI 时，这是一个重要问题。具体来说，Katzen 指出了三个在 Debian 中尚未被发现和修复的重大 CVE。
- CVE‑2026‑0861: glibc 中 memalign 系列的这个缺陷可能导致整数溢出和堆损坏，在国家漏洞数据库 (NVD) 中被评为 HIGH (8.4)。Debian 目前列出多个版本（包括 bookworm 和 trixie）易受攻击，修复仅存在于较新的“forky”系列中。尽管如此，DHI 与 Debian “no‑DSA”分类相关的 VEX 条目将受影响的镜像标记为“未受影响”，理由是易受攻击的代码无法被攻击者控制，同时继续发布未打补丁的 Debian glibc。由于许多 DHI 镜像，例如语言运行时和数据库，都依赖于 glibc，因此该状态有效地从扫描器输出中抑制了一个真实的、未打补丁的 CVE。
- CVE‑2026‑0915: 另一个可能导致内存内容泄露的 glibc 问题也被 NVD 评为 HIGH (7.5)，同样在 Debian 中标记为“no‑DSA”，表示决定将修复推迟到常规发布。同样，DHI 的 VEX 数据遵循 Debian 的优先级，将镜像标记为“未受影响”，尽管底层 Debian 软件包版本仍然列为易受攻击，并且没有应用任何下游补丁。在 Debian 重建或下游供应商挑选上游提交之前，嵌入该 glibc 构建的镜像在技术上是受影响的，扫描器应该反映这种状态。
- CVE‑2025‑6141 (ncurses): 这个 ncurses 错误在处理 termcap 条目时允许堆栈缓冲区溢出，需要本地访问，并被评为低严重性。该错误已于 2025 年 3 月在上游 ncurses 6.5‑20250329 中修复。数月后，Debian 仍未为所有相关版本发布打补丁的软件包，并将该 CVE 标记为“no‑DSA”，将修复推迟到其标准周期。DHI 针对至少一个基于 Debian 的镜像的 VEX 历史记录最初将该问题记录为“正在调查中”同时“等待上游修复”，然后后来根据 Debian no‑DSA 标签将状态翻转为“未受影响”——同样没有证据表明已将修复的 ncurses 构建集成到镜像中。
因此，Katzen 表示，“漏洞存在于 DHI 中，并且上游有可用的修复，但该修复尚未被引入 DHI。该 CVE 被 Docker Scout 和通过在其他扫描器中使用 VEX 文档自动从扫描中抑制。”
强化镜像足够吗？
从 Chainguard 的角度来看，这意味着在通用社区发行版之上构建“强化”镜像的供应商可能会发现自己陷入透明度与达到接近零 CVE 数量之间的两难境地。在 Debian 之前挑选修复会迫使 Docker 和其他使用类似节奏的供应商维护一个事实上的分支，这会带来所有长期维护和回归的麻烦。
Katzen 声称这会将压力转移给客户及其工具。随着 VEX 更深入地集成到扫描器和合规性工作流中，过度激进地抑制“不便的”CVE 会破坏标准化、机器可读的可利用性数据的核心承诺。
然后，他当然赞扬了 Chainguard 的模型，在该模型中，CVE 分类和补救可以直接从源代码到镜像进行，而无需等待上游发行版的时间表。这种端到端控制支撑着其包含 2000 多个最小镜像的目录，这些镜像不断重建以保持零 CVE 状态，同时保留供应链可见性、SBOM 和明确的 CVE 处理。
另一方面，你可能会争辩说，正如 Debian 维护者所说，有些 CVE 实际上并没有它们看起来那么严重。因此，你可以等待它们被修复。
但 CVE 到底有多重要？
但这场辩论也引出了一个更基本的问题：CVE 系统本身就是问题吗？
一些安全组织和公司，例如 云安全联盟 和 SecOps Solution，认为 CVE 与环境无关。他们说“存在一个漏洞”，但他们没有说它是否对你的部署是危险的。
最重要的是，根据一项研究，多达三分之一的 CVE 是无效的。安全业务 Codific 的联合创始人兼首席执行官 Aram Hovsepyan 博士指出，“对于安全专业人士来说，CVE 条目也是简历中的一个宝贵补充。这明确促使生成更多 CVE，即使其影响可能值得怀疑。 此外，该系统可以被操纵，为了生成 CVE 而创建它并不特别困难。”雪上加霜的是，使用 AI 创建虚假安全报告太容易了，cURL 创建者 Daniel Stenberg 最近指出了这一点。
换句话说，正如 Hovsepyan 评论的，“CVE 并非一无是处。它们是宝贵的输入。但它们绝不应该成为整个应用程序安全战略的基础。我们需要从对风险的共同理解开始，以威胁建模和情境分类为基础。漏洞仪表板可以提供帮助，但仅限于通过科学视角进行解释时。”
简而言之，两种方法都有其可取之处，仅凭 CVE 数量不足以确定你的镜像完全安全。零数量，但你不能假设零意味着安全。没有人说安全是容易的。这些新镜像有所帮助，但它们并不完美。
