資安指南

543,699 組發布到 GitHub 的憑證仍可使用（2026 年研究）：為什麼要撤銷而非只是刪除，以及開發者該怎麼做

2026 年一項研究發現，公開儲存庫中的 543,699 組憑證仍可使用。為什麼刪除檔案不夠，以及該怎麼做：撤銷、檢查用量、更換。

發布於 2026-10-04 更新於 2026-10-04 最後核實 2026-10-04 閱讀時間 5 分鐘

本頁內容

適用對象：將程式碼存放在 GitHub 等公開儲存庫的開發者，以及經營 API 的公司。本文以本站自己的文字重述一家資安公司研究的數字，不涉及如何尋找他人的憑證。

這項研究是什麼（並非 GitHub 官方研究）

2026 年 9 月 29 日，銷售祕密掃描工具的資安公司 Truffle Security 發布了一項關於公開儲存庫中遺留憑證的研究。作為偵測工具的供應商，發布者在這個主題上有商業利益。本文引用研究的數字時會照實呈現，並將本站的解讀另外標示。

GitHub 並未洩露任何資料。憑證是由各儲存庫的擁有者寫入程式碼並公開的。GitHub 的角色是提供推送保護（阻擋含有祕密資訊的推送）等預防功能，而如下所示，這些功能涵蓋的類型有限。

研究如何進行，以及如何解讀數字

約 2.245 億

檢視的儲存庫數（The Stack v3）

2026 年 7 月 27–28 日

測試有效性的時間

僅預設分支

不包含提交歷史

已通過驗證

「有效」的意思（未檢查權限與濫用）

來源資料為 The Stack v3，這是第三方為訓練 LLM（大型語言模型）而收集的公開儲存庫資料集。收集於 2025 年 8 月 7 日結束。
只檢視收集當時的預設分支（例如 main）。較舊的提交、其他分支，以及更早已移除的內容都不包含在內。這並非對 GitHub 上所有公開程式碼的掃描。
「有效」表示服務提供者確認該憑證在 2026 年 7 月 27–28 日仍可通過驗證。有些可能之後已被撤銷。
自外洩至今的時間，是從含有憑證的檔案最後修改日期起算。研究指出，這種算法往往低估了實際時間。
部分類型未納入特定數字。Google API 金鑰僅針對 Gemini 進行測試，而私密金鑰若沒有其所屬主機便無法測試，因此兩者都未納入各類型的存活數字中。

數字：剩下多少，有多少

543,699

測試時仍有效的不重複憑證數

約 110 萬

跨檔案與儲存庫的出現總次數

784 天

自外洩至今的中位數時間

6.3 年以上

最舊 10% 的年齡（最舊可追溯至 2009 年）

2024 年 2 月 29 日當週，GitHub 開始對所有使用者預設開啟公開儲存庫推送的推送保護。根據研究，543,699 組有效憑證中，有 199,843 組（36.8%）出現在該日期之後。

此外，有效憑證中有 51.8% 屬於連線字串、Google API 金鑰或私密金鑰，這些類型的推送保護預設不會阻擋。對於推送保護涵蓋的類型，比較變更前後 12 個月的數據，每百萬個檔案的外洩數量下降約 53%。推送保護未涵蓋的類型僅下降約 7%。研究本身也指出，其他因素可能同時影響結果，例如同一期間雲端服務供應商推動客戶改用短效憑證。

各類型的存活數

下表根據研究公布的數量重新計算百分比。「發現數」為預設分支上找到的憑證數；「有效數」為測試時仍可通過驗證的數量。

類型	發現數	有效數	有效比例
npm 權杖	101,886	1	0.001%
Hugging Face 權杖	30,437	15	0.05%
GitHub 權杖	73,048	260	0.4%
Slack 權杖	8,903	198	2.2%
Stripe 金鑰（包含測試模式金鑰）	124,132	4,493	3.6%
AWS 存取金鑰	82,411	6,819	8.3%
Docker Hub 權杖	3,790	1,244	32.8%
SendGrid 金鑰	22,800	9,189	40.3%
Google Cloud 服務帳戶金鑰	126,963	69,041	54.4%
MySQL 連線字串	2,421	1,806	74.6%
PostgreSQL 連線字串	12,985	11,465	88.3%
MongoDB 連線字串	未計算	51,067	—

