突发安全公告：Docker Hub 发现恶意镜像，已紧急下架200+高风险镜像​

刘学敏 2026-02-11 09:50:00
摘要： 近期，安全研究人员在 Docker Hub 上发现并报告了大规模的恶意镜像活动，Docker 官方已迅速响应，下架了超过 200 个被确认为高风险的镜像。此次事件再次为所有使用容器技术的团队敲响了警钟。本文将为你提供一套完整的自查、清理与长效防御方案，帮助你评估风险并加固安全防线。

事件概览与影响范围

本次发现的恶意镜像主要通过两种方式进行伪装：一是模仿流行的开源软件项目，使用相似的名称（即“Typo-squatting”）诱导用户下载；二是在看似无害的镜像中植入信息窃取或加密货币挖矿的恶意负载。

这些镜像一旦被用户拉取并在环境中运行，其内置的恶意脚本便会启动，可能导致服务器凭证、代码、环境变量等敏感信息泄露。

如果你或你的团队有从 Docker Hub 拉取非官方、个人发布或名称可疑的镜像的习惯，那么就存在潜在的受影响风险。虽然 Docker 官方镜像和经过验证的发布者镜像是安全的，但养成对所有外部镜像进行审查的习惯至关重要。

突发安全公告：Docker Hub 发现恶意镜像，已紧急下架200+高风险镜像

紧急响应：如何立即排查与清理

面对此类安全事件，快速、系统地排查是控制风险的第一步。请按照以下步骤，立即对你的环境进行检查。

步骤一：盘点在用镜像

首先，你需要清晰地了解环境中存在哪些镜像。连接到你的服务器或本地开发环境，执行以下命令，列出所有已下载的镜像： 

docker images

或使用以下命令，仅列出正在被容器（包括已停止的）使用的镜像： 

docker ps -a --format "{{.Image}}" | sort | uniq

将这份列表作为你排查的基础清单。

步骤二：审查镜像来源与历史层

对于清单中的每一个镜像，尤其是那些来源并非官方或你团队内部的镜像，需要仔细审查其来源。一个关键的检查点是镜像的命名空间。例如，nginx 是官方镜像，而 someuser/nginx 则是个人发布的，风险更高。

更进一步，可以使用 docker history 命令检查镜像的构建历史： 

docker history your-suspicious-image:tag

在输出中，重点关注那些执行了可疑操作的 RUN 或 CMD 指令，例如从未知 URL 下载脚本（curl、wget）、运行混淆过的代码，或修改关键系统文件。任何看起来不透明或不符合镜像预期功能的命令层都值得警惕。

步骤三：使用开源工具进行漏洞扫描

自动化工具能极大地提升排查效率。Trivy 和 Grype 是两款广受欢迎的开源容器镜像扫描工具，它们可以检测操作系统包和应用程序依赖中的已知漏洞（CVEs）。

使用 Trivy 扫描一个镜像： 

trivy image your-suspicious-image:tag

使用 Grype 扫描一个镜像： 

grype your-suspicious-image:tag

虽然这些工具的主要目标是发现 CVE，但它们的扫描报告也能揭示镜像中是否包含非预期的软件包或库，这同样是判断镜像是否被篡改的有效线索。

步骤四：清理可疑镜像与容器

一旦确认某个镜像是恶意的或高度可疑，应立即停止并删除使用该镜像的所有容器，然后强制删除该镜像。 

# 停止并删除相关容器
docker stop <container_id>
docker rm <container_id>
# 强制删除可疑镜像
docker rmi -f <image_id_or_name>

完成清理后，建议立即轮换可能已泄露的凭证，如服务器密钥、数据库密码和 API 令牌。

快速排查的核心是“盘点-审查-扫描-清理”。通过这套组合拳，可以迅速定位并移除环境中的潜在威胁。

长效防御：构建可信的容器供应链

紧急响应只能解决眼前的问题，建立一套健壮的防御机制才能从根本上规避风险。这本质上是在构建一个可信的软件供应链。

坚持使用官方或经过验证的基础镜像

这是最基础也是最重要的一条原则。尽可能从 Docker Hub 上的官方仓库或经过认证的发布者获取镜像。对于团队内部的应用，应建立私有镜像仓库（如 Harbor、AWS ECR、Google GCR），所有推送到生产环境的镜像都应源自这个受信任的仓库。

利用镜像哈希（Digest）锁定版本

在 Dockerfile、Kubernetes 部署文件或 docker-compose 文件中，避免使用 :latest 或可变的标签。这些标签可以被重新指向不同的镜像，带来不确定性。

推荐使用镜像的 SHA256 哈希值来锁定确切的版本，格式如下：

image:tag@sha256:digest_value

这种方式保证了你每次拉取的都是完全相同、不可篡改的镜像版本，有效防止了供应链中的“中间人”攻击。

将镜像扫描集成到 CI/CD 流程

安全应当左移（Shift-Left），融入到开发的早期阶段。将镜像扫描作为 CI/CD 流水线中的一个强制步骤，是实现这一目标的关键实践。

具体流程如下：

  1. 开发人员提交代码。
  2. CI/CD 系统（如 Jenkins, GitLab CI）自动构建 Docker 镜像。
  3. 在将镜像推送到仓库之前，流水线调用 Trivy 或其他扫描工具对新构建的镜像进行扫描。
  4. 设定一个安全基线，例如“不允许存在任何高危（High）或严重（Critical）级别的漏洞”。如果扫描结果超出阈值，流水线将自动失败，并阻止该镜像的发布。

这种自动化机制确保了任何带有已知高风险漏洞的镜像都无法进入你的镜像仓库，更不用说部署到生产环境了。

实施最小权限与最小镜像原则

最后，从镜像构建本身入手，减少攻击面。

  • 最小镜像：使用多阶段构建（Multi-stage builds）来创建最终镜像，只包含运行应用所必需的二进制文件和依赖，剔除所有编译工具和调试工具。考虑使用像 distroless 这样的极简基础镜像。
  • 最小权限：在 Dockerfile 中，使用 USER 指令指定一个非 root 用户来运行你的应用程序。这能极大地限制容器内进程的权限，即使应用被攻破，攻击者也难以对宿主机造成进一步的危害。

容器安全是一个持续性的过程，而非一次性的任务。此次 Docker Hub 事件是一个有力的提醒，督促我们必须将供应链安全视为应用安全的核心组成部分。

© docker中文社区站