程式碼裡的 API 金鑰外洩：被掃走只要幾分鐘
API 金鑰推上公開的 GitHub 後，可能幾分鐘內就被自動化程式找到並拿去用：Palo Alto Networks Unit 42 的實驗中，攻擊者在金鑰公開後 5 分鐘內就開始使用。發現外洩，第一步是撤銷並更換金鑰，只刪程式碼不夠。
「幾分鐘」是怎麼量出來的？
資安公司 Palo Alto Networks 旗下的 Unit 42 研究團隊在 2023 年 10 月發表研究：他們刻意把一組 AWS（亞馬遜雲端服務）的存取金鑰，放進一個公開的 GitHub 儲存庫（repo，也就是放程式碼的專案空間），觀察誰會來用。結果攻擊者在金鑰公開後 5 分鐘內就偵測到並開始使用；紀錄顯示，AWS 自動替這組金鑰套上隔離限制後僅 4 分鐘，對方就開始探查帳號。
研究團隊判斷，對方是用自動化工具持續複製公開 repo、找裡面的 AWS 金鑰。為了看清完整手法，研究團隊把隔離限制拿掉，接著看到對方在多個區域重複開雲端主機，超過 400 次 API 呼叫只花了 7 分鐘，目的是挖門羅幣（一種加密貨幣）。Unit 42 把這個行動命名為 EleKtra-Leak。
另一家雲端資安公司 Orca Security 在 2023 年 1 月到 5 月做的誘捕實驗（honeypot，故意放出誘餌觀察攻擊者）也看到類似結果：放在 GitHub 的 AWS 金鑰，2 分鐘內就被使用。GitHub 官方文件也直接寫：自動化掃描程式可以在幾分鐘內找到公開曝露的金鑰，幾小時內就可能被惡意利用。
要看清條件：這些數字來自「公開 repo 裡的 AWS 金鑰」。同一份 Orca 報告中，放在 S3 儲存空間的金鑰約 8 小時才被使用，位置不同差很多，但結論一樣：別指望沒人注意到。
平台也有自動防護，例如 GitHub 偵測到合作服務商的金鑰時會通知對方處理，但 Unit 42 也指出，攻擊者可能找得到平台沒偵測到的金鑰。平台的保護是補位，不是保險。
外洩到底有多普遍？
GitGuardian 是專門做金鑰外洩偵測的公司，每年發布《State of Secrets Sprawl》報告。2026 年 3 月發布的第 5 版統計：
- 2025 年公開 GitHub 的 commit（每一次提交的程式變更）裡，新偵測到 28,649,024 筆密鑰，比前一年多 34%。
- 與 AI 服務相關的密鑰外洩有 1,275,105 筆，年增 81%。
- 2022 年偵測到的有效密鑰，四年後仍有 64% 可以使用。
- 約 28% 的外洩事件來自協作與辦公類工具，而不只是程式碼庫。
- 內部 repo 含有寫死密鑰的機率，約是公開 repo 的 6 倍。
最後一點值得企業特別注意：「我們的 repo 是私有的」不等於安全。權限給太寬、帳號被盜或整包交出去，裡面的金鑰就跟著出門。
金鑰通常是從哪裡漏出去的？
| 外洩途徑 | 常見情境 | 為什麼危險 |
|---|---|---|
| 推到公開 repo | 測試專案、範例程式設成公開 | 自動化掃描幾分鐘內就可能找到 |
| 寫在前端程式或 App | 為了方便，把金鑰直接放在網頁程式裡 | 使用者打開瀏覽器就看得到 |
| 留在 commit 歷史 | 發現後再提交一次把金鑰刪掉 | 舊版本仍在歷史紀錄，以及別人複製出去的副本（clone、fork）裡 |
| 設定檔與聊天工具 | .env 設定檔被一起提交、在群組或工單貼金鑰給同事 |
看得到的人比你想的多 |
| 交給外包或 AI 工具 | 整包專案連同設定檔交出去 | 金鑰的去向不再由你掌控 |
把整個專案丟給 AI 程式助理時，.env 這類設定檔很可能一起被讀取、送出，資料邊界可以參考〈AI 說沒讀檔，整個 Repo 卻出門了〉。GitGuardian 也觀察到，AI 輔助產生的程式碼，金鑰外洩率全年平均約是 GitHub 整體基準的兩倍；報告同時提醒，這些外洩可能終究反映人的疏失，不只是 AI 的問題。用 AI 快速做出來的專案還有哪些常見漏洞，可以看〈AI 寫的程式安全嗎？Vibe Coding 常見的資安漏洞〉。
發現金鑰外洩，處理順序是什麼？
GitHub 官方文件寫得很直接：只把金鑰從程式碼刪掉、推一個新 commit，甚至刪掉 repo 重建，都無法阻止金鑰被濫用。建議照這個順序：
- 先撤銷或更換金鑰：到服務商後台撤銷並產生新金鑰。公開、仍有效或正式環境用的金鑰，GitHub 建議立即撤銷；擔心服務中斷，可以先產生同權限的新金鑰、讓程式改用新的，再撤銷舊的。
- 找出所有用到這把金鑰的地方：程式、部署設定、自動化流程、第三方整合，一起換成新金鑰。
- 查使用紀錄與帳單：看服務商的稽核紀錄（例如 AWS 的 CloudTrail），找不明呼叫、新建立的金鑰或帳號，並對照費用與用量。AWS 官方建議檢查所有區域的資源，EleKtra-Leak 正是在多個區域開主機。
- 評估影響範圍：這把金鑰能讀寫哪些資料、外洩了多久、有沒有牽涉客戶個資；若涉及個資，後續通報可參考〈個資外洩後企業要做什麼？通報與責任一次看懂〉。
- 最後才清理程式與歷史：改寫 Git 歷史有副作用，而且金鑰仍可能留在別人的複本、fork 和引用它的 pull request 裡。GitHub 文件也提到，金鑰撤銷或更換後就無法再使用，有時不必再改寫歷史。
怎麼避免下一次？
- 金鑰不寫進程式碼：改用環境變數或雲端的密鑰管理服務，
.env加進.gitignore（告訴 Git 不要追蹤的檔案清單）。Google Cloud 官方文件把「不要把 API 金鑰放在用戶端程式碼或提交到程式碼庫」列為最佳做法之一。 - 上傳前就擋下來：GitHub 的 push protection 會在含金鑰的推送進到 repo 前攔下。個人帳號版本預設開啟，但只擋推到公開 repo；repo 層級的 push protection 需要 GitHub Secret Protection，預設關閉，要由管理員啟用。預設情況下，有寫入權限的人可以填理由略過，所以仍要搭配審查。
- 持續掃描：公開 repo 的 secret scanning 免費自動執行，會掃所有分支的完整 Git 歷史；組織的私有 repo 要啟用 GitHub Secret Protection 才有。
- 最小權限、設上限：每把金鑰只給需要的權限並加上使用限制，每個人、每個應用程式用各自的金鑰；在服務商後台設定用量或費用警示。
- 定期輪替、刪掉不用的：Google Cloud 建議定期建立新金鑰、更新程式後刪除舊金鑰，也建議刪掉不再使用的金鑰，縮小被攻擊的範圍。
我怎麼知道自己的程式有沒有這個問題？
先用這張清單自問：
- 程式碼或設定檔裡，有沒有直接寫死的金鑰、密碼或 token？
- 網頁前端或 App 裡，有沒有能呼叫付費服務的金鑰？
- Git 歷史裡是否曾提交過
.env，就算現在已經刪掉？ - 有沒有在聊天群組、工單或文件裡貼過金鑰？
- 外包交接或人員離職後，金鑰有沒有全部換新？
- 專案用到的相依套件（別人寫好的程式庫），有沒有已知漏洞？
任何一題答不出來，就值得找人系統性檢查。智盾資安服務的檢測面向之一就是程式源碼與金鑰外洩，涵蓋硬編碼金鑰（直接寫死在程式裡的金鑰）、外洩憑證與有已知漏洞的相依套件，並交付風險分級報告與優先修補建議；奧微本身是軟體開發團隊，檢測後也可協助修補（依需求另議）。程式會一直改，檢測只反映當時的狀態，建議定期複測。
資料來源與核對日期
- Palo Alto Networks Unit 42（William Gamazo、Nathaniel Quist），〈CloudKeys in the Air: Tracking Malicious Operations of Exposed IAM Keys〉，https://unit42.paloaltonetworks.com/malicious-operations-of-exposed-iam-keys-cryptojacking/ ，2026-10-07 核對。
- Orca Security（Bar Kaduri、Tohar Braun），〈2023 Honeypotting in the Cloud Report: Attackers Discover and Weaponize Exposed Cloud Assets and Secrets in Minutes〉，https://orca.security/resources/blog/2023-honeypotting-in-the-cloud-report/ ，2026-10-07 核對。
- GitGuardian，〈The State of Secrets Sprawl 2026〉，https://www.gitguardian.com/state-of-secrets-sprawl-report-2026 ，2026-10-07 核對。
- GitGuardian，〈AI Is Fueling Secrets Sprawl. GitGuardian Reports an 81% Surge of AI-Service Leaks as 29M Secrets Hit Public GitHub〉，https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026-pr/ ，2026-10-07 核對。
- GitHub Docs，〈Remediating a leaked secret in your repository〉，https://docs.github.com/en/code-security/tutorials/remediate-leaked-secrets/remediating-a-leaked-secret ，2026-10-07 核對。
- GitHub Docs，〈Removing sensitive data from a repository〉，https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository ，2026-10-07 核對。
- GitHub Docs，〈Secret scanning〉，https://docs.github.com/en/code-security/concepts/secret-security/secret-scanning ，2026-10-07 核對。
- GitHub Docs，〈Push protection〉，https://docs.github.com/en/code-security/concepts/secret-security/push-protection ，2026-10-07 核對。
- AWS re:Post Knowledge Center，〈What can I do if I notice unauthorized activity in my AWS account?〉，https://repost.aws/knowledge-center/potential-account-compromise ，2026-10-07 核對。
- Google Cloud，〈Best practices for managing API keys〉，https://docs.cloud.google.com/docs/authentication/api-keys-best-practices ，2026-10-07 核對。
作者與關係揭露
本文由奧微軟體開發企業社發布。內容為一般資安知識整理，不構成個別系統的檢測結論；奧微軟體提供與本文主題相關的智盾資安服務。
常見問題
API 金鑰外洩了怎麼辦？
先到服務商後台撤銷並更換金鑰，找出所有用到它的服務一起更新，接著查稽核紀錄與帳單、評估影響範圍，最後才清理程式與 Git 歷史。
把金鑰從 GitHub 的 commit 刪掉就安全了嗎？
不夠。GitHub 官方文件指出，只刪程式碼、推新 commit 甚至重建 repo，都無法阻止金鑰被濫用；舊版本還可能留在歷史、複本與 fork 裡，一定要撤銷金鑰。
外洩的 API 金鑰多快會被盜用？
Unit 42 的實驗中，放進公開 GitHub repo 的 AWS 金鑰 5 分鐘內就被使用；Orca Security 的誘捕實驗觀察到 2 分鐘內。不同位置與服務差異很大。