GitHub 指出機密資訊保護須跟上軟件開發規模

現時，GitHub 上每三個拉取請求，就有一個涉及 AI Agent。一年前，這個比例還不到十分之一。若這個速度持續下去，未來兩年內，推送到 GitHub 的程式碼大部分可能都會由 Agent 編寫，其中不少可能從未經人類完整閲讀。

如果開發者和 Agent 的速度加快，我們有責任確保防護措施跟上程式碼加速生成的步伐。這意味著要在更多洩漏發生前將其阻止，並減少處理仍然發生的外洩時對人手操作的依賴。

這是處理洩漏機密資料的關鍵時刻。開發者並非變得更粗心，而是跟不上步伐。讓開發者能夠創作更多軟件的工具，也應承擔更多保護軟件的工作。

在這篇文章中，我會分享支持這個論點的九個季度數據。我亦會介紹我們與 Microsoft Applied Sciences 合作建立的微調分類器，藉此把推送防護擴展至非結構化機密資料。這個模型能在不到兩毫秒內評估一整組候選機密資料，令我們能夠阻止的機密資料數量增加一倍以上。

跟不上步伐，而非粗心

過去三年，每年都有大約每兩秒一次新的機密資料出現在公開可見的程式碼中，數量每年翻倍。公眾討論往往很快便認定是 AI 令開發者變得粗心。

由 2024 年 Q2 至 2026 年 Q2，經篩查的推送增加了 2.84 倍，而包含憑證的推送則增加了 2.59 倍。我們分析了九個完整季度的數據，沒有發現每次推送中機密資料出現比例有任何可統計檢測的趨勢。同時，數據顯示，開發者比以往更瞭解意外外洩的風險，也更不願承受這種風險。在同一時期，被開發者覆寫的推送路徑封鎖比例，從 6.63% 降至 3.93%，呈線性下降。這些數字對「Agent 正令開發者變得更粗心」這種常見説法提出質疑。

推送量增加，每次推送中的機密資料比例未見明顯上升

公開推送

推送中機密資料的比例

202M574M · 2.8×

0300M600M

0%0.5%1.0%

Q2Q3Q4Q1Q2Q3Q4Q1Q2202420252026

2026 Q2 · 574M 次推送 · 0.47% 包含機密資料

2024 年 Q2 至 2026 年 Q2 的公開推送。推送中機密資料的比例，是指檢測到機密資料的推送所佔比例。涵蓋受支援的供應商模式，包括 GitHub 自身的 token。

在比率固定的情況下，活動量增加一倍，預期外洩次數也會增加一倍。如果每次外洩都需要相同的人手處理，工作量也會增加一倍。手動撤銷機密資料的平均時間徘徊在 40 日左右；大約五分之一需時超過 90 日。我們正加快軟件的創作速度，但外洩的憑證仍可能在數星期或數月內繼續可用，因為人手補救處理無法跟上開發速度。

單靠提醒開發者更加小心，無法解決這個問題。隨著程式碼數量增加，我們必須阻止更多外洩，並減少處理其餘外洩所需的人手，才能讓軟件開發持續下去。

預防能力隨運算資源擴展

過去幾年，我一直在 GitHub 負責機密掃描，並在過去一年擔任該範疇的產品主管。我們帶來的最大影響，來自把偵測工作與能夠採取行動的系統連繫起來。

透過我們的機密掃描合作夥伴計劃，GitHub 的名錄涵蓋超過 150 個技術合作夥伴。我們透過合作夥伴計劃與參與的機密發行方合作，建立偵測器並通報公開外洩情況，讓他們作出應對。2026 年第二季，公開掃描成功回報平均每秒 26 次憑證命中，包括重複偵測結果。收到通知後，不少合作夥伴會立即撤銷 token，例如 OpenAI API 金鑰、Google Cloud 帳戶憑證、Slack webhook、Hugging Face 用戶 token、SendGrid 金鑰等。持有人可能仍需更換 token，但無須等待開發者找出並處理 GitHub 警示，撤銷便可即時進行。

推送保護會更早介入，在可辨識的憑證進入程式碼儲存庫歷史記錄前將其攔截，讓開發者或 Agent 有機會先修正變更，避免出現需要調查的外洩事件。我們與技術合作夥伴合作，盡可能提高其偵測器的精確率，直至我們有足夠信心，為開發者社羣預設啟用這些機密的推送保護。

