Docker Scout 中的策略评估入门

目录

在软件供应链管理中，维护制品的安全性和可靠性是重中之重。Docker Scout 中的策略评估在现有分析功能之上引入了额外控制层。它允许您为制品定义供应链规则，并帮助您随时间推移跟踪制品相对于您设置的规则和阈值的表现。

了解如何使用策略评估来确保您的制品符合既定的最佳实践。

策略评估工作原理

当您为仓库激活 Docker Scout 时，您推送的镜像会自动分析。分析会提供关于镜像组成的洞察，包括它们包含哪些软件包以及面临哪些漏洞。策略评估基于镜像分析功能，根据策略定义的规则解释分析结果。

策略定义了您的制品应满足的镜像质量标准。例如，不允许 AGPL v3 许可证策略会标记包含根据 AGPL v3 许可证分发的软件包的任何镜像。如果镜像包含此类软件包，则该镜像不符合此策略。某些策略（例如不允许 AGPL v3 许可证策略）是可配置的。可配置策略允许您调整标准，以更好地匹配您的组织需求。

在 Docker Scout 中，策略旨在帮助您逐步提升安全和供应链地位。与其他工具专注于提供通过或失败状态不同，Docker Scout 策略即使在您的制品尚未满足策略要求时，也能可视化微小增量变化如何影响策略状态。通过跟踪失败差距随时间的变化，您可以更轻松地查看制品相对于策略是正在改进还是恶化。

策略不必仅与应用程序安全和漏洞相关。您也可以使用策略来衡量和跟踪供应链管理的其他方面，例如开源许可证的使用以及基础镜像是否最新。

策略类型

在 Docker Scout 中，一个策略派生自一个策略类型。策略类型是定义策略核心参数的模板。您可以将策略类型比作面向对象编程中的类，每个策略都是由其相应策略类型创建的一个实例。

Docker Scout 支持以下策略类型

Docker Scout 会自动为启用它的仓库提供默认策略，但 SonarQube Quality Gates 策略除外，该策略需要在使用前与 SonarQube 集成。

您可以根据任何受支持的策略类型创建自定义策略，或者如果某个默认策略不适用于您的项目，则可以删除它。有关更多信息，请参阅配置策略。

基于严重性的漏洞

基于严重性的漏洞策略类型检查您的制品是否暴露于已知漏洞。

默认情况下，此策略仅标记具有可用修复版本的严重和高危漏洞。本质上，这意味着对于未能通过此策略的镜像，有一个简单的修复方法：将存在漏洞的软件包升级到包含该漏洞修复的更新版本。

如果镜像包含一个或多个不符合指定策略标准的漏洞，则认为该镜像不符合此策略。

您可以通过创建策略的自定义版本来配置此策略的参数。自定义版本中可配置以下策略参数

  • 时效：自漏洞首次发布以来的最小天数

    仅标记具有一定最小时间跨度的漏洞的理由是，新发现的漏洞不应导致您的评估失败，直到您有机会处理它们。

  • 严重性：要考虑的严重性级别（默认：Critical, High）

  • 仅可修复漏洞：是否仅报告具有可用修复版本的漏洞（默认为启用）。

  • 软件包类型：要考虑的软件包类型列表。

    此选项允许您指定要包含在策略评估中的软件包类型，作为PURL 软件包类型定义。默认情况下，策略会考虑所有软件包类型。

有关配置策略的更多信息，请参阅配置策略。

合规许可证

合规许可证策略类型检查您的镜像是否包含在不适当许可证下分发的软件包。如果镜像包含一个或多个此类许可证的软件包，则认为该镜像不合规。

您可以配置此策略应注意的许可证列表，并通过指定允许列表（以 PURL 形式）添加例外。请参阅配置策略。

最新的基础镜像

最新的基础镜像策略类型检查您使用的基础镜像是否为最新。

如果用于构建镜像的标签指向的摘要与您当前使用的摘要不同，则认为镜像不符合此策略。如果摘要不匹配，则表示您使用的基础镜像已过时。

您的镜像需要来源证明，此策略才能成功评估。有关更多信息，请参阅无基础镜像数据。

高危漏洞

高危漏洞策略类型检查您的镜像是否包含来自 Docker Scout 精选列表的漏洞。此列表会随新披露的、被广泛认为是高风险的漏洞而更新。

该列表包括以下漏洞

您可以通过配置此策略来自定义哪些 CVE 被视为高危。自定义配置选项包括

  • 排除的 CVE：指定您希望此策略忽略的 CVE。

    默认值：[]（不忽略任何高危 CVE）

  • CISA KEV：启用跟踪来自 CISA 已知被利用漏洞 (KEV) 目录的漏洞

    CISA KEV 目录包含在野外被积极利用的漏洞。启用后，此策略会标记包含来自 CISA KEV 目录漏洞的镜像。

    默认为启用。

有关策略配置的更多信息，请参阅配置策略。

供应链证明

软件供应链证明 策略类型用于检查您的镜像是否包含 SBOM 和 provenance 证明。

如果镜像缺少 SBOM 证明，或者缺少带有 max mode provenance 的 provenance 证明，则会被视为不符合规范。为确保合规性，请更新您的构建命令以在构建时附加这些证明。

$ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .

有关使用证明进行构建的更多信息，请参阅 证明。

