讓秘密掃描更可信：大規模減少誤報

秘密掃描在保護開發者和組織方面發揮着關鍵作用。它有助於及早發現暴露的憑證，防止小錯誤演變成真正的事件。在 GitHub 的規模下，即使是微小的低效率也會造成實際的摩擦。過多的誤報使得警報難以被信任。

當警報顯得嘈雜時，開發者會花費更多時間進行分類，而不是修復真正的問題。久而久之，這會拖慢修復速度並降低對系統的信心。

為了解決這一挑戰，GitHub 與微軟安全與 AI 的 Agents Offense 團隊合作，將更多上下文推理引入 GitHub 的秘密掃描驗證環節。該合作應用了 Agentic Secret Finder 的驗證方法——這是一個更廣泛的檢測和驗證系統，旨在理解上下文中潛在的秘密，而不僅僅是判斷它們是否匹配秘密模式。這幫助 GitHub 探索了在保持秘密掃描預期覆蓋範圍的同時，減少低價值警報的方法。

當前 GitHub 的秘密掃描將基於模式的檢測與基於 AI 的檢測相結合，以識別潛在秘密。基於模式的檢測可捕獲已知的秘密格式，例如令牌和 API 密鑰的合作伙伴模式。AI 驅動的通用秘密檢測則擴展到不匹配已知供應商模式的結構化秘密（如密碼）。

GitHub 已經在供應商模式秘密檢測方面擁有行業領先的精度，覆蓋數十億次推送，保護着數百萬個倉庫中的數千萬開發者。隨着 GitHub 擴展到 AI 驅動的秘密檢測，下一個挑戰是將 AI 檢測到的秘密的精度提升到接近供應商模式檢測的高標準。此次合作聚焦於將 GitHub 的大規模檢測管道與基於 LLM 的上下文驗證相結合，以提高警報質量和開發者信任。

我們的方法是讓秘密掃描警報值得信賴。當你能迅速判斷哪些警報需要處理時，秘密掃描最為有用。GitHub 已有減少噪音的保障措施，但某些類似秘密的值需要更多上下文來確定它們是否代表真正的暴露。為了讓這些警報更易於信任，我們在驗證步驟中增加了更多推理。通過觀察檢測到的值在代碼中的使用方式，系統可以更好地區分真正的暴露和看似敏感的值。這幫助開發者減少調查低價值警報的時間，專注於修復重要問題。

該方法直接建立在現有系統之上。檢測繼續生成候選結果，驗證步驟對其進行評估。更強的上下文感知能力使系統能更好地區分真正的秘密和噪音。結果是精度提高，而不改變上游檢測邏輯或降低覆蓋範圍。

關鍵挑戰在於決定提供哪些上下文。一小段代碼通常不足以判斷某個值是否是真正的秘密。同時，傳遞整個文件或倉庫會引入過多噪音並增加成本和延遲。因此，我們不是提供更多上下文，而是提供更好的上下文。我們不發送大量代碼，而是提取一小部分高信號信息，幫助解釋該值的使用方式。例如，我們查找值被賦給變量後用於 API 請求、身份驗證頭、數據庫客户端或雲 SDK 調用的案例。模式匹配可以告訴我們某個值看起來像秘密，但無法判斷它是否真的被用作秘密。周圍的用法上下文幫助模型區分真正的暴露和誤報（如隨機 UUID 或不透明字符串），而無需審查整個文件或倉庫。

大多數誤報可以通過集中的文件級上下文來解決。重要的不是模型看到多少代碼，而是它是否擁有正確的信號。在許多情況下，通過查看單個文件內的使用方式，就可以判斷一個值是否是真正的秘密。類似佔位符、測試數據或未使用的配置的值通常可以在無需深入分析的情況下被過濾掉。這使得系統既高效又實用：高精度、低延遲，並能跨大型代碼庫擴展。

我們在數百個客户確認的誤報警報上評估了這種方法。目標是減少 65%，實際結果是 75.76%，超出了目標，同時保持了強大的檢測性能。這意味着噪音顯著減少，需要處理的警報比例更高。這種改進直接體現在開發者體驗上：無關警報減少，更容易信任所見內容，分類噪音的時間減少，真正的問題能被更快地優先處理和修復。

我們正在持續評估更大數據集和實時流量下的方法，同時改進上下文提取和用於驗證的方式。減少誤報一直是大規模環境下的持續需求。這項工作專注於在最需要的地方提高信號質量，使警報更容易被信任和採取行動。目標很簡單：更少干擾，更清晰信號，對真實風險更快行動。