GitHub 機密偵測模型以較少誤報找出更多憑證

我們的管線與先前 LLM 管線的比較

更智能的機密資料掃描，成本僅為原來的一小部分

11.5%

較高接受率

以擁有者加權的警示精確率

86%

較短的掃描執行時間中位數

推送後掃描

98%

較低的推論服務成本

小型模型與遠端 LLM 呼叫

只有開發者對掃描結果有信心，機密資料掃描才能發揮最佳效果。漏掉太多內容，真正的憑證便可能留在儲存庫中。警示過於頻繁，開發者便可能要花時間調查並非機密資料的字串。

通用機密資料尤其難以取得平衡。同一字串可能是真正的憑證，也可能只是文件中的佔位文字，因此要偵測出來，就必須理解周邊的程式碼和文字。

為應對這項挑戰，我們專門為 GitHub 的產品需求訓練了一個機密資料分類器：在符合大規模掃描所需的速度和效率要求下，區分真正的憑證與相似字串。

在配套文章 機密資料保護必須與軟件同步擴展 中，我們解釋了為何機密資料保護必須跟上 AI 加速的開發步伐。本文將深入介紹支援這項工作的上下文感知分類器：我們如何設計、訓練和評估它，以更少雜訊找出更多真正的機密資料。

我們提供的功能

GitHub 機密資料掃描在兩個關鍵時刻運作：

• 推送保護會在推送獲接納前掃描變更，協助防止機密資料進入儲存庫，並讓開發者有機會處理掃描結果。
• 推送後掃描會在程式碼提交後運作，持續掃描儲存庫內容，並在偵測到潛在機密資料時建立警示，讓開發者和保安團隊調查並修復問題。

我們開發了一個快速分類器，與先前以 LLM 為基礎的管線相比，將推送後掃描的執行時間中位數縮短了 86%。這種效率令我們得以把通用機密資料偵測擴展至推送保護，在開發者推送變更前，而不只是程式碼提交後，便傳回結果。

為何機密資料難以偵測

結構化憑證通常有獨特的前綴、長度、字元集或校驗和。通用機密資料則未必有這些特徵。其語法與建置識別碼、校驗和、資產雜湊值、範例值及其他非敏感字串相似。周邊上下文是關鍵判斷訊號。

這些都是困難負例：符合憑證模式、但並非可用憑證的字串。加入更多規則可以排除其中一些，但每個例外都可能導致真正的機密資料被隱藏。經訓練的分類器則可利用檔案路徑、機密資料類型、變數名稱，以及附近的程式碼或文字等訊號。

因此，我們推出了採用兩階段管線的新掃描器：

1. 候選項產生：正規表示式篩選器會掃描內容，找出潛在機密資料，並維持高召回率。此階段經過最佳化，可快速且以確定性方式捕捉廣泛類別的憑證格式模式。
2. 具備上下文感知能力的分類：經微調的 ModernBERT 分類器會評估每個候選項目及其周邊上下文。它經過訓練，能辨認出真正機密資料與誤報之間的差異訊號，包括佔位值、範例、文件片段、生成內容及非敏感識別碼。由於這個模型體積小，在我們的推理基建上運行效率高，服務成本遠低於基於 LLM 的流程，也更容易擴展。

成效：

• 用戶接受度提升11.5%，誤報減少。
• 推送後機密資料偵測的執行時間縮短86%。
• 與基於 LLM 的流程相比，成本節省超過98%。

我們的流程如何運作

掃描內容時，正則表達式模式會廣泛搜尋，並標記任何看似憑證的內容，以免一開始就漏掉真正的機密資料。接着，每個候選項目都會交由經微調的 ModernBERT 分類器處理；分類器會一併讀取該值、檔案路徑、變數名稱及周邊程式碼，再估算該項目是真正機密資料的可能性。高置信度的結果會觸發警示，而佔位值、測試資料及校驗和等類似項目，則會在傳到開發人員手上前過濾掉。

我們的流程如何運作

先廣泛搜尋，再仔細判斷

步驟 1

掃描

儲存庫內容、提交、拉取要求及其他掃描範圍。

步驟 2

產生候選項目

正則表達式模式會識別可能的權杖、金鑰及類似憑證的字串。

步驟 3

分類

經微調的 ModernBERT 會評估候選項目及其上下文，並判定其為真正機密資料的可能性。

步驟 4

發出警示或抑制

高置信度的結果會進入下一階段；可能的誤報則會被過濾。

重要的設計選擇是，模型不會取代確定性掃描，而是與之互補。正則表達式仍然是快速找出候選字串的合適工具。分類器則用於機器學習最能發揮作用的環節：區分「看起來像機密資料」與「很可能是真正的機密資料」。

棘手的負例問題：看起來幾乎像真的機密資料

大多數誤報並非隨機產生，而是棘手的負例：符合憑證模式、卻不能用作憑證的字串。例子包括文件中的佔位文字、測試中的簡單範例、已遮蓋的值、非敏感識別碼及生成的測試資料。正則表達式很容易匹配這些情況；若只靠規則，系統則難以將它們過濾掉，又不會意外漏掉真正的機密資料。

