GitLab 模糊測試與安全掃描實踐

隨著軟體規模日益增長，程式碼的品質和安全性變得至關重要。本文將探討如何在 GitLab 環境中結合模糊測試和安全掃描機制，有效提升軟體的健壯性和安全性。首先，我們將以 Python 程式碼為例，示範如何實作模糊測試，藉由輸入隨機資料來找出程式碼中潛在的錯誤。接著，我們將探討 GitLab 提供的各種安全掃描工具，包含靜態應用程式安全測試（SAST）、動態應用程式安全測試（DAST）、機密檢測、依賴套件掃描、容器掃描、授權合規性檢查，以及基礎設施即程式碼（IaC）掃描等。這些工具可以幫助開發者在軟體開發生命週期中及早發現並修復安全漏洞，降低潛在風險。GitLab 的安全掃描策略根據多個開源工具，並透過 Docker 容器化技術實作自動化佈署和更新，簡化了維護工作。此外，GitLab 還支援多種程式語言，並能自動偵測專案所使用的語言，選擇合適的分析器進行程式碼掃描。透過將這些安全掃描工具整合到 CI/CD 管線中，開發者可以即時獲得程式碼安全性的反饋，並持續改程式式碼品質。

模糊測試與檔案的使用

模糊測試是一種強大工具, 能夠幫助開發人員發現程式碼中的潛在問題. 其基本概念是向程式碼輸入隨機資料, 觀察程式碼反應, 從而發現潛在錯誤. 雖然模糊測試非常強大, 但它通常需要很長時間才能發現問題.

檢驗程式碼行為

為了提高程式碼品質, 一種常見做法是執行 fuzz 測試來確保程式碼沒有倒退. 比如說, 一旦團隊修復了一個 bug, fuzz 測試可以幫助確保它不會再次出現. 此外, fuzz 測試還可以幫助快速發現 bug. 在向被測試程式碼輸入真正隨機位元組時, 查詢 bug 需要很長時間, 假如它能找到的話. 然而, 載入一個包含一個或多個序列位元組作為被測試程式碼輸入的一系列位元組作為檔案, fuzz 測試會根據這些資料快速變異這些資料以便於下一次被測試.

構建檔案

雖然構建檔案會有一些複雜度, 特別是當想要使用 GitLab 自動更新檔案功能時, GitLab 的檔案會詳細引導這個過程. 我們推薦實驗這個功能,因為它大大增加了 fuzz 測試能力.

import os
import random

def generate_random_data(size):
    return bytes(random.getrandbits(8) for _ in range(size))

def run_fuzz_test(code, data):
    try:
        code(data)
    except Exception as e:
        print(f"Error encountered: {e}")

# Example usage:
code_to_test = lambda x: print("Testing with:", x)

# Generate random data and run fuzz test
data = generate_random_data(100)
run_fuzz_test(code_to_test, data)

#### 內容解密：
此段內容主要介紹了模糊測試如何透過輸入隨機資料來驗證程式碼行為並發現潛在問題。
玄貓以編寫Python函式生成隨機資料並進行測試為例說明過程。
首先定義一個函式 `generate_random_data` 用於生成指定大小隨機位元組，
然後定義另一個函式 `run_fuzz_test` 用於執行 fuzz 測試。
最後透過示例展示呼叫這兩個函式來進行實際 fuzz 測試。

驗證您的程式碼

在現代軟體開發中，驗證程式碼的完整性和品質是至關重要的。以下將介紹如何使用 GitLab 提供的多種驗證工具來確保您的程式碼達到最佳狀態。

使用可存取性掃描器驗證程式碼

首先，我們來看看如何使用 GitLab 提供的可存取性掃描器來驗證您的程式碼。點選這個按鈕，您將能夠看到 JSON 和 HTML 報告，這些報告包含了掃描器在目標網站上發現的任何可存取性違規資訊。JSON 輸出可以下載、解析並整合到任何其他儀錶板中。HTML 報告則是可以在瀏覽器中直接閱讀的人類可讀報告，讓團隊中的每個人都能看到哪些與可存取性相關的工作需要被分割成問題，以便追蹤和管理。

此外，還有一種方式可以檢視可存取性掃描器的結果，除了檢視它的兩種產物之外。記得合併請求（Merge Request）中的程式碼品質報告和自動化功能測試報告會顯示程式碼品質或測試結果在預設分支和合併請求源分支之間的差異嗎？可存取性違規報告也以相同的方式運作。