MongoDB 所用的偵測工具只記錄它成功連線的字串，因此無法計算比例，該類型也未納入存活數字中。這裡只報告有效數量。

為什麼各類型差異如此大

差異與其說來自憑證找不找得到，不如說來自找到之後是否有人會阻止它們。以下是在我們能確認的各服務提供者官方文件範圍內的情況。

發行方會自動阻止

GitHub 權杖：GitHub 說明，推送到公開儲存庫或 gist 的有效權杖會被自動撤銷
npm 權杖：自 2019 年起，npm 會撤銷透過 GitHub 發現的有效權杖，並寄電子郵件通知擁有者
Hugging Face：官方機制讓任何人（不限於擁有者）都能使外洩的權杖失效

只有你能阻止

資料庫連線字串：沒有發行方；只要你不更改密碼，它就一直可用
許多 API 金鑰：GitHub 通知發行方後，發行方如何處理由其自行決定
你自己伺服器的私密金鑰：只有擁有者知道它們被用在哪裡

GitHub 的祕密掃描合作夥伴計畫會通知發行方，告知其在公開儲存庫中發現的憑證。GitHub 的文件建議將其回報的任何祕密視為已公開且已外洩，但實作方式由發行方自行決定。發行方決定要撤銷、重新發行，還是聯絡使用者。

兩家雲端服務供應商的回應方式，與完整撤銷並不相同。

AWS：對於可能已外洩存取金鑰的 IAM 使用者，AWS 會附加名為「AWSCompromisedKeyQuarantineV3」的受管政策。該政策會拒絕某些動作，例如啟動執行個體或變更 IAM，但不會刪除金鑰。AWS 要求客戶不要移除該政策，並依照其開立的支援案件中的指示操作。
Google Cloud：自 2024 年 6 月 16 日起，在公開儲存庫等地點偵測到的服務帳戶金鑰，預設會自動停用。組織可透過組織政策限制條件 iam.serviceAccountKeyExposureResponse 選擇退出（WAIT_FOR_ABUSE）。研究仍發現超過一半的金鑰有效；研究並未說明原因。

本站的看法：刪除後副本仍會留在其他地方

研究本身使用的是 2025 年 8 月建立的資料集。如果擁有者在那之後才刪除檔案，該憑證仍存在於資料集中。分叉（fork）、他人的複製品、鏡像，以及搜尋或 AI 訓練資料也是如此。

因此，請將「推送到公開儲存庫」視為「已外洩」，並在發行方那一端讓憑證失效。改寫歷史只是清理工作，用來阻止進一步擴散。

你的儲存庫

刪除或改寫歷史

→

分叉、複製品、鏡像

在其他人的電腦上

→

資料集、封存檔

收集當時的副本

→

發行方已撤銷

所有副本都會失效

推送到公開儲存庫的憑證最後會去到哪裡。只有最左邊的副本能從你自己的儲存庫移除。

如果你發現自己外洩了憑證

向發行方撤銷金鑰

在主控台或 CLI 中停用該金鑰或權杖。若是資料庫連線字串，請更改該使用者的密碼，或重新建立該使用者。短暫停機的成本低於遭到濫用，因此不要拖延。

檢查是否遭使用與產生費用

查看外洩至撤銷之間是否有你不認得的活動：AWS 上的 CloudTrail、Google Cloud 上的 Cloud Audit Logs，以及寄信或付款服務主控台中的用量紀錄與帳單。如果 AWS 已附加隔離政策或開立支援案件，請依其指示操作。

重新發行金鑰並更換

不要把新金鑰寫進程式碼；請從環境變數或祕密管理工具載入。趁此機會縮減其權限、允許的來源 IP 與有效期限。

最後才清理歷史

使用 git filter-repo 等工具從歷史中移除，並強制推送。分叉與其他電腦上的副本仍然存在，因此這無法取代撤銷。

如果你發現他人的金鑰，請不要測試

如果你在他人的儲存庫中發現憑證，請不要檢查它是否可用。請通知擁有者或發行方。對於公開 GitHub 儲存庫中受支援的類型，GitHub 會通知發行方。

預防外洩

推送保護有幫助，但單靠它並不足夠。如數字所示，推送保護預設不阻擋的類型會直接通過，而使用者也可以選擇理由來繞過阻擋。請搭配以下措施。

