持續整合管線

持續整合管線會從應用程式的儲存庫建置可部署的構件。

在建置構件之前,管線會以處理取回要求的相同方式來檢查是否掃描及測試程式碼。 建置構件也會掃描是否有漏洞,並在管線中簽署,然後才在 庫存 中標示為已備妥可供發行及部署。 與取回要求管線不同,Continuous Integration 管線會在建置的每一個階段收集證明及結果構件,例如測試、掃描及簽署。 此資料會與建置的構件產生關聯,並且可以透過部署程序和變更管理來追蹤。

階段和作業

下表列出了在 CI 管道中執行的任務。 此外,此表格還提供下列每一個階段的概觀:

  • 作業或階段: 這是指 .pipeline-config.yaml 配置檔內所定義的階段名稱。

  • 簡要說明: 這會提供在階段執行期間所執行之動作的簡要說明。

  • 允許自訂: 這指出使用者是否有彈性在 .pipeline-config.yaml 檔中插入自訂 Script 來修改或取代階段的預設行為。

  • 預設參考實現:這表明是否DevSecOps管道帶有階段的預定義或預設實作。 值得注意的是,對於某些階段,例如 unit-tests 或者 setup,這DevSecOpspipeline 不提供任何開箱即用的實作。 相反地,使用者必須提供自訂 Script 或自訂程式碼,以符合其應用程式的需求。

  • 證明收集: 這指出階段是否執行標準證明收集。 什麼時候DevSecOps管道為階段提供參考實現,證據收集是開箱即用的。 不過,如果 使用者 選擇修改或取代這些預先定義的階段,則必須確保其自訂實作包括適當的證明集合。 在以下階段,使用者承擔同樣的責任:DevSecOpspipeline 不提供開箱即用的實現,因此需要他們執行證據收集。 該直欄指出負責執行證明收集的實體 (使用者/管線)。

  • 跳過允許 (適用於版本> = v10): 這指出使用者是否可以在 .pipeline-config.yaml 中將 skip 內容設為 true,以拒絕執行此階段。 不過,在使用此特性時,尤其對於設計用於收集證明的階段,建議注意。 跳過這類階段可能會導致遺漏建置的必要證明。

持續整合階段與任務
作業或階段 簡要說明 .pipeline-config.yaml 中允許自訂 預設參照實作 證明收集 跳過允許的
start 設定管線環境。 管線
setup 設定建置和測試環境。 NA
detect-secrets 在應用程式碼上執行偵測密鑰掃描。 管線
test 在應用程式碼上執行單元測試和應用程式測試。 使用者
static-scan 在應用程式碼上執行靜態掃描程式碼。 管線
compliance-checks 在應用程式儲存庫上執行 Code Risk Analyzer 掃描及其他相符性檢查。 管線
peer-review 蒐集關於已合併拉取請求之同儕審查的合規性資料。 管線
containerize 建置構件。 NA
sign-artifact 簽署已建置的構件。 管線
deploy 將建置構件部署至開發環境。 NA
dynamic-scan 在應用程式上執行動態掃描。 管線
acceptance-test 在開發環境上已部署的建置構件上執行接受及整合測試。 使用者
scan-artifact 掃描建置的構件。 管線
release 將建置構件新增至庫存。 NA
finish 收集、建立並將日誌檔、構件及證明上傳至證明櫃。 NA

如需如何使用 .pipeline-config.yaml 檔案來自訂階段的相關資訊,請參閱 自訂 Script管線參數 清單。

階段和證明

下表提供了各類證據與進行收集的管道中特定階段之間的關係。

持續集成階段和相關證據
作業或階段 證明類型
start NA
setup NA
detect-secrets com.ibm.detect_secrets
test com.ibm.unit_tests
static-scan com.ibm.static_scan
compliance-checks com.ibm.code_bom_check, com.ibm.code_cis_check, com.ibm.code_vulnerability_scan, com.ibm.branch_protection
peer-review com.ibm.peer_review
containerize NA
sign-artifact com.ibm.cloud.image_signing
deploy NA
dynamic-scan com.ibm.dynamic_scan
acceptance-test com.ibm.acceptance_tests
scan-artifact com.ibm.cloud.image_vulnerability_scan
release NA
finish com.ibm.pipeline_logs, com.ibm.pipeline_run_data

如需如何使用 collect-evidence Script 在可自訂使用者階段內收集證明的相關資訊,請參閱 collect-evidence Script

偵測密鑰掃描

IBM Detect Secrets 工具可識別在應用程式碼中可見密鑰的位置。 如需為掃描設定儲存庫的相關資訊,請參閱 這裡

靜態程式碼掃描

