61%镜像含漏洞依赖 Buildpacks夺走开发者补丁控制权

容器镜像的补丁管理，正在从“每个开发者自己写 Dockerfile”转向“平台团队统一控制”。这场争论的焦点，已经从构建方式演变为安全责任归属。

问题的根源在于基础镜像的声明位置。在 Dockerfile 模式下，每个存储库都包含一条FROM语句，应用团队自行决定基础镜像的选择和补丁发布频率。要推广一个打过补丁的基础镜像，意味着需要修改每一个服务。虽然 Renovate 和 Dependabot 能自动处理这类机械操作，但更新 FROM 语句仍然会触发一次完整构建、占用 CI 队列槽位、执行测试并重新部署——这些操作还要乘以服务数量。

Buildpacks 颠覆了这一模式。其构建器（builder）是一个 OCI 镜像，打包了一组按顺序排列的 Buildpacks、生命周期以及构建时基础镜像，同时在元数据中关联一个独立的运行时基础镜像（即“运行镜像”）。后续构建时选择新的运行镜像，现有兼容应用镜像无需重建应用程序层即可执行 Rebase 操作。Cloud Native Buildpacks 项目于 2026 年 7 月 17 日从 CNCF 正式毕业，其核心理念是“将容器构建最佳实践的知识集中于专业团队，而非让组织内的应用开发者各自维护自己的 Dockerfile”。

Rebase 机制是效率的关键。它将操作系统层的摘要值替换为新运行镜像的摘要值，完全绕过重建周期。Joe Kutner 在 2023 年 12 月为 CNCF TAG 环境可持续性小组撰文时指出，这本质上只是对一个 JSON 文件的编辑，仅需几毫秒即可完成，计算资源消耗极低，无需重建、访问源代码或进入 CI 队列。但要注意，Rebase 仅替换兼容的运行镜像层；如果应用程序依赖项中存在漏洞，仍然需要重新构建。

供应商正在围绕构建器安全性展开竞争。BellSoft 于 2026 年 7 月 21 日推出了一款基于其 Alpaquita Linux 加固镜像构建的加强版 Paketo 构建器，同时取代构建栈和运行栈：内置精简软件包集、默认非 root 权限、签名及 SBOM 数据。根据 BellSoft 自己的描述，补丁是通过“下个构建版本”而非 rebase 方式推送至应用程序的，补丁镜像通常会在漏洞披露后“24 小时内”发布。其标准版（Standard tier）承诺高危漏洞 7 天内完成修复，其余漏洞修复 SLA 为 14 天，免费社区版（Community tier）未列明相关条款。

其他供应商则通过提供低 CVE 或零 CVE 镜像目录展开竞争，市场正趋于商品化。Docker 已于 2025 年 12 月将其全部加固镜像目录在 Apache 2.0 许可证下免费开放，仅保留具有 SLA 保障的付费修复服务。Docker 的 Select 版承诺在七天内修复高危 CVE，与 BellSoft 的 Standard 版标准一致。当镜像免费且服务水平协议趋同，差异化竞争的焦点转向交付能力和责任追溯机制——这正是将构建器而非镜像视为控制点的理由。

数据揭示了 Dockerfile 模式的真实风险。在 Spring I/O 2026 大会上，BellSoft 对 250 名 Spring 开发者、技术负责人和架构师进行的调查发现，64% 的受访者并未意识到他们的 Dockerfile 存在安全风险。更广泛地看，一项针对 6292 个 Docker 镜像的跨标签研究（ICSME 2025）发现，在被检查的每个标签中，近 61% 的存储库都包含存在漏洞的应用程序依赖项。这属于应用层的问题，rebase 无法解决，但它们反映的习惯与导致基础镜像未打补丁的习惯是一样的。

Buildpacks 并非万能方案。它牺牲了手动编写 Dockerfile 时按步骤控制的优势，对于需要自定义操作系统软件包，或使用 Buildpacks 未涵盖的语言生态系统的工作负载，会带来不便。镜像扩展（extension）在一定程度上弥补了这一差距：它允许平台团队在标准构建过程中生成 build.Dockerfile 和 run.Dockerfile 步骤，但扩展运行镜像可能会损害 rebase 能力。团队重新获得了 Dockerfile 式的控制权，却牺牲了快速打补丁的路径。

Buildpacks 还可能导致冷构建速度变慢、镜像体积增大，并将信任高度集中于平台的构建器上。本质上，这是在控制权与风险影响范围之间做出的抉择：治理权转移到了负责维护、签名和发布构建器的一方。随着《欧盟网络弹性法案》等法规的出台，这种压力只会与日俱增。