Docker Scout 策略評估入門

在軟體供應鏈管理中,維護工件的安全性和可靠性是重中之重。Docker Scout 中的策略評估在現有分析功能的基礎上引入了一層控制。它允許您為工件定義供應鏈規則,並幫助您跟蹤工件隨時間相對於您的規則和閾值的表現。

瞭解如何使用策略評估來確保您的工件符合既定的最佳實踐。

策略評估如何工作

當您為儲存庫啟用 Docker Scout 時,您推送的映象會被自動分析。分析結果讓您深入瞭解映象的組成,包括它們包含的包以及它們面臨的漏洞。策略評估建立在映象分析功能之上,根據策略定義的規則解釋分析結果。

策略定義了您的工件應滿足的映象質量標準。例如,**無 AGPL v3 許可**策略會標記任何包含以 AGPL v3 許可分發的包的映象。如果映象包含此類包,則該映象不符合此策略。某些策略,例如**無 AGPL v3 許可**策略,是可配置的。可配置策略允許您調整標準以更好地滿足您組織的需求。

在 Docker Scout 中,策略旨在幫助您提高安全性和供應鏈地位。與其他工具專注於提供透過或失敗狀態不同,Docker Scout 策略可視化了微小的增量變化如何影響策略狀態,即使您的工件尚未滿足策略要求。透過跟蹤失敗差距隨時間的變化,您可以更容易地看到您的工件相對於策略是正在改善還是正在惡化。

策略不一定必須與應用程式安全和漏洞相關。您還可以使用策略來衡量和跟蹤供應鏈管理的其他方面,例如開源許可使用情況和基礎映象的最新程度。

策略型別

在 Docker Scout 中,一個*策略*是從一個*策略型別*派生出來的。策略型別是定義策略核心引數的模板。您可以將策略型別與面向物件程式設計中的類進行比較,每個策略都充當從其相應策略型別建立的例項。

Docker Scout 支援以下策略型別

Docker Scout 會自動為啟用它的儲存庫提供預設策略,但 SonarQube 質量門禁策略除外,該策略在使用前需要與 SonarQube 整合

您可以根據任何受支援的策略型別建立自定義策略,或者刪除不適用於您專案的預設策略。有關更多資訊,請參閱配置策略

基於嚴重性的漏洞

基於嚴重性的漏洞策略型別檢查您的工件是否暴露於已知漏洞。

預設情況下,此策略僅標記具有可用修復版本的嚴重和高危漏洞。從本質上講,這意味著對於不符合此策略的映象,您可以部署一個簡單的修復:將易受攻擊的包升級到包含漏洞修復的版本。

如果映象包含一個或多個不符合指定策略標準的漏洞,則認為該映象不符合此策略。

