前面围绕这个项目https://github.com/Rodert/DockerHub我们已经讲过Docker Hub 镜像代理 registry-mirrors Manifest Layer Digest GitHub Actions 自动检测但只要公共镜像地址用得多了迟早会遇到一个更重要的问题公共 Docker 镜像代理到底安全吗比如原来dockerpull nginx:latest现在改成dockerpull docker.1ms.run/library/nginx:latest或者配置{registry-mirrors:[https://docker.1ms.run,https://dockerproxy.net]}镜像确实拉下来了。但问题来了我下载到的 nginx还是 Docker Hub 上官方的那份 nginx 吗代理有没有可能修改 Manifest 替换某个 Layer 返回另一份同名镜像 缓存一个过期版本 被攻击后返回恶意内容这个问题不能只回答一句“HTTPS 就安全。”也不能只回答“Docker 有 SHA256所以绝对安全。”真正要理解镜像可信问题至少要分成四层第一层HTTPS 验证传输通道 第二层Digest 验证镜像内容 第三层Signature 验证是谁发布的 第四层SBOM / Provenance 验证里面有什么、怎么构建的今天就把这四层彻底讲清楚。一、先说结论镜像代理解决的是“访问路径”原来你的服务器 ↓ Docker Hub使用代理你的服务器 ↓ Docker Mirror / Proxy ↓ Docker Hub本质上改变的是镜像从哪里传输到你的机器。它并不会天然告诉你这个镜像是谁构建的 这个镜像有没有被改过 这个镜像里有什么包 这个镜像是否来自可信 CI 这个 Tag 有没有发生变化所以可访问和可信是两个问题。二、HTTPS 能解决什么假设你访问https://dockerproxy.example.comHTTPS 主要帮助保证客户端 ↕ 镜像代理服务器之间的机密性 完整性 服务器身份认证也就是说中间网络节点不能轻易直接修改你的 HTTPS 流量。但 HTTPS 能证明的是你正在和这个域名对应的 HTTPS 服务通信。它不能自动证明这个服务给你的镜像一定就是官方发布者原始发布的镜像。这是两件完全不同的事情。三、举个极端例子假设有一个恶意代理evil-docker.example.com它自己的 HTTPS完全正常。证书也是合法证书。你执行dockerpull\evil-docker.example.com/library/nginx:latestTLS 可以保证你和 evil-docker.example.com 之间的通信没有被第三方篡改。但如果evil-docker.example.com 自己就给你一份假的 nginxHTTPS 并不能阻止它。所以HTTPS 解决的是“路上有没有被改”。而不是“源头本身是不是你想要的那份内容”。四、第二层才是 Docker 非常核心的 DigestDocker 镜像大量使用sha256:...作为内容标识。例如sha256: a81b1e2c...这就是Digest。Docker 官方文档也把现代镜像的 Digest 描述为内容寻址标识docker pull的输出会包含镜像 Digest也可以直接使用 Digest 作为镜像引用。五、Tag 和 Digest 一定要区分我们平时写nginx:latest这里latest是Tag。Tag 更像一个名字 / 指针。它可以变化。例如今天nginx:latest ↓ Manifest A下周nginx:latest ↓ Manifest B完全正常。六、Digest 不一样比如nginxsha256:abcdef...代表一份确定内容。如果 Manifest 内容改变对应 Digest也会改变。所以Tag回答“这个版本叫什么”而Digest更接近回答“到底是哪一份内容”七、这就是为什么生产环境固定 Digest 更可靠开发环境FROM nginx:latest很方便。但问题是今天构建和三个月以后构建即使 Dockerfile一个字都没改最终基础镜像也可能已经不同。如果想让构建内容固定下来可以使用FROM nginxsha256:xxxxxxxx这样基础镜像内容就被锁定。八、代理场景下 Digest 更重要假设 Docker Hub 官方nginx:1.28对应Digest A镜像代理返回Digest A至少可以证明Manifest 内容标识一致。如果代理返回Digest B就值得警惕为什么不一样可能是平台不同 Manifest List 与平台 Manifest 层级不同 缓存状态不同 Tag 已更新 代理行为异常需要进一步分析。九、Registry API 本身也提供 Manifest DigestDocker Registry API 的 ManifestHEAD操作可以用于检查某个 Manifest 是否存在并通过响应头Docker-Content-Digest返回对应 Manifest 的 Digest。所以从工具站角度看你的DockerHub 镜像集中营以后完全可以增加一个能力官方 Digest vs 镜像站 Digest 对比。十、概念流程Docker Hub nginx:latest ↓ Digest A同时Mirror A nginx:latest ↓ Digest A ✅Mirror Bnginx:latest ↓ Digest A ✅Mirror Cnginx:latest ↓ Digest B ⚠️这已经比curl 域名能不能打开高级很多。十一、但这里有一个很容易踩的坑比如nginx:latest实际上是Multi-Architecture Image。它可能先指向Image Index / Manifest List里面再包含linux/amd64 linux/arm64 linux/arm/v7不同平台自己的Manifest Digest。所以比较 Digest 时必须比较同一个层级、同一个平台。否则两个 Digest 不一样不一定说明被篡改。可能只是一个是 Image Index Digest 另一个是 amd64 Manifest Digest。十二、这也是为什么自动检测最好记录平台比如{image:nginx:latest,index_digest:sha256:aaa...,platforms:{linux/amd64:sha256:bbb...,linux/arm64:sha256:ccc...}}Mirror{index_digest:sha256:aaa...,platforms:{linux/amd64:sha256:bbb...,linux/arm64:sha256:ccc...}}就非常清楚。十三、自己机器怎么查看 Digest最简单dockerimages--digestsDocker 官方文档明确支持通过--digests显示本地镜像 Digest。例如REPOSITORY TAG DIGEST nginx latest sha256:abc123...十四、docker pull 之后也会看到 Digest例如dockerpull nginx:latest最后通常会出现类似Digest: sha256:...建议生产部署把这个 Digest 记录下来。比如 CI 日志Image: nginx:1.28 Digest: sha256:abc123...以后排查线上运行的是哪一份镜像立即有答案。十五、但 Digest 解决不了“是谁发布的”这里是特别关键的一步。假设Digest sha256:ABC确实保证内容 ABC 没有变化。但是谁告诉你ABC 本来就是官方可信发布者构建的Digest 自己不能回答。Digest 只能证明Content Identity。而不能单独证明Publisher Identity。于是就进入第三层Digital Signature。十六、镜像签名解决什么假设镜像myappsha256:ABCCI 构建完成以后由可信发布者对 Digest ABC 进行数字签名。用户拿到镜像后验证签名。如果验证成功才能进一步证明某个可信身份确实为这份 Digest 对应的镜像签过名。这就是比单纯 Digest 多出来的一层身份。十七、Cosign 是目前非常常见的容器签名工具Sigstore 的 Cosign 可以用于签名软件制品 验证软件制品 签名容器镜像 验证容器镜像Sigstore 官方当前也将 Cosign 作为推荐的签名与验证 CLI 工具。十八、最简单的签名概念假设registry.example.com/myapp sha256:ABC执行cosign sign\registry.example.com/myappsha256:ABC核心思想就是Image Digest ↓ Signature ↓ Signer Identity签名不是“给 Tag 签名”真正需要绑定的是镜像内容身份。十九、验证时也应该验证身份例如 Sigstore Keyless 模式可以cosign verify\IMAGEsha256:xxxx\--certificate-identity...\--certificate-oidc-issuer...Sigstore 官方说明Cosign 的容器签名 Payload 包含镜像 Digest默认验证过程会检查这个 Digest 是否与被验证的容器镜像相匹配。这就形成内容 发布者身份双重绑定。二十、这比“代理站说自己没改”可靠得多没有签名用户 ↓ 相信代理有签名用户 ↓ 获取镜像 ↓ 验证 Digest ↓ 验证 Publisher Signature即使镜像经过Docker Hub Mirror CDN 内部 Registry多次中转只要最终内容 Digest 没变 签名仍然有效就能获得更强的可信保证。二十一、这就是密码学的价值我们不需要要求每一个中转节点都绝对可信。而是最后验证最终制品。可以理解成Trust, but Verify。甚至更准确Don’t Trust the Transport, Verify the Artifact。二十二、那 HTTPS 还有没有意义当然有。完整体系应该HTTPS ↓ 保护传输链路 Digest ↓ 验证内容一致性 Signature ↓ 验证发布者身份它们不是互相替代。而是一层套一层。二十三、但即使镜像有官方签名还有一个问题假设镜像确实是官方构建的。它里面有没有OpenSSL glibc curl Java Node.js Python Log4j哪些版本有没有已知漏洞你还是不知道。这时候进入第四层SBOM。二十四、什么是 SBOMSBOMSoftware Bill of Materials可以翻译软件物料清单。可以把它理解成一张镜像里面到底装了哪些软件组件的清单。例如myapp:1.5 ├── ubuntu 24.04 ├── openssl 3.x ├── glibc 2.x ├── curl 8.x ├── Java 21 └── app.jar二十五、为什么 SBOM 很重要某天出现一个漏洞某版本 OpenSSL 存在 CVE。如果你公司有1000 个镜像。难道一个一个启动容器 进去 apt list显然不现实。如果每个镜像都有SBOM可以直接搜索哪些镜像包含受影响版本这就是供应链管理非常重要的能力。二十六、Docker BuildKit 现在支持构建时生成 SBOMDocker 当前的 Build Attestation 文档把构建证明分为两类核心信息SBOM 镜像包含哪些软件制品 Provenance 镜像是怎么构建出来的BuildKit 可以在构建阶段生成并附加这些 Attestation。例如dockerbuildx build\--sbomtrue\.可以生成 SBOM Attestation。二十七、还有 Provenance例如dockerbuildx build\--provenancemodemax\.Provenance 关注这个镜像如何产生 用了什么构建过程 来自什么构建环境 构建输入是什么Docker 当前文档把 Provenance 描述为How an image was built。二十八、这就出现完整供应链证据以前我们只有myapp:1.5现在Image │ ├── Digest │ │ └── 它是哪份内容 │ ├── Signature │ │ └── 谁签的 │ ├── SBOM │ │ └── 里面有什么 │ └── Provenance └── 怎么构建出来的这已经不是简单docker pull的问题了。而是Software Supply Chain Security。二十九、SBOM 不能证明镜像一定安全这个也特别容易误解。有 SBOM≠ 没有漏洞。SBOM 只是更透明。告诉你里面有什么。接下来漏洞扫描器 Policy Engine 安全平台再基于 SBOM 或镜像内容分析风险。所以SBOM Inventory而不是Safe Certificate。三十、Provenance 同样不是“绝对安全证明”它更多告诉你这个 Artifact 是怎么形成的。例如Git Repository ↓ CI ↓ BuildKit ↓ Image这让你可以设计策略只允许来自公司 GitHub Organization 只允许来自指定 Workflow 只允许特定 Builder 必须有 Provenance 必须签名然后才能形成真正Policy-Based Deployment。三十一、一个成熟的生产部署流程应该是什么样开发者git push↓CIBuild↓生成Image Digest SBOM Provenance↓签名Cosign↓PushRegistry↓生产部署前Verify Digest Verify Signature Check Provenance Scan SBOM↓最后Deploy整个链Source ↓ Build ↓ Attestation ↓ Sign ↓ Registry ↓ Verify ↓ Deploy这才是真正的Secure Container Supply Chain。三十二、公共 Mirror 在这个体系里是什么角色你会发现Mirror只是Distribution Layer。也就是负责把 Artifact 送到你手里。如果你拥有Digest Signature SBOM Provenance你的安全模型就不会完全建立在“我相信这个代理站老板”之上。三十三、对于 DockerHub 项目我建议下一步加入“可信度检测”现在项目可以检测Mirror 是否在线 延迟多少 nginx 能否拉取下一版完全可以增加Manifest Digest对比。最终状态Mirror可用延迟Digest1ms320ms✅ 一致Proxy A510ms✅ 一致Proxy B1.8s⚠️ 待确认Proxy C--这会让工具站从“速度检测”升级成“速度 内容一致性检测”。三十四、第一步可以只比较热门镜像例如nginx:latest redis:7 mysql:8.4 ubuntu:24.04 node:22 golang:1.25GitHub Actions每 6 小时 ↓ 查询官方 Manifest ↓ 记录 Digest ↓ 查询各个 Mirror ↓ 记录 Digest ↓ Compare结果✅ Match ⚠️ Mismatch ❌ Unavailable这已经非常有价值。三十五、但是 latest 不适合作为唯一安全测试因为latest可能随时移动。假设官方刚更新。代理缓存还没有同步。那么短时间Official Digest B Mirror Digest A这不一定意味着代理被篡改。可能只是Cache Lag。所以状态页应该区分Digest Match和Cache Behind不能简单不一致 恶意。三十六、更合理的检测方式选一个固定版本 Tag例如nginx:1.28.x再记录第一次观察到的官方 Digest。如果官方对应 Tag 本身不再变化Mirror 应该稳定返回同一 Digest。这比latest更适合一致性检测。三十七、更强的方法直接使用固定 Digest 测试例如已知Official: nginxsha256:ABC去 Mirror 查询ABC能不能正确访问。因为Digest 是内容地址。它不存在“最新版本同步慢”这种歧义。这才是真正适合Artifact Integrity Test的方式。三十八、项目甚至可以做“官方锚点”例如维护{image:library/nginx,tag:1.28,official_digest:sha256:...}然后检测Mirror A ABC ✅ Mirror B ABC ✅ Mirror C 无法读取 ❌比访问首页可靠得多。三十九、还可以加入 Multi-Arch 检查官方linux/amd64 Digest A linux/arm64 Digest BMirroramd64 Digest A ✅ arm64 Digest B ✅这样 Mac M 系列用户也能知道ARM64 是否正常。四十、再往上一步签名状态如果一个测试镜像本身有 Cosign Signature状态页甚至可以拉取 ↓ cosign verify ↓ 展示结果比如Mirror A Availability: ✅ Digest: ✅ Signature: ✅这个概念会非常酷。四十一、但不要错误展示“所有 Docker Official Image 都有 Cosign 签名”不同镜像的签名 Attestation Provenance支持情况并不一样。所以工具站一定要有则验证 无则显示 Unknown / Not Available而不是没有签名 镜像恶意。这两个概念不能混淆。四十二、一个工具站最终可以有四个状态维度1. Availability能不能访问2. Performance快不快3. IntegrityDigest 是否和官方锚点一致4. Supply Chain Metadata有没有 Signature / SBOM / Provenance最后速度 稳定性 内容一致性 供应链信息一起展示。这个产品就和普通Docker 镜像源列表完全不是一个级别了。四十三、再说一个常见误区docker pull成功就代表安全不是。docker pull成功只能说明客户端拿到了一个 协议上合法的镜像。它不能自动证明业务上可信 发布者可信 没有漏洞 符合企业策略。所以生产系统不能把Pull Success当成Security Success。四十四、第二个误区Digest 一样就说明没有安全问题Digest 一样可以很好地证明内容是同一份。但如果官方原始镜像本身就有漏洞。Digest 一样只是证明你准确下载到了这份有漏洞的镜像。所以Digest解决Integrity。不解决Vulnerability。四十五、第三个误区镜像签名就代表没漏洞也不对。Signature 解决是谁发布的。假设官方开发者真的发布了一份包含旧版 OpenSSL的镜像。签名完全可能100% 正确。但漏洞依然存在。所以签名不替代漏洞扫描。四十六、第四个误区SBOM 就等于漏洞扫描也不一样。SBOM告诉你有哪些组件。漏洞数据库告诉你哪些组件版本有已知漏洞。真正的扫描SBOM / Image Vulnerability Database ↓ Risk Analysis所以SBOM是基础数据。四十七、把这四种能力放在一起就特别清楚HTTPS ↓ 我是否安全地连接到目标服务器 Digest ↓ 我拿到的是否是指定内容 Signature ↓ 这份内容是谁认可发布的 SBOM ↓ 这份内容里面有什么 Provenance ↓ 这份内容是怎么构建的 Vulnerability Scan ↓ 这些组件有没有已知漏洞每一层回答不同问题。四十八、如果只是普通个人开发者做到哪一步其实不用一下搞成银行级供应链系统。我建议最少1. 使用 HTTPS Mirror 2. 不要随便运行来源不明镜像 3. 重要镜像记录 Tag Digest 4. 生产环境不要依赖 latest 5. 关键生产镜像考虑内部 Registry已经能避免很多问题。四十九、小团队再加两层6. 镜像漏洞扫描 7. CI 生成 SBOM例如构建dockerbuildx build\--sbomtrue\--provenancemodemax\--push\-tregistry.example.com/app:1.0.Docker 当前 BuildKit 可以生成 SBOM 和 Provenance Attestation并在推送到 Registry 时保留这些构建元数据。五十、更严格的企业环境再加签名构建Source ↓ CI ↓ Image Digest然后Cosign Sign部署Cosign Verify验证通过以后才允许部署。这样就能建立Admission Policy。五十一、甚至 Kubernetes 可以做“拒绝未签名镜像”完整理念Developer Push ↓ CI Build ↓ Sign ↓ Registry ↓ Kubernetes Deploy Request ↓ Policy Engine ↓ Verify Signature ├── Success → Deploy └── Fail → Reject这才是真正Zero Trust for Artifacts。不要因为镜像来自公司 Registry就自动无条件信任。五十二、公共镜像代理在企业环境应该怎么用开发机Public Mirror可以作为加速工具。生产我会更倾向Docker Hub ↓ 企业 Pull-through Cache ↓ 安全扫描 ↓ 内部 Registry ↓ Production也就是说公共 Mirror 用来解决开发便利性。企业内部 Registry 用来解决生产治理。五十三、如果直接让生产服务器连接公共 Mirror 呢技术上当然可以。但你会失去很多企业控制缓存策略 访问审计 镜像白名单 版本锁定 漏洞扫描 签名策略 Retention 权限所以服务器规模大以后自建 Registry / Cache通常更合理。五十四、这也让 DockerHub 项目的定位更加清晰你的项目最适合解决开发者 Docker Hub 访问困难 快速寻找可用 Mirror 配置 Docker 测试 Mirror 状态 理解镜像代理进一步可以增加Digest 一致性作为安全辅助信息。但不应该宣传成“我们检测过所以这个第三方代理绝对安全。”更准确我们可以检测访问状态、延迟以及部分内容一致性但最终生产安全仍需要 Digest 锁定、签名验证和内部供应链策略。这个表述会专业很多。五十五、一个很适合项目新增的检测结构例如{mirror:docker.1ms.run,availability:{status:online,latency_ms:320},integrity:{image:nginx:1.28,official_digest:sha256:abc,mirror_digest:sha256:abc,match:true},platforms:{linux/amd64:true,linux/arm64:true},checked_at:2026-10-05T12:00:00Z}这样网页就能直接展示 可用 ⚡ 320ms Digest 一致 AMD64 ✅ ARM64 ✅用户决策成本会很低。五十六、再做一个风险等级例如A 可用 Digest Match Multi-Arch 完整 B 可用 Digest Match 较慢 C 可用但尚未完成 Digest 验证 D Digest 不一致 / 异常 F 无法访问注意Digest 不一致一定不要直接写“恶意镜像”更合理⚠️ 内容版本与当前官方锚点不一致请检查缓存同步或镜像来源。因为安全产品最忌讳过度下结论。五十七、这个项目甚至可以做“镜像验证命令生成器”用户输入nginx:1.28页面生成dockerpull nginx:1.28查看dockerimages--digestsnginx再dockerbuildx imagetools inspect nginx:1.28如果项目知道官方 Digest还可以显示Expected Digest: sha256:...用户就能自己确认。五十八、如果镜像支持 Cosign再生成概念上cosign verify\IMAGEsha256:......不过这里一定要明确告诉用户 应该验证哪个 Signer Identity 和哪个 OIDC Issuer。不能为了“看起来安全”随便允许任意签名人。签名验证最核心的就是我到底信任谁。五十九、例如真正的 Verify Policy 应该是Digest: 必须固定 Signer: 必须属于指定组织 OIDC Issuer: 必须是指定 CI 身份系统 Provenance: 必须存在 SBOM: 必须存在 Critical Vulnerability: 必须低于阈值这就形成Artifact Policy。不是简单能启动就上线。六十、Docker 世界最终其实有两条链下载链Docker Hub ↓ Mirror ↓ Docker Daemon ↓ Image解决可访问性 速度。信任链Publisher ↓ Digest ↓ Signature ↓ Provenance ↓ SBOM ↓ Policy ↓ Deploy解决身份 完整性 可审计 供应链安全。两条链都需要。总结很多开发者第一次使用 Docker 镜像代理时最关心的问题只有能不能拉下来于是Mirror Online 一切 OK但生产环境真正应该问的是能不能拉 拉得快不快 拉到的是哪一份内容 和官方 Digest 是否一致 谁发布了这份镜像 有没有可信签名 镜像里面有哪些组件 它是怎么构建的 有没有已知漏洞这些问题分别对应Availability ↓ 镜像代理 Performance ↓ 延迟 / 缓存 Integrity ↓ Digest Identity ↓ Signature / Cosign Contents ↓ SBOM Build Lineage ↓ Provenance Risk ↓ Vulnerability Scan所以如果只记住一句话HTTPS 证明“你连接到了谁”Digest 证明“你拿到了哪份内容”Signature 证明“谁认可发布了这份内容”SBOM 和 Provenance 则进一步告诉你“里面有什么、它是怎么来的”。对于https://github.com/Rodert/DockerHub这个项目来说下一步除了继续维护哪些 Mirror 还能用我觉得非常值得增加Mirror Digest 一致性检测。最终从Docker 镜像地址导航升级成镜像可用性 延迟 Multi-Arch Digest 一致性的开发者工具。这样整个“大航海”系列的比喻也可以继续Docker Hub 母港 Mirror 中转港 Manifest 航海货单 Layer 货箱 Digest 货箱封印 Cosign Signature 船长签章 SBOM 货物清单 Provenance 完整航海日志船可以经过很多港口但真正重要的是货到了以后你仍然能够证明——这就是出发时的那批货。项目地址https://github.com/Rodert/DockerHub