CNCF 云原生构建标准化怎么验收：Buildpacks 的 OCI 镜像与供应链边界

先说结论：Buildpacks 毕业说明项目在生产采用、治理和安全实践上达到更高成熟度，但它不会替平台团队自动完成供应链验收。真正要交付的证据至少有四类：构建产物是可部署的 OCI 镜像，应用与依赖形成可解释的层，SBOM 能从镜像取回，基础运行层更新时可以明确判断是否适合 rebase。

这四个证据面分别回答“产出了什么”“谁能复用”“里面有什么”和“换底座会不会改变应用”。下面按一次 CI 验收来组织。

先把毕业信息拆成四个工程对象

CNCF 公告提到，Cloud Native Buildpacks 可从源码生成 OCI-compliant container images，并自动完成语言检测、依赖安装和镜像分层。平台团队不要把这句话当成安全承诺，而要把它拆成可检查对象：

• Builder 与生命周期：记录 builder 镜像、生命周期版本和 Platform API；生命周期会经历 analyze、detect、restore、build、export 等阶段。
• 应用镜像：确认 registry 中的产物、架构、入口进程和运行时基础层。
• 内容证据：记录每个 buildpack 提供的依赖层和 SBOM 文件，建立“组件—提供者—镜像层”的关系。
• 更新边界：应用源码、依赖或 buildpack 变化走完整构建；只更换兼容的运行时基础镜像时，才考虑 rebase。

固定构建输入，再检查 OCI 镜像和分层

验收时先固定输入，不要只保存一条“构建成功”的日志。至少记录源码提交、builder 引用、平台工具版本、目标镜像名称和构建时间。可以把最小检查动作写入 CI：

pack builder inspect 
pack inspect 
docker image inspect  --format '{{json .RootFS.Layers}}'

检查结果重点看三件事：镜像是否按 OCI 兼容路径导出；启动所需文件是否位于 launch 层而不是只存在于 build 阶段；源码未变化时，依赖层是否能被复用。层数少不代表一定更好，关键是边界稳定、责任清楚，并且基础层、应用层与依赖层能分别定位变更。

用 SBOM 证明“可见”，别把扫描分数当成清单

Buildpacks 文档说明，buildpack 可以为它提供的依赖填充 SBOM，并支持 CycloneDX、Syft 和 SPDX 格式。把清单拉回本地，最小动作是：

pack sbom download  --remote
find layers/sbom -type f -maxdepth 5 | sort

验收表要记下格式、文件路径、生成者和对应层。文档中的目录示例位于 layers/sbom，不同 buildpack 可能分别提供 launch 或 helper 下的清单。若只有扫描器汇总分数，没有可下载的原始 SBOM，就只能判定“扫描完成”，不能判定“供应链透明”。同时，SBOM 也不等于无漏洞：它只是让后续漏洞匹配、许可证检查和升级责任有可追踪输入。

用 rebase 划清基础层更新边界

CNB 的 rebaser 会把应用层放到新版本的 runtime base image 之上。它适合处理底层操作系统或运行时基础镜像的兼容更新，不适合掩盖应用依赖变化。平台可以把规则写成：

基础层变更 + 应用层兼容：rebase 后启动检查
应用源码/依赖/buildpack 变更：重新 pack build
rebase 返回 API 不兼容：停止发布，升级或重建 builder

成功标准不要只看命令返回 0，还要检查容器启动、健康探针、入口进程和镜像元数据。rebase 失败时，官方文档列出了 Platform API 或 Buildpack API 不兼容等边界；这类失败应回到完整构建或升级构建链路，而不是强行替换底层。

摘要：毕业是成熟度信号，不是免检通行证；镜像验收要固定 builder 和层边界；SBOM 要能取回原始文件；rebase 只覆盖兼容的 runtime 基础层更新。

相关问题

Buildpacks 生成 OCI 镜像后还需要扫描吗？需要。OCI 解决分发格式一致性，SBOM 解决组件可见性，漏洞扫描与修复仍是平台自己的流程。

为什么有 SBOM 仍不能直接 rebase？SBOM 只能说明内容，不能证明新 runtime 与应用层、入口进程和 API 兼容；rebase 仍需做启动和健康检查。

应用依赖升级应该选 rebase 还是重建？依赖或 buildpack 改变应重新构建；仅运行时基础层变化且兼容时，才使用 rebase 快速更新。