您可以透過建立策略的自定義版本來配置此策略的引數。以下策略引數在自定義版本中可配置:

  • 年齡:漏洞首次釋出以來的最短天數

    只標記達到一定最小年齡的漏洞的理由是,新發現的漏洞不應導致您的評估失敗,直到您有機會解決它們。

  • 嚴重性:要考慮的嚴重性級別(預設:Critical, High
  • 僅可修復漏洞:是否僅報告具有可用修復版本的漏洞(預設啟用)。

  • 包型別:要考慮的包型別列表。

    此選項允許您指定要包含在策略評估中的包型別,作為 PURL 包型別定義。預設情況下,該策略會考慮所有包型別。

有關配置策略的更多資訊,請參閱配置策略

合規許可

合規許可策略型別檢查您的映象是否包含以不適當許可分發的包。如果映象包含一個或多個具有此類許可的包,則認為該映象不合規。

您可以配置此策略應查詢的許可列表,並透過指定允許列表(以 PURL 形式)新增例外。請參閱配置策略

最新基礎映象

最新基礎映象策略型別檢查您使用的基礎映象是否最新。

如果用於構建映象的標籤指向的摘要與您正在使用的摘要不同,則認為該映象不符合此策略。如果摘要不匹配,則表示您正在使用的基礎映象已過時。

您的映象需要出處證明才能成功評估此策略。有關更多資訊,請參閱無基礎映象資料

高危漏洞

高危漏洞策略型別檢查您的映象是否包含來自 Docker Scout 精選列表中的漏洞。此列表會及時更新,以包含廣泛認為具有風險的新披露漏洞。

該列表包括以下漏洞:

您可以自定義此策略,透過配置策略來更改被視為高危的 CVE。自定義配置選項包括:

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

    預設值:[](不忽略任何高危 CVE)

  • CISA KEV:啟用跟蹤 CISA 已知被利用漏洞 (KEV) 目錄中的漏洞

    CISA KEV 目錄包含野外正在積極利用的漏洞。啟用後,此策略會標記包含 CISA KEV 目錄中漏洞的映象。

    預設啟用。

有關策略配置的更多資訊,請參閱配置策略

供應鏈證明

供應鏈證明策略型別檢查您的映象是否具有SBOM出處證明。

如果映象缺少 SBOM 證明或具有*最大模式*出處的出處證明,則認為它不合規。為確保合規性,請更新您的構建命令以在構建時附加這些證明:

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

有關使用證明構建的更多資訊,請參閱證明

如果您使用 GitHub Actions 構建和推送映象,請了解如何配置操作以應用 SBOM 和出處證明。

預設非 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.example.com/*
允許 NodeJS 映象的 slim 標籤docker.io/library/node:*-slim

星號 (*) 匹配直到緊隨其後的字元,或直到映象引用的末尾。請注意,為了匹配 Docker Hub 映象,需要 docker.io 字首。這是 Docker Hub 的登錄檔主機名。

此策略可配置以下選項:

  • 批准的基礎映象來源

    指定您要允許的映象引用模式。策略會根據這些模式評估基礎映象引用。

    預設值:[*](任何引用都是允許的基礎映象)

  • 僅受支援的標籤

    使用 Docker 官方映象時僅允許受支援的標籤。

    啟用此選項後,使用官方映象不支援的標籤作為其基礎映象的映象會觸發策略違規。官方映象的受支援標籤列在 Docker Hub 上的儲存庫概覽的**受支援標籤**部分。

    預設啟用。

  • 僅受支援的作業系統分發版

    僅允許受支援的 Linux 分發版版本的 Docker 官方映象。

    啟用此選項後,使用已達到生命週期結束的(例如 ubuntu:18.04)不受支援的 Linux 分發版的映象會觸發策略違規。

    啟用此選項可能會導致策略在無法確定作業系統版本時報告無資料。

    預設啟用。

您的映象需要出處證明才能成功評估此策略。有關更多資訊,請參閱無基礎映象資料

SonarQube 質量門禁

SonarQube 質量門禁策略型別建立在 SonarQube 整合之上,用於評估您的原始碼質量。此策略透過將 SonarQube 程式碼分析結果攝取到 Docker Scout 來工作。

您使用 SonarQube 的質量門禁來定義此策略的標準。SonarQube 會根據您在 SonarQube 中定義的質量門禁評估您的原始碼。Docker Scout 將 SonarQube 評估作為 Docker Scout 策略呈現。

Docker Scout 使用出處證明或 org.opencontainers.image.revision OCI 註釋將 SonarQube 分析結果與容器映象連結起來。除了啟用 SonarQube 整合之外,您還必須確保您的映象具有證明或標籤。

Git commit SHA links image with SonarQube analysis

一旦您推送映象並完成策略評估,SonarQube 質量門禁的結果將作為策略顯示在 Docker Scout 控制面板和 CLI 中。

注意

Docker Scout 只能訪問在整合啟用後建立的 SonarQube 分析。Docker Scout 無法訪問歷史評估。在啟用整合後觸發 SonarQube 分析和策略評估,以在 Docker Scout 中檢視結果。

無基礎映象資料

在某些情況下,無法確定構建中使用的基礎映象資訊。在這種情況下,最新基礎映象批准的基礎映象策略會被標記為**無資料**。

出現“無資料”狀態的原因是:

  • Docker Scout 不知道您使用了哪個基礎映象標籤
  • 您使用的基礎映象版本有多個標籤,但並非所有標籤都已過時

為確保 Docker Scout 始終了解您的基礎映象,您可以在構建時附加出處證明。Docker Scout 使用出處證明來查詢基礎映象版本。