ModernBERT 可以連同鄰近的程式碼和文字一併讀取候選項目，因而具備媲美 LLM 的上下文理解能力，卻不需要承受生成自然語言輸出的延遲和計算開銷。例如，周圍出現「example」、「dummy」、「fake」或「replace-me」等字眼的候選項目，風險可能低於被指定給部署檔中某個環境變數的候選項目。分類器會從已標註範例中學習這些上下文差異，工程師毋須把每個例外都編寫成另一條規則。

我們選用 ModernBERT，因為它非常適合這項工作負載：體積小、效率高，而且適合對程式碼相關文字進行分類。就機密資料掃描而言，模型需要針對短小的候選片段作出經校準的判斷，同時保持高吞吐量和低延遲。

在流程的這個階段，微調後的編碼器分類器比通用大型語言模型更適合作為服務模型。模型可以直接根據我們的決策邊界進行訓練，並使用對機密掃描質素至關重要的同一組召回率和精確率指標進行評估。

我們如何訓練

挑戰在於找出具代表性的資料，涵蓋語法本身容易造成誤導的情況。訓練和評估策略結合了三種資料來源：

• 從 GitHub 儲存庫取得的產品衍生範例，並採用機密偵測功能的使用回饋及額外的人手驗證。
• 從 GitHub 儲存庫資料中取得的高召回率正則表達式候選項，包括人手標註的範例及用於擴大涵蓋範圍的弱標籤。
• 針對稀少及困難情況設計的合成範例，例如文件中的機密、測試樣本、公鑰、校驗碼、結構相似的內容，以及近似但不匹配的配對。

合成資料列在納入前，會通過確定性驗證及基於模型的質素審查。訓練著重真實機密、真實情境中的誤報，以及經常令只使用正則表達式的方法混淆的困難負例。每個模型輸入都包括候選值、檔案路徑、機密類型，以及有限範圍的周邊上下文。我們透過離線評估選定閾值，然後在擴大推出前，使用類似正式環境的流量驗證模型表現。

分割資料前，我們先將共用同一個儲存庫、候選值或範例的資料列分組，避免近似重複項目同時出現在訓練集和評估集中。

訓練著重最影響警示質素的情況：真實機密、真實情境中的誤報，以及正則表達式經常匹配到的困難負例。輸入表示包括候選機密字串、檔案路徑、類型，以及有限範圍的周邊上下文。輸出則是分類分數，供掃描器判斷是否應繼續處理該候選項。

我們以產品層面的取捨為優化目標：在維持或提高召回率的同時，減少誤報及服務成本。實際上，這代表我們會透過離線評估選定分類器閾值，再以類似正式環境的流量驗證，然後才推出。

最重要的訓練原則，是讓模型接觸容易混淆的範例。我們加入了語法上與真實機密相似、但語意不同的候選項，讓模型不只學會機密看起來是甚麼樣子，也學會誤報在上下文中的樣子。

訓練完成的模型會以 8 位元量化匯出為 ONNX 格式，以便快速推理。

評估結果

我們分兩個階段評估新流程在正式環境中的影響：先以同一批公開流量與正式環境基準比較，再進行客戶 A/B 實驗。 

• 離線評估：在推送後掃描中，以相同的公開流量進行評估時，新流程的精確率比先前的 LLM 流程高 13%，召回率高 19%。 
• 線上評估：接着，我們透過與先前 LLM 流程進行 A/B 實驗，驗證這些品質提升能否轉化為客戶成效。按儲存庫擁有者加權的接受率提升了 11.5%。我們按儲存庫擁有者加權計算接受率，以減少一次大量處理警示的客戶所帶來的影響；否則，這可能會令簡單平均值失真。 

重點回顧

最好的安全工具，是開發者信任並願意使用的工具。精確率越高，造成幹擾的警示就越少。召回率越高，捕捉到的真實機密資料就越多。成本越低，我們就越能持續擴大覆蓋範圍，而不會令掃描費用高得令人難以負擔。

對開發者和安全團隊而言，這應可減少誤報，並在最容易引入機密資料的環節加快回饋：程式碼提交、提取要求，以及日常開發工作流程。

混合式系統功能強大。正規表示式提供速度、透明度，並廣泛涵蓋候選項。ModernBERT 則具備透過學習取得的語境理解能力，並有助減少誤報。在這項產品限制下，兩者結合的表現優於單獨使用任何一種方法。

我們亦瞭解到，模型規模不等於模型效用。當任務範圍狹窄、決策邊界可量度，而模型服務效率至關重要時，較小型的微調分類器可能是合適的選擇。

這是讓機密資料掃描更準確、更具可擴展性且更易使用的一步。展望未來，我們會專注於兩個方向：

• 建立持續改進的飛輪。我們會利用正式環境的回饋循環，找出新的漏報和誤報，並將真實世界的訊號轉化為更高質素的訓練及評估數據。
• 探索新的模型架構。我們正研究能否以單一步驟完成機密資料偵測和提取的方法，在維持準確度和可擴展性的同時，降低流程複雜度。

鳴謝

衷心感謝 GitHub 和 Microsoft 的工程、科學及產品團隊，協助為這款新的機密資料掃描器建立訓練數據、評估套件、服務堆疊及推出計劃。

文章 GitHub 的機密資料偵測模型：以更少雜訊找出更多機密資料 最初刊登於 The GitHub Blog。