提交前掃描：在推送之前，用 gitleaks 等掃描工具在自己的電腦上攔下祕密資訊（參見使用 gitleaks 在提交前阻擋祕密資訊）。
掃描舊儲存庫的歷史：推送保護對開啟之前的提交毫無作用。請至少對疏於維護與已封存的儲存庫完整掃描一次歷史。
使用短效憑證：GitHub Actions 可以透過 OIDC 連線 AWS 或 Google Cloud（每次執行時取得僅在短時間內有效的憑證），而不必儲存長效金鑰。Hugging Face 也提供相同做法。
限縮每個金鑰的能力：唯讀、僅限特定 API、限制來源 IP 或參照來源，並設定到期日。這能限制外洩可能造成的損失。
讓資料庫不暴露於網際網路：外洩的連線字串若無法從外部連線，便無法使用。資料庫連線字串是表格中存活時間最長的類型。

避免將祕密資訊留在程式碼中的基本做法，請參見.env 與 API 金鑰真正危險之處；留在網頁伺服器上的祕密資訊，則見公開目錄稽核。

給經營 API 的公司

表格頂端與底端的差別，在於發行方是否會自動阻止外洩的金鑰。作為保護使用者金鑰的一方，請考慮：

加入 GitHub 的祕密掃描合作夥伴計畫，並在收到通知時撤銷有效金鑰、通知使用者
為金鑰設計獨特的前綴（例如以服務名稱開頭），方便偵測
提供任何人都能回報並使外洩金鑰失效的管道或 API
將可到期的金鑰與權限範圍窄的金鑰設為預設

來源（公開紀錄）

本文中的數字來自以下公開來源。我們沒有重製研究的文字或圖表，只使用了其數量並重新整理。

Truffle Security（祕密掃描工具供應商）研究，2026 年 9 月 29 日 — trufflesecurity.com
報導：BleepingComputer（2026 年 9 月 30 日） / SecurityWeek（2026 年 10 月 1 日） / GIGAZINE（2026 年 10 月 2 日，日文）
GitHub：推送保護預設開啟（GitHub Blog） / 關於推送保護 / 支援的模式 / 合作夥伴計畫 / 權杖到期與撤銷
npm：npm Blog（2019 年 6 月 18 日）
Hugging Face：使用者存取權杖（撤銷外洩的權杖）
AWS：AWSCompromisedKeyQuarantineV3
Google Cloud：自動停用外洩的服務帳戶金鑰（2024 年 5 月 16 日） / 管理服務帳戶金鑰的最佳實務

FAQ

Q這是 GitHub 官方的研究嗎？

不是。這項研究於 2026 年 9 月 29 日由提供祕密掃描工具的資安公司 Truffle Security 發布。GitHub 並未洩露任何資料：憑證是由各儲存庫的擁有者寫入程式碼並公開的。GitHub 提供推送保護和祕密掃描等預防功能，但它們涵蓋的憑證類型有限。

Q我提交了一個 API 金鑰。刪除檔案或改寫歷史就夠了嗎？

一旦推送到公開儲存庫，副本可能已存在於分叉（fork）、他人的複製品、鏡像，以及像本研究所用的資料集中。刪除檔案或改寫歷史無法移除這些副本。第一步是向發行方撤銷該金鑰並重新發行。之後再清理歷史。

Q發行方不會自動撤銷外洩的金鑰嗎？

這取決於發行方。GitHub 的文件說明，推送到公開儲存庫的有效 GitHub 權杖會被自動撤銷，npm 自 2019 年起對其權杖也採取相同做法。然而，在 GitHub 的祕密掃描合作夥伴計畫中，發行方在收到通知後如何處理，由發行方自行決定。沒有發行方支持的憑證，例如資料庫連線字串，沒有任何人會阻止其使用。

QGitHub 的推送保護能防止這種情況嗎？

部分可以。預設情況下，推送保護會阻擋其支援模式清單中列出的特定權杖格式。GitHub 的模式清單顯示，Google API 金鑰以及 MongoDB 和 PostgreSQL 連線字串僅會發出警示，而不會被推送保護阻擋。使用者也可以選擇一個理由來繞過阻擋，或直接關閉此功能。建議搭配提交前掃描與短效憑證一起使用。

Q研究中的「有效」是什麼意思？

研究依模式比對憑證，然後詢問各服務提供者，該憑證在 2026 年 7 月 27–28 日是否仍可通過驗證。研究並未檢查這些憑證的權限，也未檢查是否遭到濫用。有些可能之後已被撤銷。