靜態程式碼掃描階段會在指定的應用程式儲存庫上執行一些靜態程式碼分析器工具。 系統會掃描 pipelinectl save_repo 指令所提供的儲存庫及預設應用程式儲存庫。

您可以使用下列任何方法,將靜態程式碼新增至管線:

  • 將 SonarQube 工具加入您的工具鏈,提供已經執行的 SonarQube 範例名稱 URL,以及憑證。 靜態掃描作業會在指定的儲存庫上執行掃描。

  • 如果您沒有自己的 SonarQube 實例,則管線會在管線執行期間建立 SonarQube 實例。 在靜態掃描階段順利執行之後,您可以存取此實例。

  • 使用 opt-in-gosec 參數來執行 golang 安全檢查的 gosec 掃描。

  • 針對自訂實作,將您自己的靜態掃描程式碼新增至 .pipeline-config.yaml 檔中的靜態掃描自訂階段。

將 SonarQube 掃描新增至管線

如需將 SonarQube 與持續整合管線整合的相關資訊,請參閱 配置 SonarQube

將 gosec 掃描整合新增至管線

使用 gosec 來檢查已掃描儲存庫中的 golang 原始碼。

若要啟用 gosec 掃描,請提供下列參數,並將值設為 1

gosec 掃描參數
名稱 類型 說明 必要或選用
opt-in-gosec text 啟用 gosec 掃描的選項 選用

如需在持續整合管線中設定 gosec 掃描的相關資訊,請參閱 配置 GoSec

使用其他靜態掃描器

如果您想使用自己的靜態掃描實作取代,您可以修改 .pipeline-config.yaml 檔案,並在 static-scan 階段加入自己的 自訂 Script

掃描並移入相符性檢查

合規性掃描和檢查
掃描或檢查 說明
Code Risk Analyzer 漏洞掃描 尋找所有應用程式套件相依關係、容器基本映像檔及作業系統套件的漏洞。 使用 Code Risk Analyzer 工具。
Code Risk Analyzer CIS 檢查 在 Kubernetes 部署資訊清單上執行 配置檢查。 使用 Code Risk Analyzer 工具。
Code Risk Analyzer 物料清單 (BOM) 檢查 所指定儲存庫的 BOM,用於擷取所有相依關係的 pedigree。 這個 BOM 會以不同的粒度收集。 例如,BOM 會擷取建置中使用的基本映像檔清單、基本映像檔中的套件清單,以及在基本映像檔上安裝的應用程式套件清單。 BOM 充當分析結果的基準,並可能用來施行原則閘道。 使用 Code Risk Analyzer 工具。
儲存庫相符性檢查 檢查分支保護設定是否正確。 例如,主要/主要分支應該一律限制強制推送。 如需相關資訊,請參閱 配置 Git Repos and Issue Tracking 儲存庫

這些 Script 會在管線知道的所有應用程式儲存庫上執行。 若要將儲存庫新增至這些掃描,請使用設定階段中提供的 pipelinectl 介面。

有關使用者指令碼階段預期輸出的詳細資訊,請參閱 自訂指令碼

注意:CI 管道不會在標籤上觸發,因為它們不支援 branch protection checkspeer review check 等功能。 如果您選擇在標籤上執行 CI 管道,請確保停用 peer-review-compliancebranch-protection-check 屬性,將其設定為 0。 但是,請注意,在這種情況下,不會針對這些進行證據收集。

建置

在「建置」階段中,您可以建置自己的構件。 雖然管線提供 Docker 映像檔類型構件的部分預設特性,但您可以在此階段中建置任何類型的構件。

使用「管線使用者介面」中的環境變數,為您的建置提供認證、密碼及參數。 您可以在此階段及所有自訂階段中存取這些環境變數。 有關如何在自訂指令碼階段存取參數和秘密的詳細資訊,請參閱 自訂指令碼

構件掃描和簽署

構件掃描和簽署階段提供 Docker 映像檔的預設行為,具有可自訂的步驟:

  • 使用 GPG 金鑰進行映像檔簽署。
  • Container Registry Vulnerability Advisor 掃描。

若要開始使用這些階段,請提供您的構件,讓管線使用 pipelinectl 介面。 您不需要更新建置 Script 和 .pipeline-config.yaml 配置。

如果要使用不同的掃描或簽署程序,或處理 icr.io 中 Docker 映像檔以外的構件,您可以在專案中使用 .pipeline-config.yaml 配置來自訂這些階段。

部署至開發

Deploy 暫置會將建置構件部署至開發環境。

動態掃描

動態程式碼掃描是一種黑盒漏洞掃描形式,可讓軟體團隊掃描執行中的應用程式並識別漏洞。

在成功部署至 dev 環境之後,「動態掃描」階段會在 Deploy to dev 階段之後立即執行。