如果您有一個具有對應合併請求的分支，合併請求將顯示在該分支上執行的最新管道中發現的任何可存取性違規，只要這些違規在建立該分支時不同時在預設分支的管道執行中發現。簡言之，合併請求會顯示管道的分支是否使您的專案程式碼變得更好（透過修復預設分支上的可存取性問題）或變得更差（透過新增新的可存取性問題）。

使用其他方式驗證您的程式碼

除了上述方法外，GitLab 還提供了其他多種工具來進一步驗證您的程式碼。以下是三種額外的方法：

程式碼覆寫率

自動化功能測試確保您的程式碼正常執行，但如果不知道這些測試覆寫了多少程式碼函式庫，很容易會產生錯誤的信心。這裡就需要使用程式碼覆寫率報告來提升測試結果的價值。

您可以組態 GitLab 使用適當的、語言特定的程式碼覆寫率工具來確定哪些行程式碼被您的測試執行。這些報告整合到 GitLab GUI 中，因此很容易知道應該針對哪些行程式碼編寫新測試。

瀏覽器效能測試

由於今天許多應用程式都是在瀏覽器中執行，而根據瀏覽器的應用程式通常比傳統桌面應用程式慢得多，因此追蹤各頁面載入速度以及瞭解程式碼變更是否改善或惡化載入速度非常重要。

GitLab 可以測量頁面載入時間並在合併請求中顯示結果，讓開發人員瞭解他們提出的程式碼變更如何影響網頁應用程式效能。它甚至可以在效能惡化超過特定使用者可組態閾值時引發特別警示。這樣開發人員就可以在他的程式碼被合併到穩定程式碼函式庫之前修復任何效能相關問題。

裝載效能測試

瀏覽器效能測試會告訴您網頁應用程式前端 GUI 的載入速度，而 GitLab 的裝載效能測試則幫助您追蹤應用程式後端程式碼效能。儘管這項功能可以以各種方式操作應用程式，但最常用的是針對應用程式 API。例如，它可以同時對一個或多個 REST API 端點進行數十、數百或數千次呼叫並監控應用程式對這些呼叫做出回應速度。您還可以使用這項工具進行長時間浸泡測試以檢查應用程式是否隨時間推移發展出記憶體洩漏或其他問題。

裝載效能測試功能會將其發現顯示在合併請求中，讓開發人員瞭解與該合併請求相關聯之分支上的任何程式碼變更如何影響其應用程式後端效能。

確保您的程式碼安全性

確保您的程式碼符合需求後，接下來的步驟是在 GitLab CI/CD 管線中新增工作，以尋找安全漏洞。這是一個可選步驟，但由於 GitLab 讓我們很容易在管線中新增安全掃描，而且幾乎沒有什麼額外的負擔，除了可能會增加幾分鐘的管線執行時間，因此玄貓強烈建議啟用所有相關的安全掃描器。

首先，我們將概述 GitLab 使用安全掃描器的一般策略；瞭解一些有關安全掃描的方面，對於後續學習每個掃描器來說是有幫助的。然後，我們將解釋 GitLab 提供的七種安全測試型別的目的：靜態應用程式安全性測試（SAST）、機密檢測、動態應用程式安全性測試（DAST）、依賴專案掃描、容器掃描、授權合規和基礎設施即程式碼（IaC）掃描。我們將展示如何在管線中啟用每種型別的掃描器，並討論一些範例組態選項和技術，您可以使用這些技術來調整其行為以最適合您的需求。最後，我們將介紹三個額外的 GitLab 功能，這些功能讓安全掃描器更容易使用且更強大：閱讀掃描報告、使用弱點管理追蹤掃描結果和整合外部安全掃描器。

在這一章節結束時，您將學到保護程式碼和資料安全的一些關鍵技能。您將瞭解如何識別哪些 GitLab 提供的安全掃描器適用於您的專案。您將知道如何將它們新增到 CI/CD 管線中並組態其行為以滿足您的需求。您將對 GitLab 提供的不同型別安全報告有一個堅實的理解。您也將能夠追蹤團隊修補任何安全漏洞的進展。最後，您將瞭解如何在管線中新增第三方安全掃描器。總之，您將有信心確保程式碼是盡可能安全。

掌握 GitLab 的安全掃描策略

在深入每個安全掃描器之前，瞭解 GitLab 安全掃描策略中的幾個基本原則對於我們後續探討來說是非常重要的。以下是一些關鍵原則：

