GitHub 密鑰掃描改用新分類器：靠上下文分辨真假密鑰，稱誤報更少、掃描更快

發生了什麼事

GitHub 在官方部落格發表文章，說明為密鑰掃描訓練的情境感知密鑰分類器。這裡的「密鑰」指密碼、API 金鑰、連線字串等不該公開的憑證；密鑰掃描就是在程式碼中找出這類內容的功能。GitHub 表示，密鑰掃描在兩個時間點運作：推送保護會在推送（把程式碼變更上傳到儲存庫，也就是存放程式碼的專案空間）被接受前掃描變更；推送後掃描則在程式碼提交後持續掃描儲存庫內容，偵測到潛在密鑰時建立警示。

GitHub 表示，與先前以 LLM（大型語言模型）為基礎的流程相比，新分類器使推送後掃描的執行時間中位數降低 86%。這項效率讓通用密鑰偵測得以延伸到推送保護，在開發者推送前就回傳結果。

為什麼通用密鑰難以判斷

GitHub 表示，通用型密鑰不一定有明顯的前綴、長度、字元集或 checksum（校驗碼，用來檢查資料是否正確的一串字元），其語法可能與建置識別碼、checksum、資產雜湊、範例值等非敏感字串重疊，因此上下文是決定性訊號。對一般讀者而言，這代表同一串字元在正式設定檔與測試範例中，意義可能完全不同。

新流程如何運作

GitHub 表示新掃描器採兩階段流程。第一階段用正規表示式（regex，一種以固定規則比對文字樣式的方法）大範圍找出候選字串，目標是「高召回」，也就是盡量不漏掉真的密鑰。第二階段由微調（針對這項任務再訓練）過的 ModernBERT 分類器評估每個候選及其周邊上下文；GitHub 形容這個模型小而有效率。模型輸入包含候選值、檔案路徑、密鑰類型與有限範圍的周邊上下文，輸出為分類分數，供掃描器決定候選是否繼續處理。

GitHub 表示，分類器可過濾佔位值、測試用的假資料（test fixture）與 checksum 等相似字串，高信心的發現才會成為警示。GitHub 也坦言，分類器只是盡力區分「看起來像密鑰」與「很可能是真密鑰」。

GitHub 公布的成效數據

表中的「精確率」指發出的警示中有多少真的是密鑰，「召回率」指真的密鑰有多少被找出來；「A/B 實驗」則是把新舊流程分給不同客戶使用後比較結果。GitHub 說明，接受度依儲存庫擁有者加權，是為了降低一次大量解決警示的客戶所造成的扭曲。

訓練與部署細節

GitHub 表示，訓練資料結合三個來源：來自 GitHub 儲存庫的產品衍生範例（含密鑰偵測功能的使用回饋與人工驗證）、高召回 regex 候選（含人工標註與弱標籤，後者指較粗略的自動標記），以及針對文件中的密鑰、測試用假資料、公開金鑰、checksum 等困難情境特別製作的合成範例。訓練前先把共用同一儲存庫、候選值或範例的資料列分組，避免近似重複資料同時出現在訓練與評估集。

GitHub 另表示，模型以 8 位元量化（用較低精度儲存模型數值）匯出為 ONNX 這種模型檔案格式，以加快推論，也就是模型實際做判斷的過程。後續聚焦兩個方向：利用生產環境回饋建立持續改進的循環，以及探索可一步完成密鑰偵測與擷取的新模型架構。

對一般讀者的實際意義

GitHub 表示，這應能讓開發者與資安團隊看到較少的誤報，並在提交、拉取請求（pull request）與日常開發流程中得到更快的回饋。GitHub 的說法是：精確率較高代表干擾的警示較少，召回率較高代表抓到更多真的密鑰，成本較低則讓它能持續擴大掃描涵蓋範圍。

查看同分類最新消息

• 科技新聞