CISA 憑證擺上 GitHub：連網安機構都會犯嘅 secret 泄漏課

圖：Ars Technica．原文連結

美國網安機構 CISA 今次出事，重點唔係「連專家都會犯錯」咁簡單，而係一個好日常、好容易被低估嘅開發流程問題：有人將本來只應該留喺 secret manager、雲端 IAM 或受控工作環境入面嘅憑證，放咗入公開 GitHub repo。據 Ars Technica 引述 KrebsOnSecurity 報道，外洩內容包括明文密碼、SSH private key、token、雲端 key 同其他 CISA 相關敏感資產；GitGuardian 研究員先由公開程式碼掃描發現，再因為 repo 擁有人冇回應而轉交媒體及相關單位跟進。

呢件事特別刺眼，因為 CISA 本身就係美國負責民用聯邦網安協調同最佳實務建議嘅機構。KrebsOnSecurity 報道指，涉事公開 repo 由 CISA 承包商相關人員維護，公開時間最少可追溯至 2025 年 11 月；安全顧問 Philippe Caturegli 亦聲稱曾核實部分雲端憑證仍然有效。CISA 對媒體回覆時表示正調查事件，並稱目前未有跡象顯示有敏感資料因事件被盜用。呢句好重要：而家可確認嘅係「憑證曾經公開暴露」，唔等於已證實有人入侵或偷走資料。

但資安事故最麻煩嘅地方，就係公開 repo 係互聯網上最容易被機械化掃描嘅地方之一。即使涉事 repo 已經下線，Git history、第三方 cache、搜尋索引、fork 或外部掃描系統都可能令風險唔止停留喺「刪走就冇事」。TechLab 唔會轉載 repo 截圖、檔名細節或任何疑似 credential；今次更值得拆解嘅，是點解一條 SSH key 或 API token 一旦入過 repo，就應該當成已經暴露，然後即刻撤銷、重發同追蹤使用紀錄。

問題唔係 GitHub，而係將 secret 當文件管

GitHub 本身有 secret scanning。官方文件寫明，當 API key、密碼、token 等硬編碼憑證被 commit 入 repo，GitHub 可以掃描 repository 所有 branch 嘅 Git history，偵測已知 secret 類型；公開 repo 會免費自動掃描。佢亦會掃 issue、pull request、discussion、wiki、secret gist 等位置。即係話，防線唔只係「有人 review code」咁簡單，而係平台層面已經知道開發者會錯手將 secret 貼入 code、log 或設定檔。

另一層係 push protection。呢個功能嘅目標唔係事後出 alert，而係喺 secret 真正入 repo 前阻擋 push。GitHub 文件顯示，個人帳戶層面嘅 push protection 會預設阻止用家將 secret 推上公開 repo；但 repository／organization 層面嘅 push protection 需要按設定啟用，亦有 bypass、例外同 delegated bypass 等治理問題。Krebs 報道引述 GitGuardian 研究員指，涉事帳戶 commit log 顯示有人關掉本來可阻擋 SSH key 或 secret 進入公開 repo 嘅預設防護。呢個位比「有人唔小心貼錯」更嚴重，因為佢代表警報曾經出現過，但流程容許人手繞過或關閉。

將 secret 放入 Git，最大問題係 Git 係為咗保存歷史而設計。你今日喺最新 commit 刪走一個 token，舊 commit 仍然會留住同一段內容，除非刻意清理 history；就算你 rewrite history，曾經 clone 過、fork 過、掃描過嘅外部副本都唔會自動消失。所以資安團隊通常唔應該將「刪除檔案」當成補救，而係要當該 credential 已經失效：撤銷舊 key、開新 key、縮權限、睇 CloudTrail 或同類 audit log、確認有冇異常 API call，之後先再處理 Git history 同內部稽核。

SSH key、API token 入 repo 點解咁危險

SSH private key 同 API token 最大差異，是前者多數代表「可登入某部機或某段基建」，後者多數代表「可對某個服務做 API 操作」。但對攻擊者嚟講，兩者都係捷徑：唔使爆破密碼、唔使釣魚，只要 key 仍然有效，就可以直接試存取。更麻煩係好多公司嘅開發、測試、CI/CD、artifact registry、container registry、monitoring、ticketing、AI API 都互相串住；一條權限過大嘅 token，可能由讀取 config 變成存取 production secret，再由 build pipeline 變成供應鏈污染。

雲端 key 尤其高風險，因為雲端 API 係自動化世界嘅控制面。AWS IAM 官方最佳實務建議，人同 workload 都應該盡量用 temporary credentials，例如透過 identity provider、IAM role 或 STS assume role，而唔係派長期 access key 到處用；同時要用 MFA、least privilege，定期檢視同移除冇用嘅 user、role、policy 同 credential。換句話講，真正嘅目標唔係「永遠唔會漏」，而係就算漏咗，key 已經過期、權限好細、用法可追蹤、輪換唔會癱瘓 production。

CI/CD 係另一個容易被低估嘅位。好多 startup、學校 project、freelance job 或公司內部工具，都會喺 GitHub Actions、GitLab CI、CircleCI、Jenkins、Vercel、AWS、GCP、Azure 之間傳 secret。方便做法係直接將長期 key 放入環境變數，但成熟做法應該係用 OIDC federation、short-lived token、per-environment secret、branch／environment approval、protected runner、artifact signing，同埋清楚分開 build、deploy、production admin 權限。否則一個 repo 或 runner 出事，影響唔會停喺 source code，而係伸延到整條部署鏈。

