Docker Scout 快速入门

Docker Scout 分析镜像内容并生成一份详细的软件包和漏洞报告。它可以为您提供如何修复镜像分析发现的问题的建议。

本指南以一个易受攻击的容器镜像为例，向您展示如何使用 Docker Scout 识别和修复漏洞，比较不同时间的镜像版本，并与您的团队分享结果。

步骤 1：设置

这个示例项目包含一个易受攻击的 Node.js 应用程序，您可以跟随操作。

1. 克隆其仓库

   $ git clone https://github.com/docker/scout-demo-service.git
   

2. 进入该目录

   $ cd scout-demo-service
   

3. 确保您已登录到您的 Docker 帐户，可以通过运行 docker login 命令或通过 Docker Desktop 登录。

4. 构建镜像并将其推送到 <ORG_NAME>/scout-demo:v1，其中 <ORG_NAME> 是您推送到的 Docker Hub 命名空间。

   $ docker build --push -t <ORG_NAME>/scout-demo:v1 .
   

步骤 2：启用 Docker Scout

Docker Scout 默认分析所有本地镜像。要分析远程仓库中的镜像，您需要先启用它。您可以从 Docker Hub、Docker Scout 仪表板和 CLI 执行此操作。在概述指南中了解如何操作。

1. 使用 docker login 命令登录到您的 Docker 帐户，或使用 Docker Desktop 中的登录按钮。

2. 接下来，使用 docker scout enroll 命令将您的组织注册到 Docker Scout。

   $ docker scout enroll <ORG_NAME>
   

3. 使用 docker scout repo enable 命令为您的镜像仓库启用 Docker Scout。

   $ docker scout repo enable --org <ORG_NAME> <ORG_NAME>/scout-demo
   

步骤 3：分析镜像漏洞

构建后，使用 docker scout CLI 命令查看 Docker Scout 检测到的漏洞。

本指南的示例应用程序使用了一个易受攻击的 Express 版本。以下命令显示了您刚构建的镜像中影响 Express 的所有 CVE

$ docker scout cves --only-package express

Docker Scout 默认分析您最近构建的镜像，因此在这种情况下无需指定镜像名称。

在 CLI 参考文档中了解有关 docker scout cves 命令的更多信息。

步骤 4：修复应用程序漏洞

经过 Docker Scout 分析后，发现了一个高危漏洞 CVE-2022-24999，这是由过时版本的 express 包引起的。

express 包的 4.17.3 版本修复了该漏洞。因此，请将 package.json 文件更新到新版本

   "dependencies": {
-    "express": "4.17.1"
+    "express": "4.17.3"
   }

使用新标签重新构建镜像并将其推送到您的 Docker Hub 仓库

$ docker build --push -t <ORG_NAME>/scout-demo:v2 .

再次运行 docker scout 命令，并验证高危漏洞 CVE-2022-24999 已不存在

$ docker scout cves --only-package express
    ✓ Provenance obtained from attestation
    ✓ Image stored for indexing
    ✓ Indexed 79 packages
    ✓ No vulnerable package detected


  ## Overview

                      │                  Analyzed Image                   
  ────────────────────┼───────────────────────────────────────────────────
    Target            │  mobywhale/scout-demo:v2                   
      digest          │  ef68417b2866                                     
      platform        │ linux/arm64                                       
      provenance      │ https://github.com/docker/scout-demo-service.git  
                      │  7c3a06793fc8f97961b4a40c73e0f7ed85501857         
      vulnerabilities │    0C     0H     0M     0L                        
      size            │ 19 MB                                             
      packages        │ 1                                                 


  ## Packages and Vulnerabilities

  No vulnerable packages detected

步骤 5：评估策略合规性

虽然根据特定软件包检查漏洞可能很有用，但这并不是改善供应链行为的最有效方法。

Docker Scout 还支持策略评估，这是一个用于检测和修复镜像中问题的更高层次的概念。策略是一组可自定义的规则，让组织能够跟踪镜像是否符合其供应链要求。

因为策略规则特定于每个组织，您必须指定要评估的组织的策略。使用 docker scout config 命令配置您的 Docker 组织。

$ docker scout config organization <ORG_NAME>
    ✓ Successfully set organization to <ORG_NAME>

