返回文章列表
玄貓（BlackCat）

CI/CD 管線整合模糊測試強化軟體安全性

本文探討如何在 CI/CD 管線中整合模糊測試，以提升軟體安全性。涵蓋模糊測試基本概念、流程、結果呈現方式，並探討語料函式庫的應用、模糊目標函式範例，以及與存取性測試的比較。

軟體測試 DevOps
CI/CD 模糊測試 安全性 軟體漏洞 語料函式庫 GitLab

在 CI/CD 流程中匯入模糊測試能有效提升軟體品質，及早發現潛在的安全漏洞與程式錯誤。模糊測試的核心概念是透過提供隨機或異常資料輸入，檢驗程式碼的穩固性，並在每次建置和佈署階段自動執行，強化軟體的可靠度。本文將探討如何在 CI/CD 管線中實作模糊測試，包含流程、結果解讀、語料函式庫的運用以及實際案例說明。透過整合模糊測試，開發團隊可以在軟體開發生命週期早期就發現並解決問題，避免潛在風險。

模糊測試是一種自動化軟體測試技術，藉由向目標程式輸入大量的隨機資料，嘗試觸發程式中的錯誤或未預期的行為。在 CI/CD 管線中，模糊測試通常在程式碼編譯和建置完成後執行。模糊測試引擎會產生隨機的輸入資料，並將這些資料傳遞給待測程式。如果程式發生當機、例外或其他非預期行為，模糊測試引擎會記錄該事件，並提供相關資訊，例如導致錯誤的輸入資料、程式當機的堆積疊追蹤等，方便開發者快速診斷和修復問題。模糊測試結果通常會顯示在弱點報告、安全標籤和合併請求中，讓開發團隊能全面掌握程式碼的安全性狀態。除了隨機資料生成，模糊測試還可以搭配語料函式庫使用。語料函式庫是一組預先定義的輸入資料，可以包含已知的有效輸入、邊界值或容易觸發錯誤的資料。使用語料函式庫可以提高模糊測試的效率，更快地發現潛在問題。同時，語料函式庫也可以用於記錄已修復的漏洞，避免重複測試。

模糊測試在 CI/CD 管線中的應用

在現代軟體開發中，模糊測試（Fuzz Testing）是一種強大的技術，能夠幫助我們發現潛在的安全漏洞和程式錯誤。將模糊測試整合到 CI/CD 管線中，可以在每次建置和佈署時自動執行模糊測試，從而提高程式碼的穩定性和安全性。這篇文章將探討如何在 CI/CD 管線中實施模糊測試，並提供具體的實作案例和技術解說。

模糊測試的基本概念

模糊測試是一種自動化的軟體測試方法，透過向程式輸入隨機或異常資料來檢查程式的穩定性和安全性。模糊測試的核心思想是，透過輸入大量隨機資料來觸發程式中的未知錯誤或漏洞。

模糊測試的工作流程

以下是模糊測試在 CI/CD 管線中的典型工作流程：

  1. 觸發模糊測試：CI/CD 管線中的某個階段（例如 fuzz 測試階段）會觸發模糊測試任務。這個任務會下載必要的工具和引擎，例如 gitlab-cov-fuzz 二進位制檔案和 Python 基礎的模糊引擎。

  2. 生成隨機資料：模糊引擎會生成一系列隨機位元組，並將這些位元組傳遞給模糊目標函式。

  3. 資料轉換：模糊目標函式會將隨機位元組轉換為特定格式的資料（例如字串），然後將這些資料傳遞給待測試的程式碼。

  4. 執行待測試程式碼：如果待測試程式碼能夠正常處理這些隨機資料（即沒有當機或拋出意外異常），模糊引擎會繼續生成新的隨機位元組來覆寫不同的程式碼路徑。

  5. 報告錯誤：如果隨機資料導致待測試程式碼當機或拋出意外異常，模糊引擎會報告這個錯誤，並且 CI/CD 管線會記錄這個問題。

模糊測試結果的顯示

當模糊測試發現錯誤時，結果會顯示在三個地方：

  1. 弱點報告：您可以透過「安全與合規性」->「弱點報告」在左側導航欄中檢視弱點報告。這只顯示模糊測試在專案預設分支上發現的問題。

  2. 安全標籤：在管線詳細資訊頁面上的「安全」標籤中顯示任何問題，這些問題是在該管線例項執行的分支上由模糊測試發現的。

  3. 合併請求：顯示預設分支和來源分支之間問題的差異。如果預設分支和來源分支之間沒有變化，合併請求將報告模糊測試沒有發現任何問題。

模糊測試報告範例

以下是一個典型的模糊測試報告範例：

