2024年07月26日玄貓（BlackCat）

GitLab 安全掃描策略與實務應用解析

本文探討 GitLab 的安全掃描策略，涵蓋多語言支援、分析器選擇、Pipeline 整合、漏洞報告與第三方工具整合等導向。文章以 Python 專案為例，詳細說明 SAST 掃描的運作機制，並解析 Semgrep 和 Bandit 兩種分析器的技術原理。此外，文章也探討了 GitLab 的三種安全報告型別，並提供

DevOps 資安

GitLab CI/CD SAST DAST 安全掃描 Pipeline

在現今軟體開發生命週期中，安全議題已成為不可忽視的一環。GitLab 提供的整合式安全掃描工具，讓開發者得以在開發過程中及早發現並修復潛在漏洞，有效降低資安風險。這些工具支援多種程式語言，並可根據專案特性選擇合適的分析器。本文將探討 GitLab 安全掃描策略，並結合實際案例進行分析，協助開發者更有效地運用這些工具。GitLab 的多語言支援特性可自動偵測專案使用的程式語言，並執行對應的分析器。以 Python 專案為例，啟用 SAST 後，GitLab 會使用 Semgrep 和 Bandit 進行程式碼掃描。雖然可能產生重複結果，卻能更全面地找出潛在問題。舉例來說，若程式碼中存在 temp_dir = '/tmp' 這樣的寫法，Semgrep 和 Bandit 都能檢測出此路徑設定的安全性問題，提醒開發者使用更安全的 tempfile 模組。值得注意的是，GitLab 的安全掃描並不會中斷 Pipeline 的執行。即使掃描出漏洞，Pipeline 仍會繼續執行後續階段，讓開發團隊能完整掌握所有掃描結果，再決定後續處理方式。除了內建工具，GitLab 也支援第三方安全掃描工具的整合，例如 Veracode，可透過設定 API 請求將其整合至 Pipeline 中，強化整體安全性。GitLab 提供三種安全報告：脆弱性報告、合規性報告和依賴性報告，協助開發者全面掌握專案的安全性狀態。

GitLab 安全掃描策略解析

在現代軟體開發中，安全性始終是最重要的考量之一。GitLab 提供了多種安全掃描工具，幫助開發者在不同階段檢測並修復潛在的安全漏洞。這些工具不僅能夠檢測多種程式語言的程式碼，還能根據特定語言和掃描器型別選擇最適合的分析器。接下來，玄貓將探討 GitLab 的安全掃描策略，並提供實際案例和深度分析。

多語言支援與分析器選擇

GitLab 支援在同一專案中使用多種程式語言，並能自動檢測這些語言。對於每種語言，GitLab 會執行相應的分析器，假設該分析器存在。例如，啟用 SAST（靜態應用程式安全測試）後，GitLab 會針對 Python 程式碼執行 Semgrep 和 Bandit 分析器。如果這兩個分析器都檢測到相同的問題，報告中可能會出現重複結果。雖然這會增加報告的複雜度，但確保能夠發現更多潛在漏洞。

具體案例：Python 專案中的 SAST 掃描

假設我們有一個 Python 專案，其中包含一段可能存在安全漏洞的程式碼：

temp_dir = '/tmp'

在這個例子中，temp_dir 是一個臨時目錄路徑。如果我們啟用 SAST 掃描，GitLab 會執行 Semgrep 和 Bandit 分析器來檢測這段程式碼中的潛在問題。

內容解密：

Semgrep 分析器：
- 作用：Semgrep 是一個快速且準確的靜態分析工具，主要用於檢測常見的安全漏洞和反模式。
- 邏輯：它會根據預定義的規則函式庫來檢查程式碼中的潛在問題。例如，它可能會檢查是否有未處理的例外或硬編碼的路徑。
- 技術原理：Semgrep 使用模式比對技術來檢查程式碼，這使得它能夠快速且準確地找到問題。
Bandit 分析器：
- 作用：Bandit 是專為 Python 設計的靜態分析工具，專注於檢測安全漏洞。
- 邏輯：它會根據 Python 安全最佳實踐來檢查程式碼中的潛在問題。例如，它可能會檢查是否有未正確處理的檔案操作。
- 技術原理：Bandit 使用 Abstract Syntax Tree (AST) 分析技術來檢查程式碼，這使得它能夠深入瞭解程式碼結構。