全面性：GitLab 提供多種不同型別的安全掃描器來涵蓋各種潛在風險。無論是靜態還是動態測試、依賴專案或容器等多樣化需求都能得到滿足。
即時反饋：GitLab 的安全掃描器能夠在 CI/CD 管線中即時執行，提供開發者實時反饋。這樣開發者可以在發現問題時立即修復。
整合化：這些掃描工具都嵌入在 GitLab 的 CI/CD 管線中，開發者無需學習新工具或跳轉到其他平台即可進行安全測試。
可組態性：每個掃描器都提供豐富的組態選項，開發者可以根據專案需求進行調整，從而最大化其效用。
持續改進：GitLab 不斷更新其掃描工具以應對新出現的威脅和漏洞。使用者不必擔心軟體過時或保安不夠穩定。

應用靜態應用程式安全性測試（SAST）

SAST 是一種用來分析原始碼、尋找潛在漏洞和缺陷的一種靜態分析方法。這類別測試不需要執行程式碼即可進行分析，因此可以很快地找出問題所在。

SAST 組態範例

以下是 SAST 的基本組態範例：

stages:
  - test

sast:
  stage: test
  script:
    - gem install bundler
    - bundle install
    - bundle exec sast

內容解密：

stages: 定義管線中的階段。在此範例中，我們只定義了 test 階段。
sast: 這是 SAST 工作名稱。
stage: 指定工作執行於 test 階段。
script: 執行 SAST 檢查所需的一系列命令。
- gem install bundler：安裝 Bundler。
- bundle install：安裝所有需要的依賴專案。
- bundle exec sast：執行 SAST 檢查。

應用機密檢測（Secret Detection）

機密檢測工具會搜尋儲存函式庫中的私人資訊或敏感資料（如 API 金鑰、密碼等）。這些資訊一旦被洩露可能會造成嚴重後果。

Secret Detection 組態範例

stages:
  - test

secret_detection:
  stage: test
  script:
    - git clone https://gitlab.com/gitlab-org/security-products/secret-detection.git
    - cd secret-detection
    - bundle install
    - bundle exec secret_detection scan ../..

內容解密：

stages: 定義管線中的階段。
secret_detection: 工作名稱為 secret_detection。
stage: 指定工作執行於 test 階段。
script: 執行 Secret Detection 檢查所需的一系列命令。
- git clone https://gitlab.com/gitlab-org/security-products/secret-detection.git：克隆 Secret Detection 工具儲存函式庫。
- cd secret-detection：進入克隆下來的儲存函式庫目錄。
- bundle install：安裝所有需要的依賴專案。
- bundle exec secret_detection scan ../..：執行 Secret Detection 檢查。

應用動態應用程式安全性測試（DAST）

DAST 是一種對執行中的應用程式進行動態分析以發現漏洞的一種方法。這類別測試通常會模擬攻擊者行為來找出應用程式可能存在的問題。

DAST 組態範例

stages:
  - test

dast:
  stage: test
  script:
    - apt-get update && apt-get install -y python3-pip
    - pip3 install dastaudit
    - dastaudit scan http://your-app-url/

內容解密：

stages: 定義管線中的階段。
dast: 工作名稱為 dast。
stage: 指定工作執行於 test 階段。
script: 執行 DAST 檢查所需的一系列命令。
- apt-get update && apt-get install -y python3-pip：更新系統並安裝 Python3 和 pip。
- pip3 install dastaudit：安裝 DAST 工具 dastaudit。
- dastaudit scan http://your-app-url/：對指定 URL 的應用進行 DAST 檢查。

下一步建議：

評估專案需要哪些種類別的檢查工具並進行相應組態。
持續更新並監控這些工具以應對新出現的威脅。
在團隊中推廣使用這些工具以提升整體開發品質和保安意識。

瞭解 GitLab 安全掃描策略

GitLab 的安全掃描策略建立在多樣化的開源掃描工具上，這些工具經過嚴格的選擇和驗證，確保能夠有效地檢測和保護程式碼的安全性。以下是玄貓針對 GitLab 安全掃描策略的一些深入分析。

GitLab 採用的開源掃描工具

許多 GitLab 的安全掃描工具都是開源的，這意味著它們並不是由 GitLab 自行開發，而是來自於第三方的開源社群。例如，IaC（Infrastructure as Code）掃描使用的是 Keeping Infrastructure as Code Secure (KICS)，而 Dependency Scanning 則使用 Gemnasium。

