Docker 27通过platform-aware缓存、SLSA Provenance原生集成、架构感知Dockerfile语法及manifest list级统一签名，实现跨架构镜像安全一致性。
要确保跨架构镜像在安全性上完全一致，关键不是“额外加安全措施”，而是让安全控制逻辑本身也随架构精准复现——Docker 27 的多平台构建机制已把安全一致性嵌入底层流程。
用 platform-aware 缓存防止安全层污染
旧版 Docker 构建时，缓存不区分平台，可能导致 ARM64 构建中误复用 AMD64 下安装的带漏洞版本依赖。Docker 27 默认启用 BuildKit 后，缓存键自动包含 platform + build-args + 源码哈希 三元组。这意味着：
- 同一行 RUN apt-get install openssl 在 linux/amd64 和 linux/arm64 下生成完全独立的缓存层
- 即使两个平台使用相同基础镜像，只要架构不同，安全补丁、动态链接行为、甚至编译器生成的二进制签名都单独验证和存储
- CI 流水线中无需人工清理缓存或隔离构建环境，平台间零交叉污染
通过 SLSA Provenance 实现跨架构可验证溯源
Docker 27 原生集成 SLSA v1.0 构建证明（Provenance），每次执行 docker build --platform linux/amd64,linux/arm64，都会为每个平台输出独立且签名的 slsa.provenance.json 文件，并作为 OCI 注解写入对应架构的 manifest 中。这带来实际保障：
- 你可以用
cosign verify-attestation --type slsa分别校验 arm64 和 amd64 镜像的构建链路是否真实、未被篡改 - 证明中明确记录了该架构下使用的具体 toolchain 版本、内核模块（如 binfmt_misc 是否启用）、甚至构建节点的硬件信任根（如 TPM attestation）
- 金融或政企场景中，审计方能确认：ARM64 镜像不是“套壳 AMD64 产物”，而是真正在合规 ARM 节点或经验证 QEMU 环境中构建
在 Dockerfile 中声明架构感知的安全操作
避免硬编码平台逻辑，改用 BuildKit 的原生条件语法，让安全动作自动适配目标架构：
- 用
RUN --platform=linux/arm64单独加固 ARM64 特定环节，例如禁用不安全的浮点指令集或加载 ARM 专用 SELinux 策略 - 在 FROM 行使用多阶段平台变量：
FROM --platform=${BUILDPLATFORM} golang:1.25-alpine AS builder，确保构建阶段工具链与目标平台 ABI 兼容，杜绝因工具链错位引入的内存安全风险 - 对敏感命令（如密钥注入、证书安装）添加平台校验：
RUN [ "$(uname -m)" = "aarch64" ] && echo "ARM64 mode: using hardened crypto lib"
统一签名与策略执行必须基于 manifest list 级别
安全策略不能只作用于单个架构镜像，而要锚定在 manifest list 这一逻辑实体上：
- 使用
docker buildx imagetools create或oras attach对整个 multi-arch 镜像打统一 SBOM 和签名，确保所有子镜像共享同一份软件物料清单和完整性摘要 - 在准入控制（如 Kubernetes admission controller 或 Harbor P2P 扫描）中，检查的是 manifest list 的 digest，而非某个具体架构的 digest——这样可防止攻击者替换其中某一架构镜像而不触发告警
- 运行时拉取时，容器引擎自动匹配平台并校验对应子镜像的签名；若某架构子镜像缺失签名或校验失败，整个拉取拒绝，不降级回退
