Docker Scout：如何扫描容器镜像漏洞

故事大致是这样的：您构建了 Docker 镜像、打了标签并部署了它。一切看起来都很顺利，直到安全团队标记出某个您甚至不知道存在的软件包有漏洞。更糟的是，合规要求提供软件物料清单（SBOM），而您还在思考如何弄清镜像里到底带了哪些依赖。容器镜像可能像个黑箱，当您要为生产环境中运行的内容负责时，这就成了问题。

Docker Scout 通过扫描容器镜像中的漏洞并自动生成 SBOM，为您提供对镜像内部的可见性。它内置于 Docker 中，无需安装或学习单独的工具。

在本指南中，我将向您展示如何用 Docker Scout 扫描镜像并理解其生成的漏洞报告，帮助您判断在何时使用它更合适。

如果您是 Docker 新手，请查看我们关于 Top 18 Docker Commands 的文章。这些命令将帮助您走上构建、运行与管理容器的正确道路。

什么是 Docker Scout？

Docker Scout 是 Docker 的原生镜像分析工具，可扫描容器镜像中的漏洞并生成软件物料清单（SBOM）。

它会分析镜像中的一切：从基础操作系统软件包、各语言生态的依赖到应用程序库。然后将它们与已知漏洞数据库进行比对。您会得到一份报告，显示哪些软件包存在安全问题、严重程度如何，以及哪些版本可以修复它们。

因此，您无需使用第三方扫描器，也不用等安全团队在部署后再来提示问题，您可以在构建镜像的地方直接进行扫描。Scout 可在 Docker Desktop、通过 CLI 运行，并与 Docker Hub 集成。

它在 Docker 生态中的定位是这样的：Docker 构建并运行您的容器，Docker Hub 存储它们，而 Docker Scout 告诉您它们内部都有什么。请记住，它现在是平台的一部分，而不是单独的附加组件。

Docker Scout 取代了更早的 docker scan 命令，后者依赖 Snyk 的扫描引擎。Scout 使用 Docker 自身的漏洞数据库，并让您对扫描过程有更多掌控。如果您仍在使用 docker scan，它已被弃用——Scout 是官方替代方案，并且已在近期的 Docker Desktop 版本中提供。

安装并启用 Docker Scout

Docker Scout 内置于 Docker Desktop 4.17 及更高版本，如果您在使用较新版本，就已经拥有它了。

它可通过 Docker CLI 工作，并出现在 Docker Desktop 的图形界面中。如果您使用 Docker Desktop，Scout 默认启用——您可以立即开始扫描镜像。

要检查系统上是否可用 Scout，请运行以下命令：

docker scout version

您将看到显示 Scout CLI 版本和插件状态的输出。

Docker scout version

如果命令能够运行，您就可以开始扫描镜像了。

如果出现“command not found”错误，说明您的 Docker 版本过旧。请更新 Docker Desktop至最新版本以获取 Docker Scout。

使用 Docker Scout 扫描镜像

运行扫描只需一个命令，这部分很简单。更具挑战的是，有时需要理解 Scout 找到了什么。

分析镜像

您可以通过将本地镜像的名称或 ID 传给 Docker Scout 来扫描它：

docker scout cves python:3.14

Scout 会分析镜像层，提取软件包信息，并检查已知漏洞。对于大多数镜像，扫描会在 30 秒内完成。

Scan results for Python 3.14 image

您也可以扫描尚未在您机器上的镜像：

docker scout cves postgres:18.1

Scout 会从镜像仓库拉取元数据而无需下载完整镜像。这使您可以在本地拉取前先检查镜像。

Scan results for Postgres 18.1 image

在分析过程中，Scout 会解包每一层，识别已安装的软件包和依赖，然后将所有内容与其漏洞数据库交叉比对。它会追踪基础操作系统的软件包（如基于 Ubuntu 的镜像中的 apt 包）以及特定语言的依赖（如 Python 包或 Node 模块）。

理解输出

Scout 按严重程度对漏洞分组：Critical、High、Medium 和 Low。

Critical 和 High 等级的漏洞需要优先关注。这些通常是正在被利用的问题或可能危及系统的严重缺陷。中等严重性的问题同样重要，但较少需要立即修复。低严重性漏洞值得跟踪，但通常不会阻塞部署。

每个漏洞会显示是哪个软件包包含了问题。如果您向下滚动报告，会看到类似以下的输出：

Vulnerability report

这会准确告诉您哪些内容存在漏洞（openssl）、您正在运行的版本，以及修复它的版本。Scout 还会链接到 CVE 详情，便于您自行了解漏洞信息。

软件包归属会显示漏洞来源——是基础镜像的软件包、应用依赖，还是系统库。这有助于您决定是更新基础镜像、在代码中升级依赖，还是等待上游修复。

使用 Docker Scout 生成并查看 SBOM

软件物料清单（SBOM）是容器镜像中所有内容的完整清单——每个软件包、库和依赖。

