Docker Buildx 内置来源策略解决什么供应链问题

Docker Buildx 的内置来源策略，解决的是“构建时拿到的受管镜像标签是否仍然对应可信发布身份”这一层供应链问题。启用 BUILDX_DEFAULT_POLICY=1 后，Buildx 会对 Docker 管理的镜像和 Dockerfile 前端做默认来源校验；它能减少标签被替换、上游发布身份失配时的盲目信任，但不会自动完成漏洞扫描、依赖审计或所有外部仓库的签名验证。

官方参考：https://github.com/docker/buildx/blob/master/docs/reference/buildx.md

内置来源策略到底保护什么

供应链风险经常不是“镜像文件突然不可用”，而是同一个可读标签在不同时间指向了不同内容，或者构建过程拉取了一个不在团队预期中的 Dockerfile 前端。Buildx 的内置策略把问题收窄到来源身份：对 Docker 管理的镜像，带签名的标签要通过发布身份校验；带摘要的引用则按摘要本身作为固定内容标识。

这个边界很重要。它证明的是“当前输入是否符合这套内置来源规则”，不是“镜像没有 CVE”，也不是“镜像内的每个依赖都来自批准清单”。第三方仓库、HTTP 下载和 Git 上下文等输入，应该交给显式构建策略或团队自己的供应链规则处理。

用一个环境开关启用默认策略

在支持该能力的 Buildx 环境中，可以把开关放入 CI 任务的环境变量，再执行原来的构建命令。下面的示例只展示接入方式，镜像名和标签应替换为项目实际输入：

# 让当前 Buildx 进程启用内置来源策略
export BUILDX_DEFAULT_POLICY=1

# 保持原有构建入口，策略会在解析构建输入时参与判断
docker buildx build \
  --tag registry.example.com/team/app:release \
  --push .

# 用版本命令确认当前调用的是预期的 Buildx 插件
docker buildx version

建议把环境变量配置在 CI 的受控 job 中，而不是只在某位开发者的本机 shell 中设置。这样同一条构建流水线才会持续使用相同的安全默认值。若构建失败，先记录被拒绝的输入和 Buildx 版本，再判断是来源身份不匹配、策略范围不包含该仓库，还是需要补充显式策略。

按标签、摘要和仓库类型判断结果

不要只看“构建是否成功”来判断策略效果。可以按下面的方式读结果：

因此，带摘要并不等于完成全部供应链验证，签名标签也不等于内容安全扫描。表格中的“适合”描述的是控制位置，不是对某个具体镜像的安全背书。

把内置策略放进供应链控制层

当团队需要限制 Git 主机、HTTP 下载地址、基础镜像仓库或构建参数时，应在 Dockerfile 旁维护显式的 Rego build policy。官方构建策略文档将其定位为对所有构建输入执行规则判断，可以补足内置来源策略没有覆盖的输入类型。

# 固定生产基础镜像的内容身份，避免可变标签漂移
FROM alpine:3.21@sha256:

# 构建时启用默认来源校验；显式 Rego policy 另由 CI 注入
export BUILDX_DEFAULT_POLICY=1

# 同时生成可追溯的构建证明和软件清单
docker buildx build --provenance=true --sbom=true --push .

实际流水线可以分成三层：内置策略先处理 Docker 管理来源，显式 Rego 规则限制团队允许的主机和仓库，摘要、provenance 与 SBOM 再提供可追溯证据。任何一层失败都应保留输入、策略版本和构建记录，方便复盘，而不是简单改回可变标签。

常见问题

启用内置策略后，所有镜像都会被签名校验吗？

不会。它主要针对 Docker 管理范围内的镜像和相关前端来源。外部仓库、Git、HTTP 或镜像内依赖仍需要显式规则和其他证据链。

只使用摘要引用是否就不需要策略了？

摘要能固定内容身份，但不能替代仓库允许范围、来源主机限制、漏洞扫描和构建证明。生产环境应把摘要固定与策略、SBOM、provenance 一起纳入发布门禁。