CISA GitHub 密鑰外露未算確認入侵，但香港公司要即刻自查

圖：TechCrunch．原文連結

美國網安機構 CISA 今次出事，最刺眼唔係有黑客成功入侵，而係一個更日常、更容易發生嘅錯誤：承包商員工將載有明文密碼、cloud keys、tokens 同敏感檔案嘅資料放入公開 GitHub repo。CISA 對外表示仍在調查，暫時未有跡象顯示敏感資料因事件被入侵或外洩；但事件已經足夠提醒任何有開發團隊嘅公司，公開 repo 唔只係程式碼展示窗，錯用起上嚟可以直接變成雲端後門。

呢件事同香港無直接受害證據，亦唔應該寫成美國政府政治新聞。不過香港公司、startup、freelance 開發者同 IT vendor 一樣會用 GitHub、AWS、CI/CD、Slack、Jira、外判開發同個人裝置。只要一條密鑰有權限開雲端資源、讀 log、拉 production database、改 deployment pipeline，洩漏就唔再係工程師手滑咁簡單，而係身份、權限同供應商管治同時失守。

發生嘅唔係普通 typo

TechCrunch 引述 Brian Krebs 嘅報道指，GitGuardian 研究員 Guillaume Valadon 發現一個由 CISA 承包商相關人員維護嘅公開 GitHub 環境，入面有大量明文憑證同敏感檔案。報道提到，相關憑證可用於 CISA 及其母機構美國國土安全部部分系統，種類包括 access tokens、雲端密鑰、密碼表同其他內部檔案；研究員曾測試部分 key，確認並非純粹假資料。因為相關 GitHub 帳戶未有回應提示，事件之後再經 KrebsOnSecurity 披露。

要分清楚，公開曝光唔等於已確認被惡意入侵；但公開曝光已經係事故。公開 GitHub repo 可以被搜尋、被第三方掃描、被快取、被 fork，亦可能被自動化工具喺短時間內抄走。TechCrunch 報道入面，CISA 未有講清楚有無撤銷同更換所有外露憑證；Krebs 亦引述研究員指部分雲端 key 喺通報後仍然有效一段時間。對防守者嚟講，真正嘅處理唔係刪檔案，而係即時停用、換 key、追 audit log、查有無異常使用，再檢查點解明文資料會入到 repo。

CISA 本身係負責美國民用聯邦系統網安建議嘅機構，所以尷尬位特別大。TechCrunch 亦提到，CISA 自 2025 年 1 月 20 日起未有正式局長，近年亦有人手削減同重組壓力；但呢個背景只可以解釋環境，唔可以用嚟淡化問題。無論係政府部門、銀行、零售商定細型 SaaS 公司，承包商存取公司系統時，公司仍然要為自己系統同資料保安負責。

點解 GitHub 會變成 secrets 黑洞

GitHub 官方文件寫得好直接：如果 API keys、密碼、tokens 呢類 hardcoded secrets 被 commit 入 repo，就會成為未授權存取目標。GitHub secret scanning 會掃描 repo 全部 branch 嘅 Git history，公開 repo 會免費自動運行；發現外洩後，官方建議係即時輪換受影響憑證。問題係，secret scanning 多數係補救訊號：一旦 secret 入咗 Git history，即使你再刪一個檔案，舊 commit、clone、fork、CI cache 仍可能有痕跡，所以最重要係令舊 secret 失效。

GitHub push protection 係另一層，作用係喺 push 之前擋低被偵測到嘅 secrets，避免佢哋先入 repo 再補鑊。不過工具唔係魔法。GitHub 文件亦講到，repo 層面嘅 push protection 可以有 bypass 流程，寫入權限嘅人喺某些設定下可以提出理由繞過；組織要再加 delegated bypass、audit log、alert 通知同權限分層，先至唔會變成人人都可以按一下放行。今次事件最值得警惕嘅地方，就係報道指涉事帳戶有關閉或繞過防護嘅痕跡，代表風險唔只係技術偵測，而係人同流程。

行業數字亦顯示，呢類錯誤唔罕見。GitGuardian 2026 年 State of Secrets Sprawl 報告稱，2025 年公開 GitHub commits 偵測到 28,649,024 個新 hardcoded secrets，按年升 34%。同一份報告亦將 long-lived secrets 列為主要問題之一。換句話講，真正危險嘅唔係某一次 copy and paste，而係公司多年累積出一堆唔知由邊個建立、無到期日、無 owner、無清楚權限範圍嘅機器身份。

真正問題係權限同生命週期

AWS IAM 官方最佳做法其實好清楚：人類用戶應盡量經 identity provider federation 取得臨時憑證，工作負載就用 IAM roles 等臨時憑證；長期 access keys 只應喺真係需要嘅場景使用，並要按情況更新、審查同移除。另一條底線係最小權限：一條 key 只應做到佢需要做嘅事，最好仲要加 condition，例如只准指定 IP、指定資源、指定時間或指定 service action。外露一條只可讀某個測試 bucket 嘅 key，同外露一條可改 IAM policy、開 EC2、讀 production S3 嘅 key，風險完全唔同。