如果您正在使用 GitHub Actions 构建并推送镜像，了解如何 配置该操作 以应用 SBOM 和 provenance 证明。

默认非 Root 用户

默认情况下，容器以 root 超级用户身份运行，在容器内拥有完整的系统管理权限，除非 Dockerfile 指定了不同的默认用户。以特权用户身份运行容器会削弱其运行时安全性，因为这意味着在容器中运行的任何代码都可以执行管理操作。

默认非 Root 用户 策略类型用于检测设置为以默认 root 用户身份运行的镜像。为符合此策略，镜像必须在镜像配置中指定一个非 root 用户。如果镜像未为运行时阶段指定一个非 root 的默认用户，则不符合此策略。

对于不符合规范的镜像，评估结果会显示镜像是否显式设置了 root 用户。这有助于您区分因 root 用户是隐式设置的镜像导致的策略违规，以及因 root 是故意设置的镜像导致的违规。

以下 Dockerfile 默认以 root 身份运行，尽管没有显式设置：

FROM alpine
RUN echo "Hi"

而在以下情况中，则显式设置了 root 用户：

FROM alpine
USER root
RUN echo "Hi"

注意

此策略仅检查镜像的默认用户，如镜像配置 blob 中所设置的。即使您确实指定了非 root 的默认用户，仍然可以在运行时覆盖默认用户，例如，通过在 docker run 命令中使用 --user 标志。

为使您的镜像符合此策略，请使用 USER Dockerfile 指令，为运行时阶段设置一个不具有 root 权限的默认用户。

以下 Dockerfile 代码片段显示了符合规范的镜像和不符合规范的镜像之间的区别。

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"]

批准的基础镜像

已批准的基础镜像 策略类型确保您在构建中使用的基础镜像得到维护且安全。

此策略检查您在构建中使用的基础镜像是否与策略配置中指定的任何模式匹配。下表显示了此策略的一些示例模式。

用例模式
允许来自 Docker Hub 的所有镜像docker.io/*
允许所有 Docker 官方镜像docker.io/library/*
允许来自特定组织的镜像docker.io/orgname/*
允许特定仓库的标签docker.io/orgname/repository:*
允许主机名为 registry.example.com 的 registry 上的镜像registry.example.com/*
允许 NodeJS 镜像的 slim 标签docker.io/library/node:*-slim

星号 (*) 匹配直到其后出现的字符，或匹配到镜像引用结束。请注意，为了匹配 Docker Hub 镜像，docker.io 前缀是必需的。这是 Docker Hub 的 registry 主机名。

此策略可通过以下选项进行配置：

  • 已批准的基础镜像源

    指定您希望允许的镜像引用模式。策略会根据这些模式评估基础镜像引用。

    默认值：[*]（任何引用都是允许的基础镜像）

  • 仅支持的标签

    使用 Docker 官方镜像时，仅允许受支持的标签。

    启用此选项后，使用官方镜像的非受支持标签作为基础镜像的镜像会触发策略违规。官方镜像的受支持标签列在 Docker Hub 上仓库概述的 **Supported tags** 部分中。

    默认为启用。

  • 仅支持的操作系统发行版

    仅允许受支持的 Linux 发行版版本的 Docker 官方镜像。

    启用此选项后，使用已达到生命周期结束的非受支持 Linux 发行版（例如 ubuntu:18.04）的镜像会触发策略违规。

    如果无法确定操作系统版本，启用此选项可能会导致策略报告无数据。

    默认为启用。

您的镜像需要来源证明，此策略才能成功评估。有关更多信息，请参阅无基础镜像数据。

SonarQube 质量门

SonarQube 质量门 策略类型基于 SonarQube 集成 构建，用于评估您的源代码质量。此策略通过将 SonarQube 代码分析结果导入 Docker Scout 来工作。

您使用 SonarQube 的 质量门 来定义此策略的标准。 SonarQube 会根据您在 SonarQube 中定义的质量门来评估您的源代码。 Docker Scout 会将 SonarQube 的评估结果呈现为 Docker Scout 策略。

Docker Scout 使用 provenance 证明或 org.opencontainers.image.revision OCI 注解将 SonarQube 分析结果与容器镜像关联起来。除了启用 SonarQube 集成外，您还必须确保您的镜像具有该证明或该标签。

Git commit SHA links image with SonarQube analysis

推送镜像并完成策略评估后，SonarQube 质量门的结果将在 Docker Scout Dashboard 和 CLI 中显示为一项策略。

注意

Docker Scout 只能访问在集成启用后创建的 SonarQube 分析结果。Docker Scout 无法访问历史评估结果。启用集成后，触发 SonarQube 分析和策略评估以在 Docker Scout 中查看结果。

无基础镜像数据

在某些情况下，无法确定您在构建中使用的基础镜像的信息。在这种情况下，Up-to-Date Base Images 和 Approved Base Images 策略会被标记为 无数据。

出现“无数据”状态的情况包括：

  • Docker Scout 不知道您使用了哪个基础镜像标签
  • 您使用的基础镜像版本有多个标签，但并非所有标签都已过时。

为确保 Docker Scout 始终了解您的基础镜像，您可以在构建时附加 provenance 证明。Docker Scout 使用 provenance 证明来确定基础镜像版本。

页面选项