漏洞掃描不中斷 Pipeline

GitLab 的安全掃描工具有其獨特的運作方式。當掃描過程成功完成時，無論是否發現漏洞，其 Pipeline 工作都會標示為透過。這意味著即使掃描出大量漏洞，Pipeline 仍然會繼續進行後續階段。

具體案例：Pipeline 中的漏洞掃描

假設我們有一個 Pipeline ，其中包含 SAST 和 DAST（動態應用程式安全測試）掃描步驟。即使 SAST 掃描發現多個漏洞，Pipeline 仍然會繼續執行後續步驟。

stages:
  - test
  - deploy

sast:
  stage: test
  script:
    - gitlab-runner exec sast

dast:
  stage: test
  script:
    - gitlab-runner exec dast

deploy:
  stage: deploy
  script:
    - echo "Deploying application..."

內容解密：

SAST 檢測步驟：
- 作用：SAST 檢測步驟負責靜態掃描程式碼中的潛在漏洞。
- 邏輯：無論是否發現漏洞，SAST 檢測步驟完成後都會標示為透過。
- 設計考量：這樣設計的目的是避免因為安全掃描而中斷 Pipeline ，讓開發團隊能夠獲得完整的掃描結果。
DAST 檢測步驟：
- 作用：DAST 檢測步驟負責動態掃描應用程式執行時的行為。
- 邏輯：同樣地，DAST 檢測步驟完成後都會標示為透過。
- 設計考量：這讓開發團隊能夠在知道所有潛在問題後再決定如何處理。

漏洞報告與第三方整合

GitLab 的安全掃揭工具會將所有發現的漏洞整合到三種不同的報告中：脆弱性報告、合規性報告和依賴性報告。每種報告都有其特定的目的和內容。此外，GitLab 支援整合第三方安全掃揭工具，以進一步增強安全性。

第三方整合實務案例

假設我們想要整合 Veracode 作為我們 Pipeline 的一部分。我們可以透過以下方式進行組態：

stages:
  - test
  - deploy

veracode_sast:
  stage: test
  script:
    - veracode-scan --profile "Default"

內容解密：

Veracode 整合步驟：
- 作用：Veracode 是一個知名的第三方靜態應用程式安全測試工具。
- 邏輯：我們可以透過組態 Veracode 的 API 請求來將其整合到 GitLab Pipeline 中。
- 設計考量：這樣可以讓我們利用 Veracode 的強大功能來補充 GitLab 自帶的 SAST 工具。

應用實務：SAST 在大型專案中的應用

在大型專案中，SAST 工具可以幫助開發者快速找到並修復潛在的安全漏洞。以下是一個真實案例：

案例：電子商務平台安全檢測

玄貓曾參與一個電子商務平台的開發專案。該平台使用 Python 和 JavaScript ，涉及多種敏感資料操作。我們啟用了 GitLab 的 SAST 功能來進行靜態掃揎。經過幾次迭代後，我們發現了一些潛在的 SQL 注入和跨站指令碼攻擊（XSS）風險。

def get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id={user_id}"
    return db.execute(query)

內容解密：

SQL 注入風險：
- 作用：上述程式碼存在 SQL 注入風險。
- 邏輯：user_id 未經過適當處理直接嵌入到 SQL 查詢中。
- 技術原理：攻擊者可以透過操縱 user_id 值來執行惡意 SQL 陳述式。
修復方法：
- 作用：使用引數化查詢來避免 SQL 注入風險。
- 邏輯：將 user_id 作為引數傳遞給查詢陳述式。
```
def get_user_data(user_id):
    query = "SELECT * FROM users WHERE id=?"
    return db.execute(query, (user_id,))
```
- 設計考量：引數化查詢可以有效防止 SQL 注入攻擊。

