零CVE容器镜像的实现路径与安全陷阱：从Debian到DriftlessAF

我们都希望容器镜像中没有常见漏洞和暴露（CVE），创建此类“零CVE”镜像本身已成为一门生意。最初只是一种激进的“左移”安全策略，现在已逐渐成为容器化工作负载的基本期望。但究竟什么才是创建这些安全镜像的最佳方式呢？这场追逐，远比看起来要复杂。

目前，市场上有不同的实现路径。其中，Chainguard 作为领先的零CVE容器镜像供应商之一，采用了名为“DriftlessAF”的开源方法。其核心在于，当检测到上游代码变更时，直接从源代码重建容器和库，而不是等待传统发行版的更新。每次构建都是一个可复现的、包含完整软件物料清单和签名的产出，旨在实现默认的安全状态。

而其他构建者，例如 Docker 及其“Docker强化镜像”（DHI），则采取了不同的策略。它们深度绑定 Alpine Linux 和 Debian 等上游发行版，在这些发行版的基础上提供减少的攻击面、非root默认设置等安全强化特性。

传统发行版模型的结构性延迟

Chainguard的产品营销经理 Sam Katzen 指出，问题的根源在于上游发行版维护者漫长的依赖链和相对缓慢的发布周期，这使其难以跟上当今漏洞报告的爆炸式增长。由于像 DHI 这样的供应商依赖上游发行版进行修补和重建，从漏洞披露到最终修复之间必然存在一个滞后期。

“这使得依赖 Debian 或 Alpine 等发行版的供应商陷入困境：他们继承了并非由他们创建且无法轻易控制的漏洞。” Katzen 如是说。

当“no-DSA”分类成为误导

以构建在 Debian 之上的 Docker DHI 为例，其镜像的安全态势与 Debian 的发布时间表紧密捆绑。DHI 镜像中的许多漏洞可利用性交换条目，实际上只是反映了 Debian 自身安全公告（DSA）的分类状态。

Debian 安全团队会使用“no-DSA”标志来标记那些他们认为不值得立即发布专门安全公告的问题。这通常是因为安全问题被认为是轻微的，或者利用起来过于困难。Debian 官方文档明确表示，“no-DSA”是一种优先级管理机制，此类问题通常会在未来的常规更新中被修复。

然而，Katzen 认为，将“no-DSA”分类简单地等同于“未受影响”可能会产生误导。这混淆了“风险优先级低”和“漏洞不存在”这两个概念，并可能让依赖 VEX 文档进行自动化扫描的下游用户产生错误的安全感。

当上游项目（如 glibc、ncurses）已经合并了修复，但这些修复尚未被 Debian 采纳并发布更新时，问题就变得尤为突出。此时，依赖 Debian 的强化镜像在技术上仍然包含漏洞，但扫描器可能因为 VEX 文档的标记而将其忽略。

Katzen 列举了几个具体案例：

• CVE-2026-0861 (glibc)：此高危漏洞可导致堆损坏。尽管上游已有修复，但 Debian 的多个版本（包括 bookworm）仍将其标记为“no-DSA”且未修复。DHI 的 VEX 数据遵循此分类，将相关镜像标记为“未受影响”，尽管底层软件包实际上并未打补丁。
• CVE-2026-0915 (glibc)：另一个glibc高危漏洞，情况类似，Debian 决定将修复推迟到常规发布周期，标记为“no-DSA”。DHI 镜像的状态也随之被标记为“未受影响”。
• CVE-2025-6141 (ncurses)：该漏洞已于2025年3月在上游修复，但数月后 Debian 仍未为所有相关版本发布补丁，同样标记为“no-DSA”。DHI 的 VEX 记录显示，其状态从“正在调查”最终变更为“未受影响”，但并无证据表明修复已被集成到镜像中。

“这意味着漏洞存在于 DHI 中，上游有可用修复，但修复未被引入。该 CVE 被 Docker Scout 或其他扫描器通过 VEX 文档自动抑制了。” Katzen 总结道。

强化镜像的透明度困境

从 Chainguard 的视角看，在传统发行版之上构建“强化”镜像的供应商，可能会陷入一个两难境地：是在上游修复之前自行挑选补丁，还是等待上游的发布节奏？前者意味着需要维护一个事实上的分支，带来额外的维护负担和回归风险；后者则意味着不得不接受一段时间的漏洞暴露，或者通过 VEX 文档来“隐藏”它们。

Katzen 认为，这最终将压力转嫁给了用户及其安全工具。如果 VEX 数据被用于过度激进地抑制那些“不方便”的 CVE，那么其作为标准化、机器可读风险数据的核心承诺就被破坏了。

相比之下，Chainguard 的模型主张通过从源代码直接构建来获得端到端的控制权，从而能够独立于上游发行版的时间表来进行 CVE 分类和修复。这种持续重建的流程，是其宣称能保持超过2000个最小化镜像处于零 CVE 状态的基础。

当然，也有人持不同观点。Debian 维护者的立场是，许多 CVE 的实际风险被高估了，等待其在下个常规周期中被修复是完全合理的。这对于许多应用场景来说或许足够，但对于那些对安全态势有极高要求的环境，则可能构成挑战。

更深层的诘问：CVE 系统本身是问题吗？

这场关于零 CVE 镜像构建路径的争论，引出了一个更根本的问题：我们如此追逐的 CVE 系统，它本身是完美无缺的吗？

一些安全专家和组织，如云安全联盟，指出 CVE 本身是“与环境无关”的。它只宣告“存在一个漏洞”，但并未说明这个漏洞在你的具体部署环境中是否真的构成危险。换句话说，一个高危 CVE 在某个完全隔离、无法被触发的容器中，其实际风险可能为零。

更令人担忧的是，有研究指出，多达三分之一的 CVE 可能是无效的。安全公司 Codific 的 CEO Aram Hovsepyan 博士指出，对于安全研究人员而言，报告 CVE 是简历上的宝贵加分项，这“明确激励了生成更多 CVE，即使其实际影响值得怀疑”。此外，该系统也存在被操纵的可能。

简而言之，将 CVE 数量作为安全的唯一度量标准是危险的。零 CVE 数量并不意味着绝对安全，正如存在 CVE 也不一定代表实际风险。一个科学的风险评估策略，需要结合威胁建模和对具体环境的理解。新的零 CVE 镜像构建方法，例如直接从源代码持续重建的 DevOps 实践，为我们提供了更优的工具，但它们并非万能灵药。理解其背后的原理和潜在的妥协，对于构建真正安全的 容器化 应用至关重要。

这场追逐仍在继续，而保持清醒的风险认知，或许比单纯追求那个“零”的数字更为重要。欢迎在 云栈社区 分享你对容器镜像安全与供应链治理的看法。