程式碼安全掃描：SAST、秘密偵測與 DAST 保護策略

– 12 分鐘閱讀

在當今的軟體開發環境中，程式碼安全的重要性日益凸顯。靜態應用程式安全測試（SAST）、秘密偵測和動態應用程式安全測試（DAST）是確保程式碼安全的三種關鍵技術。SAST 藉由分析程式碼本身來找出潛在漏洞，而秘密偵測則專注於識別程式碼中不應該出現的敏感資訊，例如 API 金鑰或密碼。DAST 則模擬駭客攻擊，從外部測試應用程式的安全性。透過 GitLab 的 CI/CD 管道，可以輕鬆整合這些安全掃描工具，實作自動化的安全檢測。設定 SAST 時，可以根據專案需求調整掃描範圍，例如排除測試程式碼目錄。秘密偵測則能有效識別程式碼函式庫中可能存在的敏感資訊，其歷史模式功能更可以追溯過往提交記錄，確保即使曾被移除的秘密也能被發現。DAST 則能模擬真實攻擊場景，找出應用程式在執行時的漏洞。除了程式碼本身的安全之外，第三方依賴項也可能引入安全風險。因此，依賴性掃描也是確保程式碼安全的關鍵環節，它可以幫助開發者快速識別並修復依賴項中的已知漏洞。

安全掃描與秘密偵測：增強程式碼安全性

在現代軟體開發中，保護程式碼免受安全漏洞的侵害已成為不可或缺的部分。這裡我們將探討兩種關鍵的安全掃描技術：靜態應用程式安全測試（SAST）和秘密偵測（Secret Detection），並解釋如何在 GitLab 中組態這些功能來確保程式碼的安全性。

SAST 組態與最佳實踐

靜態應用程式安全測試（SAST）是一種在程式碼編譯或執行之前進行的安全分析方法。它能夠檢查程式碼中的潛在漏洞，並且可以自動化地整合到持續整合/持續佈署（CI/CD）管道中。

組態 SAST

首先，我們需要在 GitLab 的 CI/CD 組態檔案中啟用 SAST。以下是如何在 .gitlab-ci.yml 中組態 SAST 的範例：

variables:
  SAST_ANALYZER_IMAGE_OVERRIDE: "registry.gitlab.com/security-products/sast:semgrep"

這段組態會覆寫預設的 SAST 映像，使用自定義的 Semgrep 分析器。如果 CI/CD 組態檔案已經有變數區段，請將新變數新增到現有的變數中，而不是建立一個全新的變數區段。

過濾特定目錄

假設我們希望 Bandit SAST 分析器不掃描特定目錄（例如包含測試程式碼的目錄），可以透過編輯 .gitlab-ci.yml 來覆寫 Bandit 的工作定義，並設定一個作業範圍內的變數：

bandit-sast:
  variables:
    SAST_BANDIT_EXCLUDED_PATHS: "*/my_tests/*"

這裡使用的是 fnmatch 語法，GitLab 檔案中有詳細說明這種語法的使用方式。

使用 GUI 組態 SAST

除了透過 .gitlab-ci.yml 檔案進行組態之外，我們也可以使用 GitLab 的圖形介面（GUI）來設定某些組態選項。例如，我們可以選擇使用替代 Docker 映像、更改執行階段或調整搜尋目錄深度等。

秘密偵測

秘密偵測是一種專門用於檢查原始碼中潛在秘密資訊的技術，例如社交保險號碼、AWS 佈署金鑰等。它與 SAST 的工作原理相似，但專注於檢查秘密資訊。

秘密偵測原理

秘密偵測根據正規表示式（regex）來檢查原始碼中的字串。這使得它完全語言無關，可以檢查任何非二進位制檔案中的字串。以下是一些常見的秘密型別：

  • Dropbox API 權杖
  • GitLab 個人存取權杖
  • Heroku API 金鑰
  • 私人 SSH 金鑰
  • Stripe 存取權杖
MY_SSN = '123-45-6789'
MY_GITLAB_ACCESS_TOKEN = 'glpat-txQxy1frpAJodkxJYL8U'
MY_PRIVATE_SSH_KEY = '''
---
--BEGIN OPENSSH PRIVATE KEY
---
--
b3BlbnNzbmUAAAAEbm9uZAwAAAAtzc2gt==
---
--END OPENSSH PRIVATE KEY
---
--
'''

秘密偵測與多語言支援

由於秘密偵測根據正規表示式，它不需要為不同語言編寫單獨的分析器。這使得它能夠輕鬆檢查各種型別的檔案，包括組態檔案、README 檔案和原始碼檔案等。

檢視 SAST 與秘密偵測結果

