Distroless 的安全缺口：为何自下而上的容器是 OCI 镜像的下一次演进
内容提要
容器安全存在两难：完整镜像攻击面大，distroless精简镜像常丢失包元数据，导致扫描器漏报、合规风险高。文章提出自下而上的构建方法：用Chisel将可信Linux包切分为所需片段并保留元数据，用Rockcraft以声明式YAML构建OCI镜像，运行时用Pebble作为PID 1回收僵尸进程，从而兼顾最小化、可审计与运行稳定。
延伸解读
精简镜像的审计盲区
文章指出，distroless 镜像在激进裁剪时常常丢失包元数据，导致 Trivy 等扫描器无法准确识别镜像内容，甚至出现漏报。这意味着即使镜像体积很小，安全团队也难以用扫描结果证明其安全性，从而带来合规风险。这种“看不见”的问题在 Day 2 运维中尤为突出，因为持续监控和漏洞响应都依赖完整的元数据。
自下而上构建如何保留元数据
文章提出的自下而上方法从空镜像开始，用 Chisel 将可信 Linux 包切分为所需片段，并保留这些片段的元数据。随后用 Rockcraft 以声明式 YAML 描述应用需求，自动拉取切片并构建 OCI 镜像。由于元数据未被剥离，扫描器可以正常工作，从而在最小化的同时保持可审计性。
运行时稳定性的关键：Pebble
精简容器常移除进程管理器，但应用若产生子进程，僵尸进程会累积并最终导致容器崩溃。文章建议使用 Pebble 作为 PID 1 入口，负责回收僵尸进程，从而在不重新引入臃肿组件的前提下维持运行稳定。这解决了最小化镜像在规模化部署中的运维隐患。
从脚本式构建到声明式状态
传统 Dockerfile 采用命令式构建，层缓存容易造成臃肿和脆弱。自下而上方法改用 Rockcraft 的声明式 YAML，开发者只需描述应用状态和所需切片，工具负责获取源码、编译并输出标准 OCI 镜像。这种转变降低了构建复杂度，也让镜像内容更可预测、更易维护。
Q&A
为什么精简的 distroless 容器反而会导致安全扫描漏报？
因为 distroless 镜像在裁剪过程中常常丢失包元数据（即已安装软件的清单），导致扫描器（如 Trivy）无法获取完整信息，从而出现漏报，甚至无法检测到实际存在的漏洞。
自下而上构建容器镜像的三个步骤是什么？
三个步骤是：切片（Slice）、构建（Build）和运行（Run）。切片用 Chisel 将可信 Linux 包切分为所需片段并保留元数据；构建用 Rockcraft 以声明式 YAML 定义并生成 OCI 镜像；运行时用 Pebble 作为 PID 1 管理进程并回收僵尸进程。
Chisel 和 Rockcraft 在自下而上构建中分别起什么作用？
Chisel 负责将标准 Linux 包（如 Ubuntu 归档）切分成细粒度的片段，只保留应用需要的部分，并保留元数据以维持供应链可信和扫描可用；Rockcraft 则通过声明式 YAML 文件描述应用需求，自动拉取源码和指定包片段，编译并输出符合 OCI 标准的容器镜像。
为什么最小化容器需要 Pebble 这样的进程管理器？
因为容器内应用产生的子进程死亡后会变成僵尸进程，占用系统资源。没有 init 系统回收僵尸进程，僵尸会累积导致容器崩溃。Pebble 作为轻量级服务管理器以 PID 1 运行，负责回收僵尸进程，从而在不增加镜像体积的前提下保持容器稳定。
自下而上构建相比传统 Dockerfile 构建有什么优势？
传统 Dockerfile 是命令式构建，命令顺序重要且层缓存易导致镜像臃肿脆弱；自下而上构建采用声明式方法，开发者用 YAML 描述应用状态，工具自动完成构建，将体验从“编写构建脚本”转变为“声明状态”，同时保留元数据，兼顾最小化与可审计性。
企业采用自下而上容器方案能解决哪些合规问题？
该方案能保留完整的包元数据，使安全扫描器正常工作，从而准确检测漏洞，避免因无法扫描而导致的合规风险。企业可以构建出既最小化又可审计、运行稳定的容器镜像，不再需要在安全可见性和容器精简之间做零和取舍。