所以事故 response 要由身份清單開始，而唔係由 repo 清潔開始。公司要答到幾條問題：邊啲 key 外露、仲有效定已撤銷、屬於人定機器、對應邊個 vendor 或員工、可以接觸邊啲環境、最近 30 至 90 日有無異常 API call。AWS CloudTrail、GitHub audit log、CI/CD job history、artifact registry、container registry、password manager 同 vault log 要一齊查。刪走公開檔案只係止血表面，真正止血係令舊憑證無效，再確認沒有被用嚟開新門。

外判同個人帳戶係最大灰色位

今次 TechCrunch 同 Krebs 都將事件追到承包商相關人員身上，但責任唔會因為係 contractor 就消失。香港好多 IT 項目由外判公司、freelancer、系統整合商或臨時顧問交付；合約通常寫清楚交付日、付款、SLA，反而未必逐項寫明 repo ownership、個人 GitHub 可唔可以用、公司資料可唔可以落本機、離職或完約時幾耐內關閉權限、CI/CD secrets 邊個負責輪換。呢啲就係實際事故最常穿窿嘅位置。

實務上，vendor 存取要由公司控制嘅組織帳戶開始，而唔係叫對方用私人 GitHub invite 入 production repo。所有外判帳戶要有 MFA、SSO 或 enterprise managed identity，權限按項目同環境分開，完約有 offboarding checklist，並且禁止用私人 repo 或個人雲端硬碟同步公司密碼表、.env、SSH key、Terraform state、Kubernetes config。NDA 只係法律文件，擋唔到一條已外露嘅 admin key；技術上要靠最小權限、短期憑證、監察同快速撤銷。

香港公司要由合規講到工程細節

截至原報道同後續資料，未見公開證據顯示香港機構直接受今次 CISA 事件影響。但本地風險唔需要等到有香港受害者先成立：AWS 本身有香港市場頁面，面向金融服務、startup、中小企、企業同安全合規方案；GitHub 同雲端 CI/CD 亦係跨地域開發工具。一旦外露 key 可以接觸客戶資料、員工資料、交易紀錄、support ticket 或 log，事件就會同私隱法同客戶信任直接掛鈎。

私隱公署在《個人資料私隱條例》概覽中列明，DPP4 要求資料使用者採取所有切實可行步驟，保障持有嘅個人資料免受未授權或意外查閱、處理、刪除、遺失或使用；如果委託資料處理者處理個人資料，亦要以合約或其他方法確保對方符合資料保安要求。套返 GitHub secrets 場景，即係公司唔可以一句「係 vendor 手滑」就算；如果 vendor key 可入到公司個人資料系統，公司需要證明自己有合理管治、限制權限同事故處理。

香港公司可以用以下清單做第一輪自查：

• Repo 可見度：列出所有公司、vendor、員工個人帳戶相關 repo，確認邊啲係 public，邊啲曾經由 private 轉 public。
• Secret scanning：開啟 GitHub secret scanning、push protection、custom patterns，並定期睇 bypass 同 alert audit log。
• 憑證輪換：所有 AWS、GitHub Actions、database、payment、SMS、email API keys 要有 owner、到期策略同輪換紀錄。
• 最小權限：CI/CD 用 OIDC 或短期 token，避免長期 admin key；測試、staging、production 權限要分開。
• 外判存取：合約寫明 repo、裝置、同步工具、完約關戶、事故通報時限，同禁止明文密碼表。
• 事故演練：試做一次 key 外露 tabletop exercise，由發現 alert 到撤銷、查 log、通知客戶同補救，計清楚需時幾耐。

呢件事最值得記住嘅唔係 CISA 失手有幾諷刺，而係連專職網安機構都會中最基本嘅 secrets hygiene 問題。工具可以掃描、可以提示、可以擋 push，但工具唔會自動定義邊個有權建立長期 key、邊個可以 bypass、vendor 完約後邊個負責輪換。對香港公司嚟講，最實際嘅起點係今日就搵出所有 secrets 住喺邊、邊啲仲有效、邊個負責、邊個可以撤銷；答唔到呢四條問題，下一次公開 repo 就可能唔只係尷尬，而係真正事故。

參考來源

• TechCrunch — US cyber agency CISA exposed reams of passwords and cloud keys to the open web — original report
• KrebsOnSecurity：CISA Admin Leaked AWS GovCloud Keys on Github — 最早深入披露事件嘅調查報道，補充研究員發現、key 有效性同承包商脈絡。
• GitHub Docs：About secret scanning — 官方說明 secret scanning 點樣掃描 Git history、公開 repo 自動啟用同收到 alert 後要輪換憑證。
• GitHub Docs：About push protection — 官方說明 push protection 如何在 push 前阻擋 secrets、bypass 同 audit alert 機制。
• AWS IAM：Security best practices in IAM — 官方 IAM 最佳做法，包括臨時憑證、最小權限、長期 access key 管理同移除未用憑證。
• GitGuardian：The State of Secrets Sprawl 2026 — 提供行業背景數據，例如 2025 年公開 GitHub commits 偵測到約 2,865 萬個新 hardcoded secrets。
• 私隱公署：《個人資料私隱條例》概覽 — 香港本地資料保安脈絡，DPP4 要求資料使用者採取切實可行步驟，亦要管治資料處理者。
• AWS Hong Kong：Cloud Computing Services & Events — 用作香港雲端服務背景，顯示 AWS 面向本地金融、startup、企業同安全合規使用場景。

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