代码热风险 – 软件供应链视角下，容器交付前要先“冷却”

by Canonical on 8 July 2026

已遭遇的安全漏洞，与即将到来的威胁

2025 年 9 月，npm 软件仓库中包括 chalk 和 debug 在内的数十个热门 JavaScript 软件包遭入侵。这些软件包应用极为广泛，几乎无处不在：前端应用、后端微服务以及 CI 工具中均有使用。开发人员并无任何失误操作，他们只是执行了一贯使用的命令：npm install chalk。但恶意软件却悄无声息地侵入了。

这并非操作系统中的漏洞。也不是某台笔记本电脑上的病毒。这是一次供应链攻击：攻击者在开发者构建软件所使用的组件中植入了恶意代码。手段并不复杂，仅仅是一名开发者遭到钓鱼攻击、一次恶意发布，数百万下游用户便因看似是合法更新而将恶意代码引入系统。

而这确实是一次合法的更新。发布者并非有意植入恶意软件，也对此毫不知情。

这一切就发生在 npm 平台上。试想一下，若同类攻击手段在应用程序运行之前，就瞄准了容器所依赖的系统库，例如 libcurl、zlib 或 openssl 等组件，后果将不堪设想。这将危及您所运行或构建的一切应用程序的底层基础。

这就是软件供应链安全中的“温度问题”。整个行业正在交付仍处于“过热”状态、难以安全管控的代码。

构建容器的两种理念

越来越多的现代软件运行在容器中。但业内情况差异巨大：容器内的代码究竟是经过充分验证趋于稳定，还是直接取自上游未经安全检验的版本，两者完全不同。

夜间重建方法

一种日渐流行的思路如下：从上游获取所有软件包的最新版本，每晚从零开始重建容器镜像，通过工具对其进行签名、校验，并最小化镜像体积。从理论上看，这似乎无懈可击。若源文件干净，便可快速交付安全可靠的代码。如果上游修复了某个漏洞，您在下一次夜间重建中就能获取该补丁。

但如果源文件被植入恶意代码呢？

您就相当于构建并签名了一个极度精简、可全程追溯、企业级别的恶意软件分发载体。更不用说还具备可复现性。后门程序并不会在意您构建的这套完善基础设施。

您这是在直接把代码从上游源头直接推送上线。没有任何冷却缓冲环节。没有任何静置观察期。无人检测其安全状态。

审慎更新方法

Ubuntu 采用了另一种思路。稳定版每两年发布一次。软件包版本保持固定，安全修复通过精准向后移植实现，即在不引入新功能或未经审核的上游变更的前提下修补漏洞。更新均为审慎推送，且附带相关说明。

这种方式并不花哨，却稳健、审慎且可预测。

不会每日夜间重建，换来的是稳定性与可靠性，因为这些代码已经经过充分验证。代码已经经过充分沉淀。它经过了时间的检验、严格的审查，以及依赖其稳定运行的生产负载的实际验证。

没有任何一种供应链安全方案是万无一失的。但如果有人试图在 libcurl 中植入后门呢？基于 Ubuntu 的容器很可能不会拉取该更新，因为发布计划中并无此需求。当其他团队还在使用刚从上游同步过来、仍存在风险的最新代码时，审慎更新模式则安然不受影响。

这个容器可能运行着 2022 年版的 curl，这并非 Ubuntu 落后，而是维护者完全清楚该版本的行为逻辑。更重要的是，他们清楚它不会做什么。它早已经过充分沉淀。经过沉淀的代码才是可预测的代码。

谁会先把后门推送上线？

试想这样一种场景：一个恶意补丁被合入上游代码库。它隐蔽、带有签名，且通过了 CI 检测。因此它看起来毫无问题并向全球发布，而此时代码仍处于高风险未验证状态。

夜间重建管道会自动拉取最新的上游代码。镜像完成构建与扫描，依旧显示零 CVE，因为这是全新代码。它带有签名、体积精简，却极具恶意。直接投入使用，未经任何质疑。

而像 Ubuntu 这样采用审慎更新模式的发行版呢？固定使用的版本虽较旧，但可预测且稳定。Ubuntu 维护者会让代码充分沉淀，恶意问题在上游阶段就已暴露，不会进入正式版本。

零 CVE 的问题

安全扫描工具热衷于标记 CVE。发现漏洞？您处于危险中。未发现漏洞？一切安全。

但现实情况更为复杂：旧代码漏洞更多，是因为被研究得更久；而新代码零漏洞，只是因为尚未被深入检测。对于新代码而言，零漏洞并不意味着安全，只意味着未被检测。这意味着代码太过新颖，尚无人知晓其内部隐患。

如果您每日夜间从上游重新构建，就是在代码尚未经过仔细审查时就将其引入。您是先进行签名，之后再去核查问题。这就好比饭菜还没放凉就直接入口。

真正的安全是慢慢积累而来的

安全不只是一份扫描结果。安全是一种准则，而准则需要审慎的克制。换言之，在采用上游代码前保持谨慎，对已稳定运行的内容恪守变更准则，对授予信任持怀疑态度。

Ubuntu 的策略假定上游代码可能出错、可能仓促发布，甚至可能已被入侵。因此，Ubuntu 维护人员会进行精心筛选与管控。他们先进行检验，之后再交付使用。他们会让代码在发布前经过充分沉淀，并且绝不会交付任何未经亲自检验的内容。

夜间重建模式押注于极简、透明与新颖，直到新颖变成一种隐患。直到“刚出炉”变成“烫到不可信”。

当新颖变成一种隐患

让容器保持“纯净”的每天夜间从上游重建机制，恰恰是引入后门的同一途径。而让容器看似固化的向后移植软件包，正是封堵后门的关键。

一家厨房一收到所有食材就立刻下锅烹饪。另一家则会检查、等待，只使用已知安全的食材。

当下一次供应链攻击入侵核心系统库时，值得一问：这两种方案中，哪一种会让您直接用上恶意软件，哪一种能帮您彻底避开风险？

重建不等于验证

您可以重建每个软件包，扫描每一层镜像，并为每个制品签名。但如果您无法掌控代码的设计意图，不清楚其来源、变更原因，或是谁在代码差异中偷偷植入了内容，您不过是用更优质的基础设施、更快地重建了他人的恶意软件。

重建只是复制。只有在您确知要复制的内容时，它才有意义。如果您忠实地重建已被入侵的代码，您并未验证任何东西。您只是在帮攻击者完成他们的 CI 工作。您只是在加热别人下的毒，还称之为新鲜饭菜。

另一种 CVE

当所有人都在追求“零已知 CVE”时，我们却忽略了更广泛的风险。我们不再追问“这个镜像是否存在漏洞？”我们应当开始追问：“这个镜像是否过于轻信？”

CVE 数量是一个滞后指标。攻击发生在扫描工具发出警报之前。真正的漏洞并非软件包本身，而是背后的理念。这种理念假定上游代码一经发布就可安全使用。

结论

这并非针对任何单个厂商或项目。这关乎整个行业如何看待信任与时效性。

审慎更新模式假定上游来源并非绝对可信，因此采取谨慎推进的策略。它让代码经过沉淀期。夜间重建模式假定上游来源可靠且必须保持最新，因此持续更新。它直接推送最新内容。

有时您流程中最安全的组件，正是那个已经十八个月没动过的组件。并非因为被遗忘，而是经过了时间沉淀，获得了留存的资格。

在软件供应链安全中，最好的代码未必是最新的。而是经过充分沉淀、问题得以暴露的代码。所以，让代码沉淀下来。这样反而更稳妥可靠。