它精确告诉您镜像中包含了什么，细致到具体的版本号。安全团队使用 SBOM 来追踪生产环境中运行的内容，且合规框架往往也要求提供它。

当您使用上一节展示的命令扫描镜像时，Docker Scout 会自动生成 SBOM。重申一下：

docker scout sbom postgres:18.1

该命令会在终端输出完整的软件包列表。Scout 会分析镜像层并提取软件包元数据，然后将其格式化为可保存或共享的 SBOM。

您可以将 SBOM 导出到文件，而不是打印到屏幕：

docker scout sbom postgres:18.1 --format spdx > postgres-sbom.json

SBOM SPDX report

Scout 支持两种标准 SBOM 格式：SPDX（Software Package Data Exchange）与 CycloneDX。二者都是广泛使用的业界标准。SPDX 更适用于合规和法律审查，而 CycloneDX 更侧重安全场景与漏洞跟踪。

您可以通过 --format 标志在格式之间切换：

docker scout sbom postgres:18.1 --format cyclonedx > postgres-sbom.json

SBOX CycloneDX report

获得 SBOM 文件后，您可以将其分享给安全团队，输入到其他扫描工具，或为合规审计归档。

使用 Docker Scout 查找并理解 CVE

Docker Scout 通过将镜像中的软件包与已知安全问题数据库进行匹配来发现漏洞。

当您运行 docker scout cves 时，Scout 会从镜像中提取每个软件包——操作系统软件包、语言库、应用依赖——然后将它们逐一与通用漏洞与披露（CVE）记录进行比对。CVE 是公开披露的安全缺陷，具有类似 CVE-2024-1234 这样的唯一 ID。

Scout 从多个来源获取 CVE 数据：

• 国家漏洞数据库（NVD）
• 各 Linux 发行版的安全公告
• Python、Node.js、Go 等生态的特定语言安全数据库

这意味着 Scout 既能捕捉基础镜像操作系统软件包中的漏洞，也能发现应用程序依赖中的漏洞。

不过，重要的是要记住，分析方式会因镜像所在位置而有所不同。

• 对于本地镜像（您在机器上构建或拉取的镜像），Scout 会直接从 Docker 守护进程读取镜像层。它会解包每一层、识别软件包，并在本地运行漏洞检查。该方式速度快，且无需对镜像本体进行网络访问。
• 对于远程镜像（在 Docker Hub 或其他镜像仓库上），Scout 会在不下载完整镜像的情况下获取镜像清单与层元数据。这使您可以在拉取前先进行扫描。漏洞数据仍来自 Scout 的数据库，但镜像分析基于仓库的元数据完成。

两种方式提供相同的漏洞信息，只是 Scout 读取镜像数据的来源不同。

修复建议与基础镜像推荐

当 Scout 发现可用补丁的漏洞时，会显示修复该问题的准确版本。您会在每个 CVE 旁看到类似“Fixed in: 1.2.3”的输出。这让您知道是否需要更新某个软件包、用较新的基础镜像重建镜像，或等待上游修复。

当切换到较新的基础镜像可消除漏洞时，Scout 还会推荐升级基础镜像。如果您使用的是 python:3.13 而 Scout 发现基础操作系统软件包存在问题，它可能建议升级到 python:3.14，甚至是更具体的补丁版本。

当 Scout 检测到不同的基础镜像标签比您当前使用的标签拥有更少的漏洞时，就会给出这些建议。建议是可操作的——您可以直接把新标签复制到 Dockerfile 中并重建。

那么，为什么这很重要？

您的基础镜像包含操作系统软件包、系统库和语言运行时，其他一切都依赖于它们。基础镜像存在漏洞，意味着从它构建的每个容器都会继承这些漏洞。选择精简且积极维护的基础镜像，可以降低攻击面。

Docker Hub 上的官方镜像会定期获得安全更新，但您仍需要重建自己的镜像以获得这些修复。例如，今天拉取 python:3.13 与六个月前拉取它，得到的软件包就会不同。

在 CI/CD 中使用 Docker Scout

团队将 Docker Scout 集成到 CI 流水线中，以在镜像进入生产前捕获漏洞。

思路很简单：将每个镜像的扫描作为构建流程的一部分，如果出现关键（Critical）漏洞则使构建失败。这样您会在开发阶段而不是部署后发现问题。大多数团队会设置在有人推送新的 Dockerfile 或更新基础镜像时，自动运行 Scout。

流水线通常检查两件事：

• 漏洞回退（回归）——将新镜像与前一个版本进行比较。如果新构建引入的 Critical 或 High 漏洞比上一个更多，流水线即失败。这能防止您无意中发布比当前在线版本更差的安全性。
• 策略偏离——验证您的镜像是否符合安全标准。您可能有这样的策略：“不允许存在 Critical 级别的 CVE”，或“基础镜像必须少于 30 天”。Scout 可以在 CI 工作流中自动执行这些规则。