一旦啟用並組態好 SAST 和秘密偵測，GitLab 會根據檢測到的語言執行相應的分析器，並將結果顯示在三個安全報告中：

  1. 漏洞報告
  2. 掃描結果報告
  3. 驗證報告

檢視結果範例

假設我們有關於暫時目錄的漏洞報告，GitLab 的漏洞報告區域會顯示如下內容：

Vulnerability Report:
- Vulnerability Type: Insecure Temporary Directory Usage
- Severity: High
- Details: The application uses temporary directories in an insecure manner.

使用 Secret Detection 找出儲存函式庫中的私密資訊

雖然正規表示式（regex）是一個強大的工具，但 Secret Detection 過度依賴正規表示式也意味著這個掃描工具有一個重要的限制：它無法檢測到密碼。這聽起來可能有點驚訝，但當你意識到一個精心撰寫的密碼應該很難被正規表示式捕捉時，這就說得通了。很難想像出一個正規表示式來捕捉所有可能的密碼，而不同時比對非機密鑰字，例如檔案中的句子或 GUI 元素中的一系列詞語。

除了這一點之外，Secret Detection 在找出應該存放在比 Git 儲存函式庫更安全位置的字串方面做得非常出色。它有一個非常棒的功能，這是 GitLab 中唯一的一個掃描器能提供的：歷史模式。如果你啟用了這種模式，Secret Detection 會掃描你儲存函式庫中的所有提交，看看是否曾經有任何機密被提交過。

歷史模式的重要性

由於版本控制系統如 Git 的目標之一是讓你可以回到檔案在任何時間點的狀態，所以很容易看到任何曾經被提交的秘密，即使它們在下一次提交中立即被移除。一旦秘密進入了 Git 儲存函式庫，它們就永遠可以被檢索到。因此，每當 Secret Detection 檢測到某個秘密時，它在任何安全掃描報告中建立的條目總是會提到該秘密不僅應該被移除，還應該被復原。任何進入 Git 儲存函式庫的秘密都應該被視為已經暴露給世界了，並且不應再使用。

這是非常重要的一點！如果 Secret Detection 發現了一個密碼，你應該立即停用那個密碼並設定一個新的（當然，你不應該將其檢入 Git）。如果它檢測到一個佈署鑰匙，你應該取消那個鑰匙並建立一個新的。這個原則適用於任何型別的秘密。如果 Secret Detection 檢測到它們，僅僅從儲存函式庫中移除它們是不夠的。它們應該被視為不可再用並且應盡快替換。

啟用與組態 Secret Detection

由於 Secret Detection 以前是 SAST 的一部份，因此使用相同的手動或 GUI 基礎方法來啟用兩者並不奇怪。

要手動啟用 Secret Detection，請確保你在管道中定義了一個測試階段。然後，包含 GitLab 提供的包含 Secret Detection 相關工作定義的範本：

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

這就是全部內容！下次觸發管道時，你會發現 Secret Detection 工作現在正在測試階段執行。

啟用與組態 Secret Detection

要使用 GUI 啟用 Secret Detection，你可以使用與 SAST 相同的過程：點選左側導航窗格中的「安全性與合規性」選項並選擇「組態」。在那裡，你會看到一個啟用 Secret Detection 的選項。點選該選項允許你建立一個分支和相關的合併請求來編輯你的 .gitlab-ci.yml 檔案以包含前面描述的 Secret Detection 範本。如果你合併請求並觸發新的管道執行，你會發現 Secret Detection 現在已經在你的管道中啟用了。與 SAST 一樣，許多人發現這種過程比手動編輯 .gitlab-ci.yml 更繁瑣，但你可能會有不同的經驗。

組態 Secret Detection

像大多數 GitLab 安全掃描器一樣，Secret Detection 有幾個可組態的選項。你可以在 GitLab 檔案中瞭解所有選項及其設定方法，但以下兩項特別值得在此強調。

首先，你可能想要啟用前面討論過的特殊歷史模式來掃描剛剛匯入 GitLab 的現有儲存函式庫。第二，你可以要求 Secret Detection 不要掃描儲存函式庫中的某些目錄。例如，你可能會為測試目的將假社會安全號碼存放在 test/ 目錄中，並在 docs/ 目錄中存放假佈署鑰匙。你可能希望透過排除這些目錄來防止 Secret Detection 將其標記為安全漏洞。

secret_detection:
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"
    SECRET_DETECTION_EXCLUDED_PATHS: "tests,docs"

檢視 Secret Detection 的結果

現在讓我們來看看 Secret Detection 的結果。 此圖示展示了從啟用與組態 Secret Detection 到檢視結果及檢視漏洞報告的流程。