認識 GitLab 的三種報告

GitLab 提供了三種主要報告來展示安全掃握結果：脆弱性報告、合規性報告和依賴性報告。每種報告都有其特定功能和使用場景。

脆弱性報告

脆弱性報告展示了所有已知脆弱性及其詳細資訊。開發者可以在此處檢視每個脆弱性的嚴重程度、位置以及建議的修復方法。

此圖示展示了脆弱性報告的一部分結構：

做法解密：

脆弱性清單：列出所有已知脆弱性。
脆弱性詳細資訊包含：
- 嚴重程度：評估脆弱性對系統影響程度。
- 位置：指出脆弱性所在程式碼位置。
- 建議修復方法：提供修復建議以消除該脆弱性。

第三方整合：Veracode 安全掃握

除了 GitLab 自帶的安全掃揀工具外，玄貓也經常使用第三方工具如 Veracode 。Veracode 提供了強大且靈活的靜態應用程式安全測試（SAST）功能。

Veracode 組態範例

以下是如何將 Veracode 整合到 GitLab Pipeline 中的一個範例：

stages:
  - test

veracode_sast:
  stage: test
  script:
    - veracode-scan --profile "Default"

內容解密：

Veracode 授權與組態： Veracode 需要 API 金鑰和其他授權資訊進行組態。我們需要確保這些資訊已經正確設定。
veracode-scan 命令： veracode-scan 命令用於觸發 Veracode 的 SAST 掃握。 --profile "Default" 指定要使用的預設組態檔案。
結果整合與呈現： Veracode 的掃握結果將被整合到 GitLab 的 Vulnerability Report 中，供開發團隊參考和處理。

結果分析與未來趨勢預測

透過以上各類別技術手段及實務操作經驗可知：未來軟體開發將愈發重視安全保障工作,不僅僅依賴於自家內建SCA（供應鏈風險分析）等標準元件,還會更加註重與第三方專業化工具結合,來確保專案全方位無死角防護.

玄貓建議開發團隊們應當主動學習並熟練運用這些先進手段,同時也要關注國內外最新趨勢變化,才能不斷提升專案自身防護能力,做到未雨綢繆、防患於未然.

使用 SAST 應用程式進行原始碼漏洞掃描

在處理原始碼時，有一些看似無害的操作實際上可能會導致安全隱患。例如，非 Python 程式設計師可能會對以下程式碼感到驚訝：

import os
import tempfile

temp_dir = os.path.join(tempfile.gettempdir(), "my_temp_dir")
os.makedirs(temp_dir)

這段程式碼看似無害，但在 Python 中被認為是一個安全漏洞。Python 的最佳實踐是使用內建的 tempfile 模組來建立和管理臨時目錄和檔案。使用 tempfile 模組建立的目錄和檔案在程式執行完成後會自動刪除，確保不會意外地將敏感資料留在電腦的檔案系統中。手動建立目錄來存放臨時檔案是危險的，因為很容易忘記在程式不再需要時刪除該目錄。這正是 SAST（靜態應用程式安全測試）設計用來檢測的問題。

不同 SAST 分析器

不同的 SAST 分析器針對不同的程式語言會檢測不同的安全漏洞。例如，GitLab 的 SAST 分析器針對不同語言可能無法檢測到類別似問題，這可能是因為該語言中這段程式碼不被視為漏洞，或是分析器本身的成熟度不及 GitLab 的 Python SAST 分析器。

啟用 SAST

在 GitLab 專案中的管線中有兩種方式來啟用 SAST：手動和使用 GitLab GUI。這兩種方式最終都會在 .gitlab-ci.yml 檔案中新增一些組態。

手動啟用 SAST

要手動啟用 SAST，需對專案的 .gitlab-ci.yml 檔案進行兩項修改：

確保管線中已定義測試階段。
包含一個名為 Security/SAST.gitlab-ci.yml 的範本。

以下是相關程式碼範例：