依預設,管線提供執行「Zed Attack Proxy (ZAP) 掃描」的支援,這是在 OWASP 的保護傘下維護的免費開放程式碼滲透測試工具。 它同時執行 API 和使用者介面動態掃描,兩者都可以在範例 hello-compliance-app 上執行。

若要執行動態掃描,請將管線參數 opt-in-dynamic-scan 設為非空值。 若要停用階段執行動態掃描,請將管線參數 opt-in-dynamic-scan 設為空白。 如需設定管線參數的相關資訊,請參閱 管線參數

CI 管線會根據嚴重性在「問題儲存庫」中建立問題。 附加至問題的標籤指出漏洞的嚴重性。

ZAP API 掃描

ZAP API 會掃描應用程式端點,以找出可能的資料洩漏、內容類型錯誤、外部重新導向、程式碼注入、SQL 注入、遠端 OS 指令注入,以及應用程式所公開的其他漏洞。 ZAP API 掃描可協助開發人員在階段或測試環境中偵測這些漏洞,並在應用程式部署至正式作業環境之前修正這些漏洞,以保護應用程式的安全。

ZAP API 掃描需要下列輸入,才能掃描您的應用程式:

  • Swagger 定義檔案 - 描述應用程式所揭露的 HTTP API 及其相關參數。
  • API 金鑰-向 API 端點進行鑑別所需的鑑別記號。
  • API 端點-來自您要 ZAP 掃描之 Swagger 定義的端點。
  • 排除的 URL-ZAP 掃描器要忽略的 URL。

ZAP API 掃描器使用所提及的輸入來執行掃描並產生報告。

opt-in-dynamic-api-scan 設為非空白值,以執行 ZAP API 掃描。 若要拒絕,請將此參數設為空白。

ZAP 使用者介面掃描

ZAP UI 會掃描應用程式的端點,以偵測網頁本身存在的漏洞,例如設定不安全的 Cookie、不當的快取標頭設定、跨網域檔案包含、不當的 CORS 設定,以及應用程式所暴露的其他漏洞。

使用者介面掃描的運作方式與 API 掃描類似,但它們使用使用者介面測試 Script 而非 Swagger 檔案。 使用者介面測試 Script 會啟動透過 ZAP 掃描器 Proxy 配置成 Proxy 的遠端控制瀏覽器,並針對使用者介面端點執行使用者介面測試。 執行 ZAP 使用者介面測試的程序如下:

  • 將測試 Script 複製到 ZAP Scanner 儲存器。
  • 執行 ZAP Proxy。
  • 執行 zap 測試 Script。

ZAP Proxy 會記錄資料流量,並探索要掃描的端點。 掃描完成之後,Proxy 會產生報告,並以與 ZAP API 掃描相同的方式產生問題。

opt-in-dynamic-ui-scan 設為非空白值,以執行 ZAP API 掃描。 若要拒絕,請將此參數設為空白。

  • 針對自訂實作,將您自己的動態掃描程式碼新增至 .pipeline-config.yaml 檔中的動態掃描自訂階段。

如需 ZAP API 掃描和 ZAP 使用者介面掃描的相關資訊,請參閱 配置 ZAP 掃描

發貨至庫存

使用 release to Inventory 使用者 Script 階段,以使用 cocoa inventory add CLI 指令將構件新增至庫存。 如需指令的相關資訊,請參閱 cocoa inventory add 主題。

如果您想要在管線中發生問題時跳過庫存更新,請使用下列環境變數來檢查管線的狀態。 在更新庫存之前檢查其狀態:

  • skip-inventory-update-on-failure 來自管線的接受環境變數,以指定是否應完成庫存更新。
  • 如果管線執行中有任何階段失敗,則 one-pipeline-status 設為 1

您可以使用 pipelinectl 介面,利用 list_reposload_repolist_artifactsload_artifact 指令來存取您的儲存庫和構件。 如需指令的相關資訊,請參閱 pipelinectl 文件。

在建置上收集法規遵循資料

當管線順利執行時,您可以收集建置的相關資訊。

在所有檢查、掃描、測試及構件登入證明櫃時,都會收集證明。 管線日誌檔也會連同管線資料本身一起儲存至包含 Tekton 定義的鎖定器。 在此步驟中也會收集同層級檢閱的相符性資料。 管線會使用 pipelinectl 來搜尋具有自前次建置以來已合併之取回要求的儲存庫。 它也會檢查其檢閱狀態,將它儲存為構件,並根據結果來建立證明。

最終 Script 是根據證明狀態將管道狀態標示為綠色或紅色的評估器。 如果它們包含任何失敗,則持續整合執行會標示為紅色。