首页 > 科技周边 > 业界新闻

OCI镜像供应链元数据在多环境发布中的保留方式

来源：17golang原创

时间：2026-09-25 14:50:02 153浏览收藏

多环境发布中，真正容易丢失的不是镜像层，而是镜像摘要之外的供应链证据：构建来源、SBOM、签名和扫描结果。OCI 1.1 已经提供了 subject、artifactType 与 Referrers API，让这些对象可以按镜像摘要建立关系。实用做法是把稳定身份写入镜像本身，再把可独立更新的证明作为 referrer，一起从构建仓库晋级到测试、预发布和生产仓库。

要点速览

标签和 manifest 注解适合放版本、来源地址等短元数据，但不能替代签名或 SBOM。
跨环境复制要以 digest 为主键，并递归复制 referrer，不能只复制一个 tag。
目标仓库发现不到证明时先阻断晋级，确认 API 或 tag 兼容策略后再放行。

OCI元数据要分成两层保存

OCI 镜像配置中的 labels 和 manifest 的 annotations 都能承载任意键值，适合记录构建提交、组件名称、来源仓库和生成时间。这一层会参与镜像内容的摘要计算，修改它就会得到新的镜像摘要，因此不能在生产仓库里临时补写“生产环境”标签。

构建证明、SBOM、签名和漏洞扫描结果更适合作为独立 artifact 挂在目标镜像上。它们可以按自己的生命周期更新，但 subject 仍然指向同一个镜像 manifest。这里的关键不是“把 JSON 放进镜像”，而是让消费方能从摘要反查到完整证据链。

OCI镜像摘要与标签注解、构建来源、SBOM、签名和扫描结果的关系说明图 — 图1：OCI元数据分层说明图，展示镜像摘要与供应链证明的绑定关系。

先固定摘要，再生成和绑定证明

流水线应在构建完成后解析最终 digest，再以这个 digest 生成签名、SBOM 和 provenance。不要先给 tag 签名，随后又因为重打标签或修改注解产生另一个 digest。最小的晋级命令可以这样组织：

# 先固定构建产物的摘要，避免 tag 在流水线中漂移
export IMAGE_SRC="build.example.invalid/team/app@sha256:..."
export IMAGE_DST="test.example.invalid/team/app:release-2026-09"

# -r 表示递归复制镜像及其 referrer，目标仓库仍需具备相应兼容能力
oras cp -r "$IMAGE_SRC" "$IMAGE_DST"

# 以目标仓库中的 digest 发现附着证明，再决定是否允许继续晋级
oras discover "$IMAGE_DST"

示例中的域名仅用于说明命令结构。生产流水线应从构建系统输出中注入真实仓库地址，并把源摘要、目标摘要、证明类型和复制结果作为发布记录。ORAS 文档同时提供 Referrers API 和 tag 方案，说明不同仓库之间不能默认拥有完全相同的发现能力。

跨仓库复制必须把证据一起晋级

只复制镜像 manifest，通常能让容器启动，却可能让准入策略找不到 provenance 或签名。更稳妥的门禁是：目标仓库复制结束后，按目标镜像摘要执行发现；至少找到约定的 provenance、SBOM 和签名类型，才允许部署控制器读取该 tag。

对象	绑定位置	晋级时的判断
版本与来源	labels/annotations	随镜像摘要一起变化，禁止生产临时改写
构建来源、SBOM	subject referrer	按摘要发现，检查类型和来源
签名	subject referrer	校验签名主体与目标摘要一致
扫描结果	subject referrer	按策略判断过期、缺失或不合格

OCI镜像从构建仓库晋级到测试预发布生产并保留附着证据的说明图 — 图2：多环境晋级说明图，展示镜像与附着证据的同步复制和失败门禁。

仓库兼容性要成为发布门禁

OCI Referrers API 的路径是 /v2//referrers/。如果目标仓库不支持该发现方式，工具可能退回到基于 tag 的引用方案；两者在清理策略、权限和可见性上并不等价。团队应维护一张仓库能力表，记录是否支持 OCI index、subject、Referrers API、签名对象和递归复制。

实际发布时不要把“复制命令返回成功”当成元数据完整。复制后至少做一次发现并保存摘要关系；发现为空、证明类型缺少或目标摘要改变，都应让流水线停在兼容门禁，修复复制参数或仓库能力后再重试。