資安業者 Truffle Security 近日公布一項針對 GitHub 公開儲存庫憑證暴露的研究，掃描約 2.25 億個公開儲存庫快照後發現，大量藏在程式碼裡的登入憑證並非陳年舊帳號，而是至今仍然有效的通關密鑰。這份報告揭露的數字相當驚人，也讓開源社群與企業 IT 部門重新審視程式碼上傳前的檢查流程。
研究團隊使用 The Stack v3 資料集中的約 2.25 億個 GitHub 公開儲存庫快照進行全面掃描，並在 2026 年 7 月實際驗證掃出的憑證是否仍可使用。結果顯示，共有 543,699 組憑證在驗證當時仍具備效力。更值得注意的是，這些憑證的暴露時間中位數達到 784 天，代表多數憑證已經在公開程式碼中躺了超過兩年。
從分布來看，暴露時間最長的前 10% 憑證，暴露時間甚至長達 6.3 年。換句話說，有些憑證在公開儲存庫中暴露超過六年依然有效，任何人只要翻閱這些公開程式碼，就可能撿到足以進入系統的鑰匙。
GitHub 自 2024 年 2 月起為所有免費帳號分批預設啟用 Push Protection 機制，在程式碼提交到公開儲存庫之前自動檢查，並攔截可辨識的 API 金鑰與存取權杖。研究團隊比較 2024 年 3 月前後各 12 個月的暴露情況，發現受到 Push Protection 預設防護的憑證類型，暴露密度下降 53%，未受預設防護的類型僅下降 7%。
不過研究團隊也提醒，這段期間 AWS 與 Google 同步推動有效期限較短的憑證與工作負載身分機制，因此無法排除這些外部措施同樣壓低了暴露數字。Push Protection 的防護效果雖然明顯，但並非憑證暴露下降的唯一原因。
另一個關鍵發現是 Push Protection 的預設保護範圍並不全面。在研究找到的仍有效憑證中，有 51.8% 並不在 GitHub 預設攔截的範圍內，包括資料庫連線字串、私鑰以及 Google API 金鑰。這類憑證即使走正常的提交流程，也不會被系統擋下。
此外，Push Protection 的定位是在程式碼提交階段阻止新的憑證進入公開儲存庫，對於已經暴露在外的舊憑證，並沒有自動撤銷的機制。過去提交的憑證只要沒人處理，就會一直留在公開的歷史紀錄之中。
不同類型憑證的存活率差異極大。NPM 權杖仍有效的比例僅約 0.001%，GitHub 權杖約為 0.36%；相較之下，Postgres 連線字串仍有效的比例高達約 88%，Google Cloud 服務帳號憑證則約為 54%。研究人員指出，GitHub 與 NPM 會主動撤銷自家外洩的權杖，但 Postgres 連線字串沒有同等的撤銷機制。
研究團隊建議，只要憑證曾經隨著程式碼提交到公開儲存庫，就應立即視為已經暴露。企業的第一步是先輪替相關憑證，再清理程式碼歷史紀錄；同時應回頭掃描既有的程式碼歷史，並優先採用具有有效期限的憑證，從源頭降低風險。
至於這些仍有效的憑證是否已經被攻擊者擷取或實際濫用，研究團隊表示並未確認。這也意味著真正的安全狀態仍是未知數，企業只能假設最壞的情況來因應。
這份研究的結論相當明確：程式碼公開前的一次檢查，擋得下未來的新增暴露，但擋不住過去的舊帳。對開發者與企業而言，定期掃描歷史提交、建立憑證輪替制度，恐怕比仰賴平台防護更為實際。