与 GitHub Actions、GitLab CI 或 Jenkins 的集成在概念上相同。您构建镜像，针对它运行 docker scout cves，解析结果，并根据您的标准决定流水线是通过还是失败。一些团队则将 Scout 集成到容器镜像仓库的流程中，在镜像推送后立即进行扫描。

Docker Scout 与其他镜像扫描器对比

Docker Scout 并非唯一可用的工具。它与 Trivy、Snyk 等工具存在竞争，但各自面向的工作流不同。

• Trivy 是一个开源扫描器，可在任何地方运行，从本地机器、CI 流水线到 Kubernetes 集群。它可扫描容器镜像、文件系统和 Git 仓库。Trivy 在扫描位置和方式上更灵活，且无需 Docker 账号。可将其视为独立于 Docker 生态运行的扫描器。
• Snyk 聚焦开发者工作流，并与 IDE、GitHub 及其他开发工具深度集成。除容器外，它还能扫描应用依赖、基础设施即代码以及源代码。Snyk 也会提供详细的修复指导，并可发起 PR 来修复漏洞。如果您需要覆盖整个技术栈（不仅仅是容器）的安全能力，Snyk 是一个合理的选择。
• Docker Scout 在您已经使用 Docker Desktop 和 Docker Hub 的情况下效果最佳。它是原生集成的，无需额外设置、无需管理 API 密钥、也无需学习独立工具。Scout 会扫描推送到 Docker Hub 的镜像，CLI 则是 Docker 安装的一部分。

如果您的团队使用 Docker 工具构建并运行容器，并希望在不增加复杂度的情况下获得安全可见性，请选择 Docker Scout。如果您需要灵活、可在任何地方使用的开源方案，请选择 Trivy。如果您希望在容器、代码与基础设施上获得全面安全与自动化修复，请选择 Snyk。

常见限制与须知

Docker Scout 会扫描容器镜像，但不会监控您部署后的运行情况。

它分析的是静态镜像——内置于容器中的软件包与文件。它无法检测运行时问题，如权限提升攻击、网络入侵或部署后启动的恶意进程。如果您需要运行时安全监控，应使用 Falco 或 Sysdig 等在生产环境中观察容器行为的工具。

Scout 也不能替代完整的SAST（静态应用安全测试）或DAST（动态应用安全测试）。SAST 工具在构建前分析源代码中的安全缺陷；DAST 工具通过模拟攻击测试正在运行的应用。Scout 只关注已构建镜像内部的软件包——它不会发现应用逻辑中的漏洞或代码中的配置错误。

Scout 擅长的是让您看清镜像内部并引导您进行修复。它会告诉您哪些软件包存在漏洞、哪些版本可以修复，以及哪些基础镜像可以减少攻击面。这使 Scout 非常适合用于构建时的安全检查和合规跟踪，但您仍需要其他工具来覆盖完整的安全维度。

使用 Docker Scout 的最佳实践

以下是一份清单，帮助您最大化利用 Docker Scout。

• 在开发周期早期进行扫描。 在本地开发期间就对镜像运行 Scout，而不仅仅在 CI 或部署前。越早发现漏洞，修复时的上下文越清晰、成本越低。等到生产环境才处理，往往意味着在压力下紧急打补丁。

• 随时间比较镜像以跟踪安全趋势。 Scout 可以显示您的安全状况是在改善还是恶化。对每次构建运行扫描并比较结果。如果新构建比上一次引入了更多关键漏洞，说明发生了变化——可能是依赖更新或基础镜像变更，您需要调查。

• 将 Scout 的发现视为优先级信号，而非绝对阻断。 并非每个漏洞都需要立刻行动。开发依赖中、且不在生产中使用的低严重性 CVE 可以暂缓；公开暴露服务中的关键 CVE 则需要立即处理。结合 Scout 的严重性分级与软件包上下文，针对您的部署场景决定优先级。

• 将 Scout 与基础镜像卫生搭配使用。 选择精简且积极维护的基础镜像，并定期更新。使用 python:3.14-slim 代替 python:3.14，可以剔除不需要的软件包。每月重建镜像可获取基础层中的安全补丁。Scout 能告诉您哪里有漏洞，但选好基础镜像能从源头预防许多漏洞出现。

结语

Docker Scout 为您提供了一种切实可行的方式，开始理解容器镜像内部的组成。

它无缝契合基于 Docker 的开发流程——无需安装独立工具，无需设置额外账号。您运行一个命令，就能获得漏洞报告，并了解需要更新哪些软件包。

Scout 最好作为更广泛安全方案的一部分，而不是唯一选择。将其与运行时监控、源代码分析以及定期更新基础镜像相结合。在构建阶段用它发现漏洞，再用其他工具覆盖部署之后发生的事情。

如果您想了解 Docker 如何融入机器学习的 CI/CD 流水线，请报名我们的 CI/CD for Machine Learning 课程。一个下午就能找到所有答案。