Docker Scout 中的策略评估入门
在软件供应链管理中，维护安全性和可靠性 的工件是重中之重。Docker Scout 中的策略评估引入了 控制层，位于现有分析功能之上。它允许您定义 Artifacts 的供应链规则，并帮助您跟踪 Artifacts 随着时间的推移，相对于您的规则和阈值执行。
了解如何使用 Policy Evaluation 来确保工件保持一致 具有既定的最佳实践。
策略评估的工作原理
当您为存储库激活 Docker Scout 时，系统会自动分析您推送的镜像。分析为您提供见解 关于镜像的构成，包括它们包含的包以及 他们暴露于哪些漏洞中。策略评估建立在 Image Analysis 功能，根据规则解释分析结果 由策略定义。
策略定义您的构件应满足的镜像质量标准。 例如，No AGPL v3 licenses 策略会标记包含根据 AGPL v3 许可证分发的软件包的任何镜像。 如果镜像包含此类软件包，则该镜像不符合此策略。 某些策略（例如“无 AGPL v3 许可证”策略）是可配置的。 通过可配置的策略，您可以调整条件以更好地满足组织的需求。
在 Docker Scout 中，策略旨在帮助您将 安全和供应链地位。其他工具专注于提供通行证 或 fail 状态，Docker Scout 策略可视化了微小的增量更改 影响策略状态，即使您的项目不符合策略 要求（还）。通过跟踪失败差距如何随时间变化，您可以 轻松查看您的工件相对于 政策。
策略不一定必须与应用程序安全性和 漏洞。您可以使用策略来衡量和跟踪 供应链管理，例如开源许可证使用和基础 镜像最新性。
策略类型
在 Docker Scout 中，策略派生自策略类型。策略类型包括 定义策略核心参数的模板。您可以比较策略 类型添加到类中，每个策略都充当 实例。
Docker Scout 支持以下策略类型：
Docker Scout 会自动为存储库提供默认策略，其中 已启用，但 SonarQube 质量门控策略除外，该策略要求在使用前与 SonarQube 集成。
您可以从任何支持的策略类型创建自定义策略，或者 如果默认策略不适用于您的项目，请将其删除。了解更多 信息，请参阅 配置策略.
基于严重性的漏洞
Severity-Based Vulnerability （基于严重性漏洞） 策略类型检查您的 工件暴露于已知漏洞中。
默认情况下，此策略仅标记严重性和高严重性漏洞 有可用的修复版本。从本质上讲，这意味着有一个 您可以为不符合此策略的镜像部署的简单修复：升级 vulnerable 软件包添加到包含漏洞修复程序的版本。
如果图片包含一个或多个 超出指定策略条件的漏洞。
您可以通过创建策略的自定义版本来配置此策略的参数。 以下策略参数可在自定义版本中配置：
Age （期限）：自漏洞首次发布以来的最小天数
仅标记具有特定最低期限的漏洞的基本原理是 新发现的漏洞不应导致您的评估 失败，直到你有机会解决它们。
- 严重性：要考虑的严重性级别（默认值：
Critical, High)
仅限可修复的漏洞：是否仅报告 具有可用修复版本的漏洞（默认启用）。
包类型：要考虑的包类型列表。
此选项允许您指定包类型，如 PURL 包类型定义、 ，以便包含在策略评估中。默认情况下，策略 考虑所有包类型。
有关配置策略的更多信息，请参阅配置策略。
合规许可证
Compliant Licenses 策略类型检查您的镜像是否包含 在不适当的许可证下分发的软件包。图片被考虑 如果它们包含一个或多个具有此类许可证的软件包，则为 non-compliant。
您可以配置此策略应注意的许可证列表， 并通过指定允许列表（以 PULL 的形式）来添加例外。 请参阅配置策略。
最新的基础镜像
Up-to-Date Base Images （最新基础镜像） 策略类型检查基础镜像是否 使用是最新的。
如果您曾经使用的标记 Build your image 指向与你正在使用的摘要不同的摘要。如果 摘要不匹配，这意味着您使用的基本镜像已用完 日期。
您的镜像需要出处证明，此策略才能成功 评价。有关更多信息，请参阅无基础镜像数据。
备受瞩目的漏洞
High-Profile Vulnerabilities 策略类型检查您的镜像是否 包含来自 Docker Scout 精选列表中的漏洞。此列表被保留 与新披露的漏洞保持同步，这些漏洞被广泛认可为 要有风险。
该列表包括以下漏洞：
- CVE-2014-0160 （OpenSSL Heartbleed）
- CVE-2021-44228 （Log4Shell） 漏洞
- CVE-2023-38545（cURL SOCKS5 堆缓冲区溢出）
- CVE-2023-44487 （HTTP/2 快速重置）
- CVE-2024-3094（XZ 后门）
- CVE-2024-47176 （OpenPrinting -
cups-browsed) - CVE-2024-47076 （OpenPrinting -
libcupsfilters) - CVE-2024-47175 （OpenPrinting -
libppd) - CVE-2024-47177 （OpenPrinting -
cups-filters)
您可以自定义此策略以更改考虑的 CVE high-profile 的配置策略。自定义配置选项包括：
排除的 CVE：指定您希望此策略忽略的 CVE。
默认值：（不会忽略任何备受瞩目的 CVE）
[]CISA KEV：允许跟踪 CISA 的已知已利用漏洞 （KEV） 目录中的漏洞
CISA KEV 目录包括在野外被积极利用的漏洞。启用后， 该策略标记包含 CISA KEV 目录中的漏洞的镜像。
默认启用。
有关策略配置的更多信息，请参阅配置策略。
供应链鉴证
的 Supply Chain Attestens 策略类型检查您的镜像是否具有 SBOM 和来源证明。
如果镜像缺少 SBOM 认证或 具有 Max Mode Provenance 的 Provenance 证明。为确保合规性， 更新您的 build 命令以在构建时附加这些证明：
$ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .
有关使用证明进行构建的更多信息，请参阅证明。
如果您使用 GitHub Actions 构建和推送镜像， 了解如何配置作以应用 SBOM 和来源证明。
默认非 root 用户
默认情况下，容器作为root具有完整系统的超级用户
管理权限，除非 Dockerfile 指定
其他默认用户。以特权用户身份运行容器会削弱其
运行时安全性，因为这意味着在容器中运行的任何代码都可以执行
管理作。
Default Non-Root User 策略类型检测设置为作为
默认的root用户。为了遵守此策略，镜像必须指定
non-root 用户。镜像不符合此要求
策略。
对于不合规的镜像，评估结果显示rootuser 已为镜像显式设置。这可以帮助您区分
如果rootuser 是隐式的，并且
图片root是有目的地设置的。
以下 Dockerfile 以root默认情况下，尽管没有明确设置：
FROM alpine
RUN echo "Hi"而在下面的例子中，rootuser 显式设置：
FROM alpine
USER root
RUN echo "Hi"注意
此政策仅检查镜像的默认用户（如 镜像配置 blob。即使您指定了非 root 默认用户， 仍然可以在运行时覆盖默认用户，例如通过 使用
--userflag 的docker run命令。
要使您的镜像符合此策略，请使用USERDockerfile 指令设置
没有运行时阶段的 root 权限的默认用户。
以下 Dockerfile 代码片段显示了 compliant 和 不合规的镜像。
FROM alpine AS builder
COPY Makefile ./src /
RUN make build
FROM alpine AS runtime
COPY --from=builder bin/production /app
ENTRYPOINT ["/app/production"]FROM alpine AS builder
COPY Makefile ./src /
RUN make build
FROM alpine AS runtime
COPY --from=builder bin/production /app
USER nonroot
ENTRYPOINT ["/app/production"]已批准的基础镜像
Approved Base Images 策略类型可确保您使用的基础镜像 在您的构建中得到维护和保护。
此策略检查构建中使用的基础镜像是否与任何 策略配置中指定的模式。下表显示了一些 此策略的示例模式。
| 用例 | 模式 |
|---|---|
| 允许来自 Docker Hub 的所有镜像 | docker.io/* |
| 允许所有 Docker 官方镜像 | docker.io/library/* |
| 允许来自特定组织的镜像 | docker.io/orgname/* |
| 允许特定仓库的标签 | docker.io/orgname/repository:* |
允许具有主机名的注册表上的镜像registry.example.com | registry.example.com/* |
| 允许 NodeJS 镜像的 slim 标签 | docker.io/library/node:*-slim |
星号 （） 匹配到后面的字符，或直到结尾
的镜像引用。请注意，*docker.ioprefix 是 required 的
匹配 Docker Hub 镜像。这是 Docker Hub 的注册表主机名。
此策略可通过以下选项进行配置：
已批准的基础镜像源
指定要允许的镜像引用模式。政策 根据这些模式评估基本镜像引用。
默认值：（任何引用都是允许的基础镜像）
[*]仅支持的标签
使用 Docker 官方镜像时仅允许受支持的标签。
启用此选项后，使用官方镜像的不支持标签的镜像 ，因为其基础镜像会触发策略冲突。官方支持的标签 镜像列在存储库的 Supported tags （支持的标签） 部分中 Docker Hub 上的概述。
默认启用。
仅支持的 OS 发行版
仅允许受支持的 Linux 发行版版本的 Docker 官方镜像。
启用此选项后，使用不支持的 Linux 发行版的镜像 已达到使用寿命（例如
ubuntu:18.04） 触发策略冲突。启用此选项可能会导致策略不报告任何数据 如果无法确定作系统版本。
默认启用。
您的镜像需要出处证明，此策略才能成功 评价。有关更多信息，请参阅无基础镜像数据。
SonarQube 质量门
SonarQube 质量门策略类型基于 SonarQube 构建 集成以评估质量 的源代码。此策略通过提取 SonarQube 代码分析 结果导入 Docker Scout。
您可以使用 SonarQube 的质量定义此策略的条件 门。 SonarQube 根据您定义的质量门评估您的源代码 在 SonarQube 中。Docker Scout 将 SonarQube 评估显示为 Docker Scout 政策。
Docker Scout 使用出处证明或org.opencontainers.image.revisionOCI 注释到链接
带有容器镜像的 SonarQube 分析结果。除了启用
SonarQube 集成，您还必须确保您的镜像具有
attestation 或标签。
推送镜像并完成策略评估后， SonarQube 质量入口在 Docker Scout 仪表板中显示为策略，并且 在 CLI 中。
注意
Docker Scout 只能访问集成后创建的 SonarQube 分析 已启用。Docker Scout 无权访问历史评估。触发 启用集成后的 SonarQube 分析和策略评估 在 Docker Scout 中查看结果。
无基础镜像数据
在某些情况下，无法确定有关基础的信息 构建中使用的镜像。在这种情况下，Up-to-Date Base Images （最新基础镜像） 和 Approved Base Images （已批准的基础镜像） 策略将被标记为 No data （无数据）。
在以下情况下会出现这种“无数据”状态：
- Docker Scout 不知道您使用了什么基础镜像标签
- 您使用的基础镜像版本具有多个标签，但并非所有标签都已发布 日期
要确保 Docker Scout 始终了解您的基础镜像，您可以 在构建时附加出处证明。Docker Scout 使用出处证明来找出基础 image version 的