Docker Scout 政策評估入門

在軟體供應鏈管理中，維護構件的安全性和可靠性是首要任務。Docker Scout 中的政策評估在現有分析功能的基礎上引入了控制層。它允許您為構件定義供應鏈規則，並幫助您追蹤構件相對於您的規則和閾值的表現，隨著時間的推移。

瞭解如何使用政策評估來確保您的構件符合既定的最佳實務。

政策評估的運作方式

當您為儲存庫啟用 Docker Scout 時，您推送的映像檔會自動進行分析。分析讓您深入瞭解映像檔的組成，包括它們包含哪些軟體包以及它們面臨哪些弱點。政策評估建立在映像檔分析功能的基礎上，根據政策定義的規則來解讀分析結果。

政策定義了您的構件應該滿足的映像檔品質標準。例如，**沒有 AGPL v3 授權**政策會標記任何包含以 AGPL v3 授權發佈的軟體包的映像檔。如果映像檔包含此類軟體包，則該映像檔不符合此政策。某些政策（例如**沒有 AGPL v3 授權**政策）是可以設定的。可設定的政策允許您調整標準以更好地滿足您組織的需求。

在 Docker Scout 中，政策旨在幫助您提升您的安全性和供應鏈狀況。其他工具專注於提供通過或失敗狀態，而 Docker Scout 政策則可視化小的、漸進式的變更如何影響政策狀態，即使您的構件（尚）未滿足政策要求。透過追蹤失敗差距如何隨時間變化，您可以更輕鬆地瞭解您的構件相對於政策是在改進還是在惡化。

政策不一定與應用程式安全性和弱點相關。您也可以使用政策來衡量和追蹤供應鏈管理的其他方面，例如開放原始碼授權使用和基礎映像檔的最新狀態。

政策類型

在 Docker Scout 中，「*政策*」源自「*政策類型*」。政策類型是定義政策核心參數的範本。您可以將政策類型與物件導向程式設計中的類別進行比較，每個政策都充當從其對應的政策類型建立的實例。

Docker Scout 支援下列政策類型

• 基於嚴重性的弱點
• 相容的授權
• 最新的基礎映像檔
• 高風險弱點
• 供應鏈證明
• 預設非 root 使用者
• 已核准的基礎映像檔
• SonarQube Quality Gates

Docker Scout 會自動為啟用它的儲存庫提供預設政策，但 SonarQube Quality Gates 政策除外，該政策需要在使用前與 SonarQube 整合。

您可以從任何支援的政策類型建立自訂政策，或者如果預設政策不適用於您的專案，則可以將其刪除。如需詳細資訊，請參閱設定政策。

基於嚴重性的弱點

**基於嚴重性的弱點**政策類型會檢查您的構件是否暴露於已知弱點。

預設情況下，此政策僅標記存在修復版本的嚴重和高嚴重性弱點。基本上，這表示您可以為不符合此政策的映像檔部署簡單的修復程式：將弱點軟體包升級到包含弱點修復程式的版本。

如果映像檔包含一個或多個不符合指定政策標準的弱點，則該映像檔將被視為不符合此政策。

您可以透過建立自訂版本的政策來設定此政策的參數。在自訂版本中可以設定下列政策參數

• **年齡**：自弱點首次發佈以來的最短天數

  僅標記特定最短年齡的弱點的基本原理是，新發現的弱點不應導致您的評估失敗，直到您有機會解決它們為止。

• **嚴重性**：要考慮的嚴重性級別（預設值：`嚴重、高`）

• **僅可修復的弱點**：是否僅報告具有可用修復版本的弱點（預設情況下啟用）。

• **軟體包類型**：要考慮的軟體包類型清單。

  此選項允許您指定要包含在政策評估中的軟體包類型，如PURL 軟體包類型定義。

  相容的授權

  相容的授權原則類型會檢查您的映像檔是否包含以不適當的授權發佈的軟體套件。如果映像檔包含一個或多個具有此類授權的套件，則視為不相容。

  您可以設定此原則應注意的授權清單，並透過指定允許清單（以 PURL 的形式）來新增例外。請參閱設定原則。

  最新的基礎映像檔

  最新的基礎映像檔原則類型會檢查您使用的基礎映像檔是否為最新版本。

  如果您用於建置映像檔的標籤指向的摘要與您使用的摘要不同，則映像檔將被視為不符合此原則。如果摘要不符，則表示您使用的基礎映像檔已過時。

  您的映像檔需要來源證明，此原則才能成功評估。如需更多資訊，請參閱沒有基礎映像檔資料。

  高風險弱點

  高風險漏洞原則類型會檢查您的映像檔是否包含 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 被視為高風險。自訂設定選項包括：

  • 排除的 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"

  ...注意

  此原則僅檢查映像檔設定區塊中設定的映像檔預設使用者。即使您指定了非 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.io 前綴才能比對 Docker Hub 映像檔。這是 Docker Hub 的註冊表主機名稱。

  此原則可透過下列選項進行設定：

  • 已核准的基礎映像檔來源

    指定您要允許的映像檔參考模式。此原則會根據這些模式評估基礎映像檔參考。

    預設值：[*]（任何參考都是允許的基礎映像檔）

  • 僅支援的標籤

    使用 Docker 官方映像檔時，僅允許支援的標籤。

    啟用此選項後，使用官方映像檔不支援標籤作為其基礎映像檔的映像檔會觸發原則違規。Docker Hub 上儲存庫概觀的**支援的標籤**區段中列出了官方映像檔支援的標籤。

    預設為啟用。

  • 僅支援的作業系統發行版本

    僅允許支援的 Linux 發行版本版本的 Docker 官方映像檔。

    啟用此選項後，使用已到達生命週期結束的不支援 Linux 發行版本（例如 ubuntu:18.04）的映像檔會觸發原則違規。

    如果無法判斷作業系統版本，啟用此選項可能會導致原則回報沒有資料。

    預設為啟用。

  您的映像檔需要來源證明，此原則才能成功評估。如需更多資訊，請參閱沒有基礎映像檔資料。

  SonarQube Quality Gates

  SonarQube Quality Gates 策略類型建基於 SonarQube 整合，用於評估您的原始碼品質。此策略透過將 SonarQube 程式碼分析結果導入 Docker Scout 來運作。

  您可以使用 SonarQube 的 品質閘門 來定義此策略的標準。SonarQube 會根據您在 SonarQube 中定義的品質閘門來評估您的原始碼。Docker Scout 會將 SonarQube 評估結果顯示為 Docker Scout 策略。

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

  

  推送映像並完成策略評估後，SonarQube 品質閘門的結果會在 Docker Scout 儀表板和 CLI 中顯示為策略。

  ...注意

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

  沒有基礎映像檔資料

  在某些情況下，無法判斷建置中使用的基礎映像的相關資訊。在這種情況下，**最新基礎映像** 和 **已核准的基礎映像** 策略會被標記為 **無資料**。

  出現「無資料」狀態的原因如下：

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

  為了確保 Docker Scout 始終知道您的基礎映像，您可以在建置時附加 來源證明。Docker Scout 使用來源證明來找出基礎映像版本。