Miasma Worm 影響 73 個 repo 後：AI coding 設定檔也是供應鏈邊界
Miasma 供應鏈事件影響 73 個 Microsoft GitHub repositories，也把 AI coding agent 的設定檔推到安全討論中心。當 repo 會被 Claude Code、Cursor 或 Gemini CLI 讀取時，設定與規則檔不只是專案偏好，而是可改變開發環境行為的輸入。
目錄+
Miasma Worm 最值得工程團隊記住的，不是「又一個 npm 事件」，而是它讓 AI coding agent 的設定檔成為供應鏈的一部分。
多份六月的資安報告指出，Miasma 相關攻擊波及 73 個 Microsoft GitHub repositories。研究者同時觀察到針對 AI 開發工具設定的 payload：例如 Claude Code、Cursor 或 Gemini CLI 會讀取的專案層級檔案。當開發者 clone 一個 repository、再用 agent 開啟它時，這些檔案可能不只是被人閱讀，而是會被工具載入並影響行為。
這不代表每一份 .claude、.cursor 或其他設定檔都有惡意；它代表它們不再適合被當成無害的編輯器偏好。它們與 CI workflow、package script 一樣，都是需要來源與變更審查的 execution surface。
為什麼這次事件和 AI coding 特別有關
傳統供應鏈攻擊常把目標放在套件、lockfile、安裝腳本或 CI。AI coding 工具增加了一條新路徑：攻擊者可以嘗試把指令、hook、規則或設定放進 repository，等待開發者以具權限的 agent 開啟。
agent 的特殊之處在於它不只讀檔，還可能讀取更多 context、執行終端機、存取 GitHub、修改程式碼或使用雲端憑證。於是原本一段「看起來只是開發指引」的文字，可能變成影響工具選擇與行動順序的輸入。
Miasma 事件的完整技術鏈仍須依各報告與受影響組織的鑑識結果判斷；但它已足以改變防守優先順序：安全審查必須涵蓋 agent configuration，而不只涵蓋 application code。
把 repo 分成三類風險檔案
團隊不需要禁止所有 AI coding 工具，但應先把 repository 裡的檔案分級。
一般內容檔包含文件、測試資料與業務程式碼；它們也可能帶有 prompt injection，但通常不會直接改變工具啟動行為。自動化檔包括 GitHub Actions、package scripts、Docker 與部署設定，早就應經過嚴格 review。第三類是agent configuration：工具規則、hook、MCP 設定、workspace instruction 與 IDE project settings。它們應被視為自動化檔，而不是一般文字檔。
這個分級的作用很實際：只要 PR 修改第三類檔案，就要觸發額外 review、來源確認與 secret／network capability 檢查。對外部貢獻或新 clone 的 repo，則先在隔離環境開啟，避免讓本機 agent 直接繼承敏感權限。
今天就能建立的四道防線
- 把 agent 設定納入 CODEOWNERS。
.claude、.cursor、.gemini、MCP 設定與 hook 相關路徑，應要求至少一位安全或 platform owner 審核。 - 在 CI 對設定 diff 做規則檢查。 偵測新增的 shell hook、外部下載、環境變數讀取、憑證路徑與不明網路連線；這些訊號不一定是惡意，但值得阻擋自動合併。
- 分離 agent 的身分與權限。 本機或 CI 的 agent 不該沿用人類開發者的長效 cloud credential。使用最小範圍、短期 token，並隔離可寫入的目錄與網路。
- 把 clone 視為尚未信任。 首次開啟陌生 repo 時，不自動啟用 workspace hooks、MCP server 或 agent rules；先看 manifest，再選擇允許哪些能力。
這些措施不能保證消除供應鏈風險，但能把「開一個 repo 就執行一串未審查指令」變成需要明確跨越的關卡。
供應鏈安全的單位正在變小
過去我們習慣掃 package name、hash 與 CVE。agent 時代還要問：這個 repository 要把什麼內容餵給模型？模型可以把它轉成哪些工具行動？有沒有一個人在 action 發生前看得到？
這不是把所有設定檔都妖魔化，而是承認工具行為已經從程式碼擴張到規格、描述與工作區內容。能把這些輸入納入 review 的團隊，才有機會在 agent 變得更自主之前，保留足夠清楚的控制面。