此圖示展示了模糊測試發現的一個錯誤。報告包含了錯誤堆積疊追蹤、觸發錯誤的隨機位元組以及具體的錯誤資訊（例如 IndexError 和觸發它的行號）。

IndexError: list index out of range
File "is_bob.py", line 10, in is_bob
    return some_list[index]
Sample: [62]

模糊測試的額外考量

隨機性與不可預測性

模糊測試因其隨機性而具有不可預測性。相同的測試在不同時間執行可能會有不同的結果。因此，建議將模糊測試作為持續進行的一部分，以增加發現問題的機率。

非同步執行

有些團隊選擇將模糊測試作為非同步任務執行，而不是阻塞後續管線階段。這樣可以避免因為單次執行時間過長而影響整體管線效率。

停止條件

與其他測試工具不同，模糊測試通常在發現第一個問題後即停止執行。這是因為每次管線執行都會重新執行一次全新的模糊測試合作出來更有效。

使用語料函式庫進行模糊測試

語料函式庫是一種特殊且可選用於模糊測試特色。它是一組已知對你程式碼行為會造成影響的一系列隨機位元組。這種語料函式庫物件可以有兩種用途：

  • 當一個特定系列隨機位元組造成某個錯誤或當機時儲存。
  • 作為測試種子來提高下一次執行時發現問題漏洞得機率。
  • 測試工具會自動調整已發生錯誤而進行修復後儲存起來以備將來更容易發現問題漏洞使用之情形。

模糊目標函式範例

以下是一個簡單的 Python 模糊目標函式範例：

import sys
import os

def fuzz_target(data):
    try:
        string_data = data.decode('utf-8')
        is_bob(string_data)
    except UnicodeDecodeError:
        pass

def main(args):
    fuzz_target(bytes(args[1]))

if __name__ == "__main__":
    main(sys.argv)

內容解密：

以上範例展示了一個簡單的 Python 模糊目標函式。以下是對該函式各部分作用及邏輯詳細解說：

  • fuzz_target 函式：接受一組隨機位元組 data 作為輸入。
  • try-except 塊：嘗試將 data 轉換為 UTF-8 編碼的字串。如果轉換失敗（即丟擲 UnicodeDecodeError），則直接傳回而不執行待測試程式碼。
  • is_bob 函式：假設這是待測試函式，接受字串作為輸入並進行某些操作。
  • main 函式：接受命令列引數並呼叫 fuzz_target 函式。
  • __main__ 塊：確保當該指令碼直接執行時能夠正確呼叫 main 函式。

模糊測試與存取測試

在現代軟體開發中，確保程式碼的穩定性和安全性是至關重要的。模糊測試（Fuzz Testing）和存取測試（Accessibility Testing）是兩種有效的技術手段，分別用來檢驗程式碼的穩定性和使用者介面的可存取性。以下將詳細探討這兩種測試方法的應用與實作。

模糊測試的運作原理

模糊測試是一種自動化測試技術，透過向程式碼輸入隨機資料來檢驗其穩定性和安全性。模糊測試的核心理念是，隨機資料有可能觸發程式碼中潛在的漏洞或錯誤，從而幫助開發者在實際運作前發現並修復這些問題。

使用語料函式庫進行模糊測試

在模糊測試中，語料函式庫（Corpus）扮演著重要角色。語料函式庫是一組已知的輸入資料，這些資料可以幫助模糊測試器更快速地找到潛在的問題。語料函式庫有兩個主要用途：

  1. 確保修復過的漏洞不會重現： 一旦開發團隊修復了一個漏洞，模糊測試可以使用語料函式庫中的特定位元組序列來確保該漏洞不會再次出現。將引發漏洞的位元組序列加入語料函式庫後，未來的模糊測試會使用這些位元組來測試程式碼。

  2. 加速漏洞發現： 模糊測試器生成真正隨機的位元組資料作為輸入時，可能需要很長時間才能找到漏洞。然而，如果語料函式庫中包含有效輸入資料（即程式碼可以處理的資料），模糊測試器可以對這些有效資料進行變異，從而更快地找到觸發漏洞的資料。

設定語料函式庫

設定語料函式庫可能會有些複雜，特別是如果你想利用 GitLab 的自動更新功能。當模糊測試找到新的漏洞時，GitLab 可以自動更新語料函式庫。這個過程可以顯著提升模糊測試的效果，因此建議嘗試這個選項。

GitLab CI/CD 中的存取測試

並非所有應用程式都包含網頁介面，但當你開發網頁應用時，確保其介面對各種殘障使用者友好是非常重要的。GitLab 提供了簡單且強大的工具來檢查網站是否符合 Web Content Accessibility Guidelines (WCAG)，這些由 World Wide Web Consortium 提供。