當你已經根據自己的需求啟用和組態好 Secret Detection ，並且它在管道中成功執行後， 可以在漏洞報告區域檢視結果。 此圖示展示了從檢視結果到檢查漏洞詳細資訊之流程。 舉例來說：

漏洞報告範例

以下是對之前提供的 Python 原始碼執行 Secret Detection 生成的一些結果：

# 假設有以下 Python 原始碼
def get_secret():
    return "supersecretpassword"

# 對上述程式碼執行SecretDetection,產生警示。
# 警示內容：找到明文機密字串"supersecretpassword"

與 DAST 的比較

與 SAST 和 DAST 是「白盒」測試不同的是，「白盒」測試會檢視應用程式內部以瞭解其運作方式；DAST 是「黑盒」測試的一種形式，「黑盒」測試只是傳送輸入並查詢輸出中的潛在問題或安全漏洞， 而不瞭解應用程式如何將輸入轉換為輸出。 此圖示展示了 SAST 和 DAST 的區別。

理解 DAST

DAST 測試網頁應用程式 URL 或 Web API 端點。如果你將網站首頁 URL 提供給 DAST ，它會存取該頁面、識別頁面上的任何連結或可點選 GUI 元素、跟隨那些連結或點選那些元素， 然後重複該過程。它將繼續此“蜘蛛”流程直到它能夠存取應用程式內部所有頁面為止。 在此過程中的每一步中， 它都會檢查網頁應用程式傳回的結果以查詢任何問題。以下是它所尋找的一些問題：

  • 暴露私人敏感資訊
  • 雙向請求欺騙令牌缺失
  • 接受敏感資訊（如密碼）透過查詢字串

滲透測試工具分析

滲透測試工具分析方式如下：

此圖示展示了 DAST 流程。

DAST 流程解析：

  1. 存取首頁：DAST 首先會存取網站首頁。
  2. 識別連結及可點選 GUI 元素：然後識別頁面上的所有連結和可點選 GUI 元素。
  3. 跟隨連結及點選 GUI 元素：接著跟隨這些連結或點選這些元素。
  4. 重複上述流程：最後重複上述步驟直到所有可達到頁面都已存取完畢。

網路應用風險敘述

網路應用風險敘述如下：

  1. 暴露私人敏感資訊：DAST 查詢網路應用未經授權公開私人敏感資訊之情況。
  2. 雙向請求欺騙令牌缺失：DAST 查詢網路應用雙向請求欺騙令牌之缺失情況。
  3. 接受敏感資訊透過查詢字串：DAST 查詢網路應用接受敏感資訊（如密碼）透過查詢字串之情況。 此圖示展示了 DAST 風險敘述內容。
小段落標題

希望以上內容能夠幫助大家更好地瞭解如何使用 Secret Detection 和 DAST 工具來提升軟體開發流程中的安全性與穩定性。

@startuml
skinparam backgroundColor #FEFEFE

title 程式碼安全掃描：SAST、秘密偵測與 DAST 保護策略

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

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

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

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

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

stop

@enduml

此圖示展示瞭如何使用SecretDetection進行歷史模式執行以及進行風險敘述之流程

保護您的程式碼

在現代軟體開發中，保護程式碼免受潛在威脅是至關重要的。這裡我們將探討如何使用動態應用安全測試（DAST）來發現和修補網頁應用程式中的弱點。這些技術不僅適用於傳統的網頁應用程式，也同樣適用於Web API端點。

DAST的運作原理

DAST是一種安全測試技術，透過向目標系統傳送請求並分析其回應來檢測潛在的安全漏洞。無論是針對URL還是Web API端點，DAST都可以在被動或主動模式下執行。每次執行DAST時，它都會進行被動掃描，這意味著它會傳送類別似真實使用者請求的無害、非惡意請求。

如果您需要更深入的分析，可以啟用全面掃描。這種掃描模式除了通常的被動請求之外，還會新增主動攻擊。這些主動攻擊更具侵略性，如果針對非自有網站或Web API，可能會被視為惡意攻擊。然而，它們非常有價值，因為它們模擬了真實駭客可能使用的攻擊方式，從而揭示了許多潛在的弱點。

啟用與組態DAST

DAST提供了豐富的組態選項。以下是一些常用的組態步驟，幫助您快速上手：

  1. 存取安全掃描組態頁面：

    • 在左側導航欄中選擇「安全與合規」，然後選擇「組態」。
    • 根據需要啟用DAST並進行初步組態。

  2. 建立掃描器組態檔案：

    • 設定是否僅進行被動掃描或包含主動掃描。
    • 設定超時值以限制DAST花費在網站爬行上的時間。
    • 為這個組態檔案命名，以便日後重複使用。

  3. 建立網站組態檔案：

    • 設定要掃描的網站首頁URL或Web API端點。
    • 如果正在掃描網站，可以選擇性地新增身份驗證憑證以登入網站。

  4. 生成CI/CD組態程式碼：

    • 組態完成後，GUI會顯示一段程式碼片段，您可以將其複製並貼上到專案的.gitlab-ci.yml檔案中。
    • 這段程式碼指示DAST在管道中執行。