這些開源工具並不劣於由 GitLab 自行開發的軟體，相反地，它們經過了 GitLab 的嚴格研究和驗證。GitLab 會定期審查新的開源安全掃描工具，以確保採用最適合且最先進的技術。因此，這些掃描工具在 GitLab 的管道中是非常可靠的。

強調開源工具的優勢

開源工具通常比專有軟體更受歡迎，因為它們經常由專注於安全性的組織或公司開發，這樣的工具往往具有更少的漏洞。正如開源社群所說：「給予足夠的眼睛，所有漏洞都是淺顯的。」這對於安全相關的工具尤為重要，因為一個設計不當的安全掃描器可能會讓你誤以為你的程式碼是安全的，這比完全不知道你的產品安全狀況還要糟糕。

Docker 容器化與更新機制

GitLab 的安全掃描器是以 Docker 容器化形式執行的。這意味著每次執行掃描器時，都會下載相應的 Docker 映像。這會導致一些額外的時間消耗，但由於大部分掃描工作本身就需要幾分鐘來完成，這些時間消耗通常是可以接受的。

此外，由於這些 Docker 映像是自動更新的，你無需擔心手動更新安全掃描器。GitLab 會確保每次執行時都是最新版本，這減少了系統管理和維護的負擔。

語言支援與自動檢測

GitLab 的安全掃描器支援多種程式語言，並且可以自動檢測你專案中的語言型別。它透過查詢觸發檔案（例如 .py 檔案來判斷 Python 程式碼）來決定要執行哪些分析器。大多數情況下，你不需要手動設定或調整檔案結構。

如果 GitLab 未能正確識別你專案的語言型別，你可以參考官方檔案中列出的觸發檔案列表，確保每種語言都有至少一個觸發檔案存在。

語言支援範例

Go：使用 Semgrep 分析
Ruby：使用 Brakeman 分析
Python：需要 requirements.txt 或 .py 檔案
Java（Maven）：需要 pom.xml

不同語言使用不同分析器

有些掃描器（如 SAST 和 Dependency Scanning）根據不同語言使用不同的分析器。例如：

Go 語言：使用 Semgrep
Ruby 語言：使用 Brakeman

GitLab 會根據專案中的語言自動選擇合適的分析器來進行檢測。

不同語言與分析器關係示意圖

@startuml
skinparam backgroundColor #FEFEFE

title GitLab 模糊測試與安全掃描實踐

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

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

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

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

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

stop

@enduml

此圖示展示了不同程式語言與其對應分析器之間的關係。

內容解密：

Go 與 Semgrep：Semgrep 是一個靜態分析工具，專門針對 Go 語言進行漏洞檢測。
Ruby 與 Brakeman：Brakeman 是一個 Ruby on Rails 安全分析器，專門檢查 Ruby on Rails 應用程式中的安全漏洞。
Python 與 Bandit：Bandit 是一個 Python 原始碼安全檢測工具。
Java 與 SpotBugs：SpotBugs 是一個專門針對 Java 應用程式進行靜態分析和漏洞檢測工具。

掃描器與 CI/CD 整合

GitLab 的安全掃描器可以無縫整合到 CI/CD 管道中。這意味著你無需手動組態或維護這些掃描器；GitLab 會自動更新並執行最新版本。如果你已經擁有 GitLab 的 CI/CD 組態且你的許可層級允許使用這些掃描器，建議你直接在 GitLab 中使用它們而不是獨立執行。

頁面解說

以下是對頁面內容進行解說：

GitLab 使用第三方開源工具：GitLab 做出很明智的一個選擇, 就是依賴第三方開源社群, 持續觀察世界上優秀開源社群所提供新技術, 再挑選合適到自己的產品中.
Docker 包裝運作方式：當我們在 Gitlab CI/CD 建立出新專案時, 自動透過 Docker 載入相關所需組建以及封裝方式, 包含最新版本即時更新.
語法及架構支援：Gitlab 支援目前知名度高且多人使用之語法及架構, 也能透過組態檔案自動偵測目前專案使用之語法.
自動化及維護成本降低：由於透過 Docker 包裝, 各式各樣之環境我們只需撰寫 dockerfile 組態, 不需手動管理或更新相關封裝.

結論來說, Gitlab 提供整合性之 CI/CD 架構以及高度安全之掃描功能, 能夠幫助我們快速將軟體推播上線, 提供高度自我維護與完整組態自動化服務.

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。