WCAG 的主要內容

WCAG 涵蓋了許多可能導致存取問題的網站特性，例如：

  • 需要垂直和水平滾動的頁面
  • 不包含文字內容的 HTML 標題標籤（如 <H1>）
  • 對比度不足的文字
  • 沒有替代文字描述的圖片
  • 無名稱可供螢幕閱讀器使用的按鈕控制項

設定存取測試

要在 GitLab CI/CD 裡加入存取測試，你需要在 .gitlab-ci.yml 檔案中建立一個新階段稱為 accessibility：

stages:
- accessibility

接著，包含 GitLab 提供的一個存取相關工作定義範本：

include:
- template: "Verify/Accessibility.gitlab-ci.yml"

最後，設定一個全域變數告訴存取掃描器要檢查哪個網站：

variables:
a11y_urls: «https://www.hats-for-cats.com»

檢視存取測試結果

存取掃描器會生成一個簡單易讀的 HTML 頁面來描述它找到所有輕微問題（警告）和嚴重問題（錯誤）。要檢視這些結果，執行一個啟用了存取測試功能的管道，然後存取管道細節頁面。你會看到一個名為 a11y 的工作，點選該工作檢視終端輸出和產生的工件。

接下來進行更深入技術探討

接下來我們將進一步探討這兩種技術手段在實務中的應用細節及其優勢與挑戰。

慣例細節說明及佈署範例

import random
import string

def generate_random_bytes(size):
    """生成指定長度的隨機位元組"""
    return ''.join(random.choices(string.ascii_letters + string.digits, k=size))

# 產生100個隨機位元組序列
corpus = [generate_random_bytes(100) for _ in range(100)]

for idx, data in enumerate(corpus):
    print(f"Sequence {idx}: {data}")

#### 內容解密：
以上範例展示瞭如何使用 Python 生成隨機位元組序列。`generate_random_bytes` 函式利用 `random.choices` 方法產生指定長度（在此範例中為 100）的隨機字串。這些字串可以作為模糊測試的一部分進行進一步處理。

然後我們建立了一個包含 100 個隨機位元組序列（每個序列長度為 100） 的語料函式庫。接著遍歷並列印每個序列及其索引值。

接下來我們會進一步探討如何利用這些語料函式庫進行更高效率地模糊測試及其他相關技術應用。

此圖示展示了從生成隨機位元組到建立語料函式庫的一整流程：

@startuml
skinparam backgroundColor #FEFEFE

title CI/CD 管線整合模糊測試強化軟體安全性

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

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

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

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

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

stop

@enduml
小段落標題

從上述圖示中可以看出整體流程非常清晰明瞭：首先我們生成隨機位元組資料、然後將它們加入語料函式庫進行後續調整以及進一步處理流程。接著我們會結合具體案例展示如何執行模糊測試並修復潛在漏洞。

透過本篇文章我們瞭解到模糊測試與存取性測試各自獨特功能與應用場景；同時也瞭解了透過傳統方式與新型態技術如 AI、ML等如何進一步提升系統穩定性與安全性；我們也瞭解到透過合理組態與維護系統能夠達到更高層次之系統品質控管標準！

驗證您的程式碼

使用存取性掃描器檢視報告

當您點選這個按鈕時，會顯示存取性掃描器生成的 JSON 和 HTML 報告。這些報告包含了在目標網站上發現的任何存取性違規的相同資訊。JSON 輸出可以下載、解析並整合到您設定的任何其他儀錶板中。HTML 報告則是可以在瀏覽器中閱讀的人類可讀報告，讓您團隊中的每個人都能看到哪些與存取性相關的工作可能需要轉化為問題，以便追蹤和管理。

此外，還有一種方法可以檢視存取性掃描器的發現，除了檢視它的兩個工件。記得合併請求的程式碼品質報告和自動化功能測試報告的版本顯示了預設分支和合併請求來源分支之間的程式碼品質或測試結果差異嗎？存取性違規的合併請求報告以完全相同的方式運作。

如果您有一個具有相應合併請求的分支，則合併請求會顯示該分支上最新管道執行中發現的任何存取性違規，只要這些違規未在建立該分支時執行的預設分支管道上發現。換句話說，合併請求會顯示管道分支是否使您專案的程式碼更好（透過修復預設分支上的存取性問題）或更差（透過新增預設分支上沒有的新存取性問題）。如果您正在處理功能分支並希望確保老闆不會因為您新增比解決問題還多而對您大喊大叫，這是一個很棒的報告。

其他驗證程式碼方法