DAST掃描目標

雖然您可以建立包含任何網站或Web API URL的網站組態檔案，但我們強烈建議僅針對您擁有和管理的目標進行掃描。特別是當使用DAST的全面掃描選項時，該選項進行更具侵略性的掃描。此外，我們建議僅在審查、測試或預生產環境中執行DAST，以避免對生產環境造成不穩定或效能下降。

手動啟用與組態DAST

如果您偏好手動啟用與組態DAST，可以按照以下步驟操作：

  1. 在管道中新增dast階段：
stages:
- deploy
- dast
include:
- template: DAST.gitlab-ci.yml
variables:
  DAST_WEBSITE: https://example.com
  DAST_FULL_SCAN_ENABLED: "true"
  1. 設定全域變數：
    • DAST_WEBSITE：要掃描的URL。
    • DAST_FULL_SCAN_ENABLED：是否啟用全面掃描。

DAST執行時間管理

由於DAST可能需要較長時間來完成所有頁面的掃描，GitLab允許您按需或根據計劃執行DAST掃描：

  1. 按需觸發掃描：

    • 在左側導航欄中選擇「按需掃描」，然後按照GUI向導進行操作。

  2. 計劃掃描：

    • 在「安全與合規」選項中設定計劃以定期執行DAST掃描。

檢視DAST結果

DAST掃描結果將顯示在漏洞報告區域中，與靜態應用程式安全測試（SAST）和秘密檢測結果一樣。以下是一些示例結果：

漏洞報告區域：
- Header Fields 漏洞（示例：Content-Type缺失）

這些結果通常涉及標頭欄位問題，這是被動掃描中最常見的發現。

查詢依賴性中的漏洞

為什麼要重複造輪子？很多時候，開源社群已經為我們提供了經過充分測試和檔案化的函式庫和框架。然而，這些第三方依賴項可能包含未知的安全漏洞。GitLab提供了依賴性掃描功能來確保您使用的依賴項是安全無虞的。

為何需要依賴性掃握？

在現代軟體開發中，我們經常依賴第三方函式庫來加速開發流程。例如Python模組、Ruby Gems、Java JAR檔案等。然而，這些第三方依賴項可能包含已知漏洞，並且如果您將它們納入到專案中，就會繼承這些問題。

依賴性掃握功能透過分析您所引入的所有依賴項來發現潛在漏洞。它能夠自動檢查這些依賴項是否存在已知漏洞並生成詳細報告。

啟用與組態依賴性掃疎

  1. 存取安全組態頁面：

    • 在GitLab導航欄中選擇「安全與合規」，然後選擇「組態」。
    • 啟用依賴性掃疎功能並設定相關引數。

  2. 新增CI/CD組態：

    • 在.gitlab-ci.yml檔案中新增依賴性掃疎階段：
stages:
  - build
  - test
  - dependency_scan

dependency_scan:
  stage: dependency_scan
  script:
    - dependency-check --project "YourProjectName" --out "dependency-scan-report.html"
  artifacts:
    paths:
      - dependency-scan-report.html
  1. 檢視報告：
    • 探索報告可以顯示每個依賴項的詳細資訊及其潛在漏洞。
Example Dependency Scan Report:
---
-
---
-
---
-
---
-
---
-
---
-
---
-
---
-
---
-
---
---
Dependency Name: example-library
Version: 1.0.0
Vulnerability: CVE-2023-XXXXXX (High Risk)
Description: Example description of vulnerability.
Recommendation: Upgrade to version 1.1.0 or later.
---
-
---
-
---
-
---
-
---
-
---
-
---
-
---
-
---
-
---
---

內容解密：

此程式碼範例展示如何在GitLab CI/CD管道中啟用並執行依賴性掃疎功能：

  • stages: 您定義了三個階段：構建、測試和依賴性掃疎。
  • dependency_scan: 您指定了一個名為dependency_scan的作業階段。
  • script: 您執行了一個命令來生成依賴性報告。
  • artifacts: 您儲存了生成的報告檔案供後續分析使用。

以上步驟幫助我們確保所有引入到專案中的第三方函式庫都是安全無虞且沒有已知漏洞存在。

玄貓 BlackCat

玄貓 BlackCat

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