在現代軟體開發流程中，安全已不再是可選項，而是必要條件。GitLab CI/CD 提供了便捷的整合式安全掃描機制，讓開發者得以在開發過程中及早發現並修復安全漏洞。本文將探討如何在 GitLab CI/CD 管線中有效運用七種安全測試型別，包含靜態應用程式安全測試（SAST）、動態應用程式安全測試（DAST）、機密檢測、依賴性掃描、容器掃描、授權合規性檢查以及基礎設施即程式碼（IaC）掃描。透過這些機制的整合，開發團隊可以建構更安全的應用程式，並將安全性融入整個開發生命週期，實踐 DevSecOps 理念。除了個別掃描器的設定方式外，本文也將剖析 GitLab 安全掃描策略的核心概念，包含多層次防禦、易用性、持續改進等原則，以及其仰賴開源工具的策略與優勢。此外，文章也涵蓋了 Docker 模組化封裝的機制、自動更新的優點，以及 GitLab 如何智慧地偵測專案中的程式語言並執行對應的分析工具，讓開發者能更有效率地運用 GitLab 的安全掃描功能，提升軟體交付的安全性與可靠性。
安全掃描：保護你的程式碼
在瞭解如何組態 GitLab CI/CD 管線以驗證專案程式碼是否符合需求後，下一步是新增檢查安全漏洞的工作。這是一個可選步驟，但由於 GitLab 使得將安全掃描新增到管線變得簡單，且除了增加幾分鐘的管線執行時間外幾乎沒有其他副作用，因此建議啟用所有與專案相關的安全掃描器。玄貓將從介紹 GitLab 的一般安全掃描策略開始，這對於理解個別掃描器之前的幾個方面非常有幫助。然後，我們將解釋 GitLab 提供的七種安全測試型別的目的：靜態應用程式安全測試（SAST）、機密檢測、動態應用程式安全測試（DAST）、依賴性掃描、容器掃描、授權遵從性和基礎設施即程式碼（IaC）掃描。
GitLab 的安全掃描策略
GitLab 的安全掃描策略根據幾個基本原則：
- 整合性：所有安全掃描都是直接整合到 CI/CD 管線中，確保每次程式碼變更都會自動進行安全檢查。
- 多層次防護：GitLab 提供多種不同型別的安全測試，涵蓋靜態分析、動態測試、依賴性檢查等，確保全面的安全防護。
- 易用性：掃描結果可以直接在 GitLab 的介面上檢視，並且可以透過簡單的組態來啟用或修改掃描器。
- 持續改進：GitLab 不斷更新和改進其安全掃描功能，確保能夠應對最新的安全威脅。
靜態應用程式安全測試（SAST）
靜態應用程式安全測試（SAST）是一種在程式碼編譯或執行之前進行的分析方法。SAST 主要檢查原始碼中的潛在漏洞，如 SQL 注入、跨站指令碼攻擊（XSS）等。
啟用 SAST
要在 GitLab CI/CD 管線中啟用 SAST，可以在 .gitlab-ci.yml 檔案中新增以下組態：
sast:
stage: test
script:
- gitlab-sast analyze
內容解密：
sast:：定義一個名為sast的工作。stage: test：指定這個工作屬於test階段。script:：定義執行的指令。gitlab-sast analyze：這行指令會觸發 GitLab SAST 分析工具來檢查程式碼中的潛在漏洞。
機密檢測
機密檢測工具會在儲存函式庫中搜尋可能洩露的敏感資訊，如 API 金鑰、密碼等。這些資訊如果被公開，可能會導致嚴重的安全問題。
啟用機密檢測
要在 GitLab CI/CD 管線中啟用機密檢測，可以在 .gitlab-ci.yml 檔案中新增以下組態：
secret_detection:
stage: test
script:
- gitlab-secret-detection scan
內容解密：
secret_detection:：定義一個名為secret_detection的工作。stage: test：指定這個工作屬於test階段。script:：定義執行的指令。gitlab-secret-detection scan：這行指令會觸發 GitLab 機密檢測工具來搜尋儲存函式庫中的敏感資訊。
動態應用程式安全測試（DAST）
動態應用程式安全測試（DAST）是在應用程式執行時進行的測試方法。DAST 主要模擬攻擊者的行為，對執行中的應用程式進行各種攻擊，以發現可能存在的漏洞。
啟用 DAST
要在 GitLab CI/CD 管線中啟用 DAST，可以在 .gitlab-ci.yml 檔案中新增以下組態：
dast:
stage: test
script:
- gitlab-dast analyze
內容解密：
dast:：定義一個名為dast的工作。stage: test：指定這個工作屬於test階段。script:：定義執行的指令。gitlab-dast analyze：這行指令會觸發 GitLab DAST 分析工具來模擬攻擊者對執行中的應用程式進行測試。
Dependencies Scanning
Dependencies Scanning 是一種檢查專案依賴專案中已知漏洞的方法。這些依賴專案可能來自外部函式庫或框架，如果其中包含已知漏洞，可能會對整個專案造成影響。
啟用 Dependencies Scanning
要在 GitLab CI/CD 管線中啟用 Dependencies Scanning，可以在 .gitlab-ci.yml 檔案中新增以下組態：
dependency_scanning:
stage: test
script:
- gitlab-dependency-scanning analyze
內容解密：
dependency_scanning:：定義一個名為dependency_scanning的工作。stage: test：指定這個工作屬於test階段。script:：定義執行的指令。gitlab-dependency-scanning analyze：這行指令會觸發 GitLab Dependencies Scanning 工具來檢查專案依賴專案的已知漏洞。
Container Scanning
Container Scanning 是一種檢查 Docker 映象中已知漏洞的方法。隨著容器技術的普及，確保容器映像的安全性變得越來越重要。
啟用 Container Scanning
要在 GitLab CI/CD 管線中啟用 Container Scanning，可以在 .gitlab-ci.yml 檔案中新增以下組態：
container_scanning:
stage: test
script:
- gitlab-container-scanning analyze
內容解密：
container_scanning:：定義一個名為container_scanning的工作。stage: test：指定這個工作屬於test階段。script:：定義執行的指令。gitlab-container-scanning analyze：這行指令會觸發 GitLab Container Scanning 工具來檢查 Docker 映象中的已知漏洞。
License Compliance
License Compliance 是一種確保專案依賴專案符合授權規範的方法。不合規的授權可能會導致法律問題或商業風險。
啟用 License Compliance
要在 GitLab CI/CD 管線中啟用 License Compliance，可以在 .gitlab-ci.yml 檔案中新增以下組態：
license_management:
stage: test
script:
- gitlab-license-compliance check
內容解密：
license_management:：定義一個名為license_management的工作。stage: test: 指定這個工作屬於 test 階段。- gitlab-license-compliance check: 命令觸發 GitLab License Compliance 工具來檢查專案依賴項是否符合許可規定。
Infrastructure as Code (IaC) Scanning
Infrastructure as Code (IaC) Scanning 是一種檢查基礎設施組態檔案中的潛在漏洞和問題的方法。這些組態檔案通常使用 Terraform、Ansible 或 CloudFormation 工具編寫。
啟用 IaC Scanning
要在 GitLab CI/CD 管線中啟用 IaC Scanning，可以在 .gitlab-ci.yml 檔案中新增以下組態：
iac_scanning:
stage: test
script:
- gitlab-iac-scanning analyze
內容解密：
- iac_scanning : IAC 檢測作業.
- stage : 測試階段.
- script : 控制命令.
- gitlab-iac-scanning analyze : 執行 IaC 掃描.
檔案結構示例
以下是完整管理診斷檔案結構示例:
root/
├── .gitignore # 忽略特設定檔案或目錄.
├── .gitlab-ci.yml # CI/CD 組態檔案.
└── README.md # 專案說明檔案.
未來趨勢與預測
未來，隨著自動化和持續整合/持續交付（CI/CD）流程的普及，更多企業將會將安全掃描納入其開發流程中。GitLab 作為一個強大且靈活的 DevOps 平台，將會繼續提供更多先進的安全功能和掃描工具。企業需要不斷更新和改進其安全策略，以應對日益複雜和多樣化的網路威脅。
GitLab 之安全掃描策略深入解析
GitLab 的安全掃描策略依賴於多種開源的第三方工具，這些工具經過嚴格的研究和審核，確保其品質和可靠性。本文將探討 GitLab 的安全掃描策略，並提供具體的實務案例和技術選型分析。
GitLab 使用開源掃描工具
首先，讓我們來瞭解 GitLab 使用的安全掃描工具。你可能會驚訝地發現，GitLab 所使用的所有安全掃描工具都是第三方開源工具，而非由 GitLab 自行開發的專有軟體。例如，基礎設施即程式碼（Infrastructure as Code, IaC）的掃描由開源工具 Keeping Infrastructure as Code Secure (KICS) 完成，而依賴性掃描則由 Gemnasium 工具處理。
這並不意味著這些第三方工具在品質上輸於 GitLab 自行開發的軟體。事實上，這些開源工具都經過 GitLab 的嚴格研究和審核，確保其能夠成為官方 GitLab 掃描器的一部分。此外，GitLab 會定期審查新的開源安全掃描工具，以決定是否需要替換或補充現有的掃描器。因此，你可以放心地使用這些掃描器來強化你的 CI/CD Pipeline，即使它們的程式碼並非由 GitLab 開發人員撰寫。
專注於安全性的組織或公司所開發的安全掃描器通常比專有軟體少見錯誤。這與開源軟體的一句名言相符：“給予足夠的人眼球，所有錯誤都會變得簡單。”對於安全相關工具來說，找出並修復錯誤尤為重要。使用一個設計不良的安全掃描器可能會讓你產生程式碼已經安全的錯覺，這甚至比完全不知道程式碼的安全狀況更糟。
為何選擇 GitLab 的安全掃描器？
既然這些掃描器都是開源軟體，為何不自己下載並獨立執行呢？事實上，沒有任何限制阻止你這樣做。然而，這樣做並沒有太大意義。GitLab 認可的掃描器非常容易整合到 GitLab CI/CD Pipeline中，而且 GitLab 會自動更新它們以確保你總是執行最新版本（除非你另有指定），而不需要你進行任何操作。如果你已經在 GitLab 中設定了 CI/CD Pipeline，且你的 GitLab 授權等級提供了你所需的掃描器存取許可權，玄貓建議你在 GitLab 中使用這些工具而非獨立執行它們。這樣做可以避免額外的系統管理和維護工作。
支援的語言
要檢視每種 GitLab 安全掃描器支援的所有語言以及所使用的開源工具名稱，請參考官方 GitLab 檔案（https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks）。請注意，這些細節會隨時間變化，因此定期檢查檔案以瞭解哪些新語言被不同型別的掃描器支援是明智之舉。
安全掃描器以 Docker 模組包裝
當一個安全掃描器在你的 GitLab CI/CD Pipeline中執行時，它會在一個 Docker 容器中執行。對於大多數 GitLab 使用者來說，這一點並不重要，但有一些需要了解的影響：
下載延遲：由於Pipeline工作需要下載安全掃描器的 Docker 映像檔，這可能會增加工作執行時間約一分鐘左右。然而，實際延遲取決於你的網路速度以及映像檔是否已被快取。通常這不是問題，因為許多掃描器即使在下載完映像檔後也需要幾分鐘時間才能執行完畢。
執行者要求：任何安全掃描工作必須在使用 Docker 或 Kubernetes 執行者的 GitLab Runner 上執行。如果你使用的是 SaaS 版本的 GitLab（即 gitlab.com），這個問題已經解決：所有 SaaS 提供的 GitLab Runner 都使用其中一種執行者。如果你使用的是自行管理的 GitLab 傳送者組態情況會有所不同。
自動更新：由於每次執行時都會下載最新版本的安全掃描器 Docker 映像檔，因此不必擔心更新安全掃描器。GitLab 確保每個工作都能提取最新版本的映像檔。
不同語言分析工具
某些掃描器如 SAST 和依賴性掃揀需要使用不同語言特定工具來進行分析。GitLab 稱這些語言特定工具為分析器（analyzers）。例如當啟用 SAST 功能於僅包含 Go 語言程式碼之專案時, Gitlab 將執行名為 Semgrep 的 Go 語言感知式 SAST 分析器. 若啟用 SAST 功能於根據 Ruby 的專案時, Gitlab 則執行另一名為 Brakeman 的 Ruby 語言感知式分析器.
無需告知 Gitlab 應該執行哪些分析工具-它能自動偵測專案中的電腦語言並僅執行與該語言相容之分析工具. 捕捉檔是指擁有特定命名或副檔名之檔案存在專案資料函式庫中. 例如若找到任何以 .py 結果之檔案, 他將假設專案包含 Python 語言程式碼並執行針對 Python 的分析工具. 他還會檢視傳統與各種語言之組態檔如 Ruby專案中的 Gemfile 或 Gemfile.lock, Python專案中的 requirements.txt, 或利用 Maven 編譯工具之 Java專案中的 pom.xml.
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title GitLab CI/CD 整合安全掃描實務
package "Docker 架構" {
actor "開發者" as dev
package "Docker Engine" {
component [Docker Daemon] as daemon
component [Docker CLI] as cli
component [REST API] as api
}
package "容器運行時" {
component [containerd] as containerd
component [runc] as runc
}
package "儲存" {
database [Images] as images
database [Volumes] as volumes
database [Networks] as networks
}
cloud "Registry" as registry
}
dev --> cli : 命令操作
cli --> api : API 呼叫
api --> daemon : 處理請求
daemon --> containerd : 容器管理
containerd --> runc : 執行容器
daemon --> images : 映像檔管理
daemon --> registry : 拉取/推送
daemon --> volumes : 資料持久化
daemon --> networks : 網路配置
@enduml
次段落標題：此圖示說明
此圖示說明當啟用 SAST 功能時, 對於 Go 語言程式碼與 Ruby 語言程式碼之處理方式. 對於 Go 語言程式碼, 他將利用 Semgrep 分析工具; 對於 Ruby 語言程式碼則利用 Brakeman 分析工具.
通常情況下, 無需擔心讓電腦語言易於被 Gitalb 偵測-它足夠智慧來處理幾乎所有專案. 嘗試一些設定之後仍無法正確偵測語言之情況下可以參考官方檔案或參考一些實際案例.