行業已經唔係第一次見到

GitGuardian 2026 年 State of Secrets Sprawl 報告顯示，2025 年公開 GitHub commits 新增約 2,864 萬個 hardcoded secrets，按年升 34%；公開 GitHub commits 約 19.4 億，按年升 43%。AI 服務相關 secret 亦升得特別快，報告指 2025 年有約 127.5 萬個 AI-service secrets 暴露，按年升 81%。呢啲數字唔係話 AI 寫 code 必然更危險，而係開發速度、整合數量、service account、MCP config、agent 工具同本機環境存取一齊增加時，secret 數量會爆炸式上升。

同一份報告亦指出，internal repositories 比 public repositories 更容易藏住 hardcoded secret，比例約高 6 倍；另外約 28% secret sprawl 事故源自 Slack、Jira、Confluence 等協作或生產力工具，而唔係 code repo 本身。呢個脈絡解釋咗點解「我個 repo 係 private」唔係免死金牌。private repo、內部 wiki、incident channel、臨時 debug ticket，全部都可能係 credential 最終落腳嘅地方。工具可以掃出一部分問題，但流程文化如果容許大家為咗趕 deadline 貼 key、截圖、分享 .env，掃描只會變成事後清潔。

所以今次 CISA 事件真正值得學嘅，不是笑一個承包商，而是問自己公司有冇足夠防止「單一個人決定」變成「全公司雲端風險」。如果 developer 可以用私人 GitHub 帳戶同步工作資料、可以將公司 secret 放入非受管 repo、可以關掉保護、可以長時間保留有效雲端 key，而組織冇 central audit、冇 alert、冇 key ownership、冇定期輪換，咁事故只係等時間發生。越多外判、越多 SaaS、越多 AI coding assistant，呢個問題越唔可以靠口頭提醒解決。

香港公司應該點自查

今次事件冇港行、港版價或香港本地服務變動；對香港嘅實際關係，在於同一套開發模式本地都好常見。HKCERT 2026 年展望指，香港 2025 年錄得 15,877 宗網安事故，按年升 27%；2026 年主要風險包括 AI 相關攻擊、供應鏈漏洞、第三方保安缺口，以及過度依賴雲端基建。報告亦提到公司越來越依賴外判服務同第三方平台，而合作方一旦有保安漏洞，影響可以連鎖傳到客戶組織。呢個講法同今次 CISA 承包商事故好貼近。

本地 IT team、agency、startup 同 freelance developer 可以即刻做一輪簡單但實際嘅自查：

• 喺 GitHub organization 開啟 secret scanning、push protection、branch protection 同 audit log review，並限制邊個可以 bypass。
• 用工具掃 public、private、archived repo 同 Git history；唔好只掃 main branch 最新版本。
• 將 AWS、GCP、Azure、OpenAI、Stripe、GitHub token 等 secret 全部盤點 owner、用途、權限、最後使用時間同輪換週期。
• CI/CD 優先改用 OIDC 或 short-lived credentials；長期 key 要設 expiry、least privilege 同環境分隔。
• 一旦發現 secret 入 repo，先 revoke／rotate，再查 log，同步通知受影響系統 owner；刪檔同清 history 係後續動作。
• 明確禁止用私人 repo、個人雲端硬碟、chat group 或 ticket comment 儲存公司 secret，並為外判帳戶設 offboarding checklist。

最後要講清楚：secret scanning 係必要防線，但唔係保險箱。真正嘅安全做法，是令 secret 冇需要出現喺 repo；要出現時就短期、細權限、可追蹤、可撤銷。CISA 呢單事故暫時未證實造成敏感資料被盜用，但佢已經示範咗一個殘酷現實：越有經驗嘅組織都會有人犯低級錯，分別只在於系統有冇足夠設計，令低級錯唔會變成高權限事故。

參考來源

• Ars Technica — In stunning display of stupid, secret CISA credentials found in public GitHub repo — original report
• KrebsOnSecurity — CISA Admin Leaked AWS GovCloud Keys on Github — 事件主報道，提供 GitGuardian 發現、CISA 回應、承包商背景同外洩時間線。
• TechCrunch — US cyber agency CISA exposed passwords and cloud keys — 補充 CISA 對外回覆，確認暫未有跡象顯示敏感資料被盜用。
• GitHub Docs — About secret scanning — 官方說明 secret scanning 點樣掃 Git history、public repo 同 remediation 建議。
• GitHub Docs — About push protection — 官方說明 push protection 點樣喺 secret 入 repo 前阻擋，以及 bypass／組織設定限制。
• AWS IAM — Security best practices in IAM — 官方雲端權限建議，包括 temporary credentials、IAM role、MFA、least privilege 同 access key 更新。
• GitGuardian — State of Secrets Sprawl 2026 — 行業數據來源，提供 GitHub hardcoded secret、AI service secret、internal repo 同協作工具外洩趨勢。
• HKCERT — Hong Kong Cybersecurity Outlook 2026 — 香港脈絡來源，支持本地供應鏈、第三方平台、雲端依賴同企業網安資源分析。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。