我們已經涵蓋了一些最常見的驗證程式碼方法。GitLab 提供了更多功能來幫助您進一步測試程式碼。這裡我們無法詳細介紹所有內容，但以下是三種額外方法來測試程式碼的快速描述。所有這些工具啟用和組態的詳細資訊都可在 GitLab 的官方檔案中找到。

程式碼覆寫率

自動化功能測試可以確保您的程式碼按照預期執行。測試是每個軟體開發專案的重要組成部分，但如果不知道測試覆寫了多少程式碼函式庫，則很容易從看到所有測試透過中獲得虛假自信。畢竟，如果這些測試只執行應用程式 5% 的程式碼，那麼 100 個透過測試對您沒有多大幫助。

程式碼覆寫率報告可以讓您對測試結果的價值充滿信心。您可以組態 GitLab 使用適當的語言特定程式碼覆寫率工具來確定哪些產品程式碼行被測試執行。該報告整合到 GitLab GUI 中，因此很容易知道在編寫新測試時應該針對哪些程式碼行。

瀏覽器效能測試

由於許多今天的應用程式都是在瀏覽器中執行，且瀏覽器應用程式通常比傳統桌面應用程式慢得多，因此跟蹤各網頁頁面載入速度非常重要，並要知道對程式碼所做的更改是使載入時間變好還是變差。

GitLab 可以衡量頁面載入時間並顯示結果以便開發人員瞭解其建議程式碼更改對 Web 應用效能產生什麼影響。當效能超出特定使用者可組態門檻值時，它甚至可以引發特別警示。該報告允許開發人員在其程式碼合併到穩定程式碼函式庫之前修復其程式碼引入的任何與效能相關問題。

負載效能測試

雖然瀏覽器效能測試可以告訴您 Web 應用前端 GUI 的載入速度，但 GitLab 的負載效能測試有助於追蹤應用後端程式碼效能。雖然這個功能可以以各種方式驗證應用，但它最常用於目標應用 API。例如，它可以以數十次、數百次或數千次同時呼叫一個或多個應用 REST API 端點來撞擊您的應用，然後監控應用對這些呼叫回應速度有多快。您也可以使用此工具執行長時間浸泡測試以檢視應用是否隨時間發展出記憶體洩漏或其他問題。

負載效能測試功能會在合併請求中顯示其發現結果，以便開發人員瞭解與該合併請求關聯分支上的任何程式碼更改如何影響其應用後端效能。

摘要

在本章中，您涵蓋了大量內容。您學會如何在 GitLab CI/CD 管道中構建程式碼，使用各種不同方法和語言。這並未涵蓋編譯或其他構建程式碼的每種可能方式——我們只是剛剛涉及該主題——但在使用任何語言或工具時，您應該對一般步驟有很好的瞭解。您還學到某些型別的程式碼驗證工具要求先構建程式碼，因為它們與正在執行中的程式碼進行互動。其他測試則不需要此步驟，因為它們僅掃描原始碼而不執行它。

接下來，您學習如何在管道中使用 GitLab 的 Code Quality 功能來確保程式碼遵循編寫風格最佳實踐、遵守常見編寫約定、避免不必要複雜性以及不顯示任何可能存在錯誤或意外行為的程式碼氣味。

然後您學習如何將自動化功能測試整合到 GitLab CI/CD 管道中。您不僅瞭解如何從管道作業觸發這些測試還瞭解如何確保結果可在 GitLab GUI 中看到兩種不同報告中。此外，您還瞭解如何使用合併請求中的測試結果 delta 檢視來瞭解該合併請求分支上的程式碼是否幫助提高產品自動化測試合格率。

接下來是模糊測試（fuzz testing），GitLab 最複雜但可能最有趣的一項錯誤查詢功能。你學會了組成模糊測試架構的一四個不同元件以及隨機資料如何從一個元件流向下一個元件以嘗試使你的程式當機或引發意外例外狀況。你熟悉了模糊測試的一些獨特之處並學習如何調適它們。最後你看到如何利用一套語料不僅捕捉功能迴歸還加快模糊測試並使其更可能找到問題。

最後一個觀察到實際操作的是 GitLab 的可存取性檢查功能。這幫助你確保網頁應用對範圍內殘障人士可供使用從而最大限度擴充套件可能使用者基礎。

這些工具是開始驗證軟體專案時很好的起點位置但 GitLab 提供了幾種其他方法進一步深入檢查你的人員Pipeline工具快速導覽了覆寫率工具瀏覽器效能檢查與負載效能檢查等所有這些將獎勵進一步探索利用 GitLab 的官方檔案與一些實際操作。 等到你的人員Pipeline工具已經透過驗證之後就可以佈署給客戶端使用嗎？錯誤！首先必須確保沒有包含任何安全漏洞會進一步探討此話題於下一章節