stages:
  - test
include:
  - template: Security/SAST.gitlab-ci.yml

第一步非常簡單，因為通常在新增安全掃描之前，管線已經有測試階段定義。如果尚未新增任何測試相關工作，只需新增上述兩行即可。如果已經有其他階段定義，請不要刪除它們，只需新增測試階段即可。

確認順序

記住，階段列表的順序很重要，因為這決定了 GitLab 執行管線的順序。

包含範本

範本是 GitLab 提供的一個包含 CI/CD 程式碼的檔案，可以定義新的工作或新增其他功能。透過在 CI/CD 組態檔案中包含範本，可以新增執行任務（例如 SAST 掃描）而不需瞭解這些工作的運作方式。

例如，假設您的專案僅包含 Python 程式碼，您可以期望這個範本在專案管線中執行兩個新工作：一個是 Bandit，另一個是 Semgrep，這是 GitLab 支援的兩個 Python SAST 分析器。

提交這些更改後並檢視相關提交觸發的管線詳細資料，您會發現已包含這些工作並位於測試階段下：

@startuml
skinparam backgroundColor #FEFEFE

title GitLab 安全掃描策略與實務應用解析

|開發者|
start
:提交程式碼;
:推送到 Git;

|CI 系統|
:觸發建置;
:執行單元測試;
:程式碼品質檢查;

if (測試通過?) then (是)
    :建置容器映像;
    :推送到 Registry;
else (否)
    :通知開發者;
    stop
endif

|CD 系統|
:部署到測試環境;
:執行整合測試;

if (驗證通過?) then (是)
    :部署到生產環境;
    :健康檢查;
    :完成部署;
else (否)
    :回滾變更;
endif

stop

@enduml

A（test）：表示測試階段。
B（Bandit）：表示 Bandit 的 SAST 工作。
C（Semgrep）：表示 Semgrep 的 SAST 工作。

內容解密：

圖表解說：這張流程圖展示了在「test」階段中執行的兩個主要工作：Bandit 和 Semgrep。它們分別負責對 Python 原始碼進行靜態應用程式安全掃描。
邏輯與設計考量：使用流程圖來簡單直觀地展示不同工作之間的關係及其所屬階段。
技術原理：GitLab 的範本機制允許我們輕鬆地將預設工作整合到管線中，確保每次提交都能進行完整的安全掃描。
潛在改進點：可根據實際需求調整或新增更多工作以擴充套件掃描範圍。

啟用 SAST 與 GitLab GUI

使用 GUI 新增 SAST 掃描相對複雜一些：

在左側面板選擇「Security and Compliance」選項並選取「Configuration」，進入控制台以啟用和組態大部分 GitLab 安全掃描器。
點選按鈕以啟用 SAST，進入組態頁面。
保持所有選項為預設值並點選底部按鈕建立合併請求（Merge Request）。
在合併請求頁面保持所有欄位為預設值並點選底部按鈕建立合併請求。
前往合併請求頁面並完成合併操作。這時您的 .gitlab-ci.yml 檔案應該已包含測試階段以及前文所述範本。

完成這些步驟後，您應該會看到與手動啟用相同的結果：每次管線執行都會新增兩個與 Python 基礎分析器相對應的工作。

組態 SAST

全域變陣列態

假設您想停用 Semgrep Python 分析器，可以透過在 .gitlab-ci.yml 中設定全域變數來實作：

variables:
  SAST_EXCLUDED_ANALYZERS: "semgrep"

內容解密：

全域變陣列態：透過設定全域變數 SAST_EXCLUDED_ANALYZERS，我們可以指定要停用的分析器。這種方法適用於需要全域調整安全掃描行為的情況。
邏輯與設計考量：設定全域變數可以簡化組態流程並確保所有工作都遵循相同的安全規範。
技術原理：GitLab 的 CI/CD 組態檔案支援全域變數來控制工作行為，從而提供靈活性和一致性。
潛在改進點：根據具體需求調整或新增其他全域變數以進一步最佳化安全掃描策略。