有賴合作夥伴的努力，過去一個月，推送保護至少每秒封鎖一次機密。對於與發行方綁定的憑證，GitHub 封鎖的機密數量多於漏網的數量。我很自豪，我們已讓這對開發者而言成為再平常不過的事。

補救能力隨人力擴展

納入其他機密類型後，推送保護會在新偵測到的機密進入程式碼儲存庫歷史記錄前，攔截約 30%。其餘 70% 則要等到憑證不幸已經外洩後，我們才會發現。換言之：

預防能力隨運算資源擴展，但補救工作仍受限於人力。
拒絕一次推送需要運算資源；清理由可見歷史記錄洩漏的機密，則會耗費開發者的時間和心力。
隨著程式碼量增加，我們必須防止更多外洩事件，並減少處理其餘事件所需的人力，否則新增漏洞的數量將難以承受。

要求開發者更加小心，無法解決這種失衡。在開發流程較早階段識別更多這類機密，是平台必須承擔的工作。

解決四體問題

在機密越過推送邊界前，攔截成本很低，而且決定只有兩種：封鎖或允許。越過邊界後，同一字串便可能用來登入真實系統，而成本則沒有上限。

很多時候，我們唯一的偵測線索可能是周邊程式碼和外部世界的脈絡。服務供應商發出的 token 可能有可辨識的前綴。內部資料庫密碼則可能完全沒有結構，也沒有任何可辨識的模式。我們早已利用脈絡在推送後找出這些機密；問題在於如何將這種依據脈絡作出的判斷與其他因素取得平衡。

我們將機密資訊保護中的這種情況稱為「四體問題」：精確度、延遲、吞吐量和成本是相互牽制的限制條件。預防措施必須值得開發者花時間。一項適合稍後審查的發現，未必足以構成阻止推送的理由。誤報會打斷開發者，並令他們更難信任下一次攔截。檢查若太慢、成本太高或難以擴展，便會限制其執行頻率。

在推送時以不到 2 ms 提供保護

GitHub 的 AI 驅動通用機密資訊偵測模型會利用周邊程式碼的上下文，阻止資料庫 URL、Kubernetes Secret 資訊清單和 Dockerfile 中類似密碼的值，同時允許佔位符 changeme。

我們的新 ModernBERT 分類器會在上下文中評估候選機密資訊，不會生成程式碼或文字。它不僅比現有以 LLM 為基礎的處理流程更精確，速度也極快，評估一批候選項目只需不到兩毫秒。它的成本效益亦極高，足以在關鍵路徑中大規模執行。

將我們的模型納入推送保護後，我們能夠預防的機密資訊數量可增加一倍以上。此功能目前處於私人預覽階段。本月稍後，此功能將開放予在 Enterprise Cloud 和 GitHub Teams 使用 GitHub Secret Protection 的機構。此功能會消耗 AI 點數。

我們亦會將此模型帶到推送以外的開發者介面。

由今天起，任何 啟用 AI 機密資訊偵測的機構 將會自動 更新至 新模型。這些推送後掃描所產生的警示，仍包含在機構購買的機密資訊掃描服務中，無須額外付費。
此 模型亦將隨 GitHub Enterprise Server 3.23 一同推出 ，以公開預覽形式，讓 Secret Protection 客戶即使身處氣隙隔離環境，也能收到 AI 偵測的警示。
我們 會將分類器加入 Copilot CLI 和 Copilot App 的 /security-review 指令，因此 Copilot 用戶即使沒有機構的 GitHub Secret Protection 方案，也可以在推送前處理機密資訊。AI 點數用量會在你的 AI 用量分析中歸入 GitHub Secret Protection。

展望未來

我們希望迎來這樣的未來：開發者可以將更多工作交託予 Agent，而毋須監督每項請求；機構為保障憑證安全所需的人手，不再隨其編寫的程式碼數量增加。我們有責任在保護軟件方面，為開發者社羣帶來與軟件生產方面同樣的進展。

我們希望人們開發更多軟件。我們保護軟件的能力，應與創造軟件的能力同步提升。

文章機密資訊保護必須與軟件同步擴展最初刊登於The GitHub Blog。