现在，您可以运行 quickview 命令来获取您刚刚构建的镜像的合规性状态概览。该镜像会根据默认策略配置进行评估。您将看到类似以下的输出

$ docker scout quickview

...
Policy status  FAILED  (2/6 policies met, 2 missing data)

  Status │                  Policy                      │           Results
─────────┼──────────────────────────────────────────────┼──────────────────────────────
  ✓      │ No copyleft licenses                         │    0 packages
  !      │ Default non-root user                        │
  !      │ No fixable critical or high vulnerabilities  │    2C    16H     0M     0L
  ✓      │ No high-profile vulnerabilities              │    0C     0H     0M     0L
  ?      │ No outdated base images                      │    No data
  ?      │ Supply chain attestations                    │    No data

状态列中的感叹号表示违反了策略。问号表示没有足够的元数据来完成评估。勾号表示合规。

步骤 6：改进合规性

quickview 命令的输出显示还有改进的空间。一些策略无法成功评估（No data），因为镜像缺少来源和 SBOM 证明。该镜像在一些评估中也未能通过检查。

策略评估不仅仅是检查漏洞。以Default non-root user（默认非 root 用户）策略为例。该策略通过确保镜像默认不以 root 超级用户身份运行，来帮助提高运行时安全性。

要解决此策略违规问题，请编辑 Dockerfile，添加一个 USER 指令，指定一个非 root 用户

  CMD ["node","/app/app.js"]
  EXPOSE 3000
+ USER appuser

此外，为了获得更完整的策略评估结果，您的镜像应附有 SBOM 和来源证明。Docker Scout 使用来源证明来确定镜像是如何构建的，以便提供更好的评估结果。

在您可以使用证明构建镜像之前，您必须启用 containerd 镜像存储（或使用 docker-container 驱动程序创建自定义构建器）。传统的镜像存储不支持清单列表，而来源证明正是通过这种方式附加到镜像上的。

在 Docker Desktop 中打开设置。在通用部分下，确保选中使用 containerd 拉取和存储镜像选项，然后选择应用。请注意，更改镜像存储会暂时隐藏非活动镜像存储的镜像和容器，直到您切换回来。

启用 containerd 镜像存储后，使用新的 v3 标签重新构建镜像。这次，添加 --provenance=true 和 --sbom=true 标志。

$ docker build --provenance=true --sbom=true --push -t <ORG_NAME>/scout-demo:v3 .

步骤 7：在仪表板中查看

在推送带有证明的更新镜像后，是时候通过另一个视角来查看结果了：Docker Scout 仪表板。

1. 打开 Docker Scout 仪表板。
2. 使用您的 Docker 帐户登录。
3. 在左侧导航栏中选择镜像。

镜像页面列出了您已启用 Scout 的仓库。

在您想查看的镜像行中，除了链接以外的任何位置单击，以打开镜像详情侧边栏。

侧边栏显示了仓库最后推送的标签的合规性概览。

注意

如果策略结果尚未出现，请尝试刷新页面。如果您是第一次使用 Docker Scout 仪表板，结果可能需要几分钟才能出现。

返回到镜像列表，并选择最新镜像列中的镜像版本。然后，在页面右上角，选择更新基础镜像按钮以检查策略。

该策略检查您使用的基础镜像是否为最新版本。它目前处于不合规状态，因为示例镜像使用了一个旧版本的 alpine 作为基础镜像。

关闭基础镜像的推荐修复模式窗口。在策略列表中，选择策略名称旁边的查看修复方案按钮，以获取有关违规的详细信息以及如何解决它的建议。

在这种情况下，推荐的操作是启用 Docker Scout 的 GitHub 集成，这有助于自动保持您的基础镜像为最新版本。

提示

您无法为本指南中使用的演示应用启用此集成。欢迎将代码推送到您自己的 GitHub 仓库，并在那里尝试该集成！

摘要

本快速入门指南仅初步介绍了 Docker Scout 支持软件供应链管理的几种方式

• 如何为您的仓库启用 Docker Scout
• 分析镜像的漏洞
• 策略与合规
• 修复漏洞并提高合规性

下一步是什么？

还有更多内容等待探索，从第三方集成到策略定制，再到实时监控运行时环境。

查看以下部分

• 镜像分析
• 数据源
• Docker Scout 仪表板
• 集成
• 策略评估