TruffleHog：從提交與端點尋找洩漏的秘密
TruffleHog 掃描程式碼儲存庫、檔案系統與雲端服務中的外洩憑證，並驗證這些密鑰是否仍然有效。
秒懂
- 它是什麼？
- TruffleHog 是秘密掃描工具，README 涵蓋 Git、檔案、容器、雲端來源、驗證與自訂偵測器。
- 適合誰用？
- TruffleHog：從提交與端點尋找洩漏的秘密 適合需要 README 涵蓋 Git、檔案、容器、雲端來源、驗證與自訂偵測器。 的團隊；不適合只想以根目錄 pnpm dev 啟動完整服務的人，因為 README 明確說明它是共用套件工作區。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
偵測秘密的四個階段
TruffleHog 是一個用於查找洩漏憑據的命令列工具。README 將它的工作分為四個階段：發現、分類、驗證和分析。這裡所說的秘密，是指一台機器用來向另一台機器認證自身的憑據，包括 API 金鑰、資料庫密碼、私有加密金鑰等。發現階段會搜尋 Git 倉庫、聊天記錄、wiki、日誌、API 測試平台、物件儲存和檔案系統等來源。分類階段會把找到的內容對應到 800 多種秘密類型，並關聯到它所屬的具體身分，從而識別出某串文字是 AWS 金鑰、Stripe 金鑰、Cloudflare 金鑰、Postgres 密碼還是 SSL 私鑰。驗證階段會嘗試用每個已分類的秘密登入，以確認它是否仍然有效。分析階段則針對大約二十種最常洩漏的憑據類型，傳送多個請求來了解誰建立了這個秘密、它能存取哪些資源，以及它在這些資源上擁有什麼權限。
第1-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第1-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第1-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第1-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第1-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第1-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
資料來源與掃描目標
命令面按資料來源組織成子命令。README 列出了 git、github、gitlab、huggingface、docker、s3、filesystem、syslog、circleci、travisci、gcs、postman、jenkins、elasticsearch、stdin 和 multi-scan。每個子命令有自己的參數，可透過 --help 檢視。快速入門部分展示了代表性用法：trufflehog git https://github.com/trufflesecurity/test_keys --results=verified 掃描倉庫，trufflehog github --org=trufflesecurity 掃描組織，trufflehog s3 --bucket=<bucket name> 掃描 S3 儲存桶，trufflehog gcs --project-id=<project-ID> --cloud-environment 掃描 Google Cloud Storage，trufflehog docker --image trufflesecurity/secrets 掃描容器映像，trufflehog filesystem path/to/file1.txt 掃描本機檔案和目錄。另有一個實驗性的 github-experimental 命令用於列舉 GitHub 倉庫中已刪除和隱藏的提交；README 警告這是 alpha 功能，列舉全部有效提交可能耗時二十分鐘到數小時，取決於倉庫大小。
第2-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第2-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第2-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第2-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第2-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第2-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
verified 狀態的含義
README 定義了三種結果狀態。verified 表示憑據已通過針對其所屬 API 的測試，被確認為有效且活躍。unverified 表示已偵測到但未確認有效，可能是無效、已過期或驗證被停用。unknown 表示驗證已嘗試但因錯誤而失敗，例如網路或 API 故障。README 以 AWS 偵測器為例：它呼叫 GetCallerIdentity API 來檢查 AWS 憑據是否活躍。對於私鑰，驗證會確認該金鑰能否實際用於 SSH 或 SSL 認證，使用的技術稱為 Driftwood，針對數百萬 GitHub 使用者和數十億 TLS 憑證。README 沒有給出偵測率、誤報率或驗證覆蓋率的具體數字，只給出了已宣告的偵測器數量。
第3-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第3-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第3-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第3-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第3-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第3-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
安裝與工件驗證
README 記錄了多種安裝方式。macOS 使用者可執行 brew install trufflehog。Docker 方式需要把目前目錄掛載到 /pwd；README 給出了 Unix、Windows 命令提示字元、Windows PowerShell 以及 M1/M2 Mac 的變體，後者使用 --platform linux/arm64。二進位發行版從 GitHub releases 頁面下載解壓。從原始碼編譯使用 git clone 後執行 cd trufflehog; go install。安裝指令碼位於 scripts/install.sh，-v 參數用於驗證檢查碼簽章，還可附加發行標籤參數以安裝特定版本。README 說明所有工件都有檢查碼，檢查碼檔案使用 cosign 簽章。驗證步驟需要從 releases 頁面下載檢查碼、pem 和 sig 檔案，先用 cosign verify-blob 並指定與 GitHub 工作流程相符的憑證身分正則，再執行 sha256sum --ignore-missing -c 確認工件雜湊。
第4-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第4-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第4-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第4-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第4-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第4-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
設定、自訂偵測器與命令列參數
命令列暴露了一組全域參數和每個命令的獨立選項。README 中的 git --help 輸出顯示了 --results，預設值為 verified,unverified,unknown；--json 輸出 JSON；--concurrency 設定並行數；--no-verification 跳過驗證；--fail 在發現結果時以 183 結束。偵測器選擇由 --include-detectors 和 --exclude-detectors 控制，封存掃描有大小、深度和逾時限制。透過 --config 傳入的設定檔可以定義自訂正則偵測器和多個來源；設定中的來源僅供 multi-scan 子命令使用，而自訂正則偵測器可用於任何子命令。自訂偵測器至少需要一個正則運算式和一個關鍵字，驗證交給 webhook，webhook 接收包含正則比對的 JSON POST；回傳 200 OK 則標記為已驗證，網路或 API 錯誤則標記為 unknown。README 將該功能標註為 alpha 且可能變更。文件還提到通用 JWT 偵測，適用於使用公開金鑰密碼學且公開金鑰可取得的 JWT。
第5-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第5-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第5-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第5-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第5-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第5-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
CI/CD 整合與結束碼
README 記錄了 GitHub Action，即 trufflesecurity/trufflehog@main，輸入參數包括 path、base、head、extra_args、version 和 image。範例工作流程對所有提取請求與推送到 main 的提交進行秘密掃描，fetch-depth 設為 0 以取得完整歷史。對於獨立工作流程，README 建議使用淺層複製，根據推送或提取請求事件的提交數計算 fetch-depth。GitLab CI 範例用安裝指令碼安裝工具，並在合併請求管線中執行 trufflehog filesystem "$SCAN_PATH" --results=verified,unknown --fail --json。預先提交鉤子文件在 PreCommit.md 中。結束碼有明確說明：0 表示無錯誤且無結果，1 表示掃描過程中遇到錯誤，183 表示無錯誤但發現了結果，且僅在 --fail 啟用時回傳。
第6-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第6-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第6-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第6-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第6-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第6-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
專案狀態、授權與穩定性
該倉庫用 Go 編寫，在中繼資料快照時有 27,308 顆星、2,519 個 fork 和 505 個未關閉問題。README 說 v3 是完全用 Go 重寫的版本，新增了 700 多個支援主動驗證的憑據偵測器，原生支援掃描 GitHub、GitLab、Docker、檔案系統、S3、GCS、Circle CI 和 Travis CI，並可作為 GitHub Action 和預先提交鉤子使用。自 v3.0 起專案以 AGPL-3.0 發布，README 說明此前的程式碼庫以 GPL 2.0 保留在倉庫歷史和早期套件發布中。授權文字授予複製、散布和修改軟體的自由，並針對網路伺服器使用要求營運者向公眾提供執行在可公開存取伺服器上的修改版本原始碼。授權文字還宣告除已提供的保證範圍外，該作品不提供任何保證，且未涉及支援、安全保證或維護承諾。README 明確警告公開 API 不穩定：專案處於重度開發階段，無法對穩定性做出任何保證。未來的貢獻需要先簽署 CLA。
第7-1個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第7-2個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第7-3個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第7-4個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第7-5個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
第7-6個章節檢查面向要以專案自己的檔案和指令為準。TruffleHog 可掃描 Git、檔案、容器與雲端來源，並以驗證器判斷秘密是否仍然有效，命令列輸出是主要操作介面。 使用者先確認目標版本、執行環境與相依套件，再對照 README 所列的輸入、輸出和限制。若要在團隊內採用，應把該專案的設定鍵、命令列參數、錯誤訊息和產物位置寫入測試紀錄，避免只憑首頁描述推斷能力。對於安全、效能或相容性要求較高的場景，應針對實際使用的模組建立可重跑案例，並觀察日誌是否顯示預期狀態。
編輯結論
TruffleHog：從提交與端點尋找洩漏的秘密 適合需要 README 涵蓋 Git、檔案、容器、雲端來源、驗證與自訂偵測器。 的團隊；不適合只想以根目錄 pnpm dev 啟動完整服務的人，因為 README 明確說明它是共用套件工作區。採用前先在指定套件目錄閱讀 README，執行 corepack pnpm install、pnpm lint 與 pnpm test，並用 pnpm ship:minor --projects=目標套件名稱 --dry-run 檢查發布範圍。
社群筆記