TrapDoor：竊取憑證的供應鏈攻擊鎖定 AI 助手指令檔

TrapDoor 的套件攻擊，靠的是 34 個以上的仿冒工具套件被加進專案。pull request 新增套件前，必須針對確切套件與 lockfile 差異，檢查漏洞、授權條款、維護者與來源儲存庫信譽、版本來源、安裝腳本差異，以及套件名稱是否有錯字或相似字元；任何分析缺漏，都要擋下合併。這項控制在安裝前審查原始碼變更；實際套件檔案的惡意程式掃描，以及限制 postinstall 或匯入時程式碼的影響，仍由其他控制負責。

對 agent 命令、套件安裝與建置執行，採用沙箱對外連線預設拒絕，並獨立測試每條執行路徑。來源指出 GitHub Pages 用於提供惡意程式與設定，GitHub Gist 則是 Rust 路徑的竊資目的地；不能把靜態 Pages 網站直接寫成接收憑證的位置。只允許套件儲存庫或共用代管網域仍不夠，還須確認必要路徑，避免上傳與中繼濫用。

把不可信套件的安裝，以及必要的匯入與建置執行，放在一次性沙箱中；不要掛載開發者家目錄、SSH 金鑰或正式環境秘密。能停用時，先停用 npm 安裝生命週期腳本。Python 匯入程式碼與 Rust build.rs 需要另外隔離執行或拒用套件，沒有一個通用旗標能同時停用三條路徑。

不論提示詞將動作稱為什麼，讀取 SSH 金鑰或錢包、執行 shell 與對外傳送，都是高風險動作。權限與風險紀錄應將這些動作排除在一般任務範圍外；實際拒絕則由執行時的核准、工具授權與對外連線管制負責。

以端點內容檢查與確切暫存檔案的審查提供早期訊號，並由中央 CI 決定是否允許合併。已公開的 hook 涵蓋 CLAUDE.md、agent_config.md 與兩種危險措辭，不涵蓋 .cursorrules，也不會解碼隱藏 Unicode、驗證遠端指引或證明指令安全。必須針對本案擴充並獨立驗證檔案與政策涵蓋範圍，在助手讀取前拒絕未經審查的變更。

在營運者可控制的入口，依 G001 使用鎖定版本、經校準的次要分類器，檢查程式助手實際讀入的指令檔文字中的任務轉向、權限宣稱或提權意圖，並產生與確切內容綁定的發現。G001 不會解碼零寬字元中的隱藏指令，也不會比對原始與呈現後的文字。目前 G002 解碼器無法初始化，此處不計入其效果。分類結果提供證據，是否拒絕輸入由獨立放行政策決定；看似合理或被隱藏的指令仍可能漏判。放行前須另行驗證完整分類結果與必要類別的涵蓋範圍。目前 G001 範例會把空結果、缺少必要類別或NaN 分數回報為 PASS／NO_FINDING；整合端必須把這些情況視為錯誤並拒絕放行。這是額外需要實作的檢查，不是已公開範例原本就具備的行為。

在指令檔的確切讀入位置、組裝推論請求前，套用已公開的欄位驗證與 Unicode 政策；依具簽章的放行政策，拒絕不允許的字元或偵測發現。正規化與模式檢查仍可能漏掉語意上的任務轉向，也不會把儲存庫指令變成可信權限；仍需要工具授權與對外連線管制。

一旦掌握 TrapDoor 的指標，防禦方需要把清查範圍從套件相依關係展開到相關資產：哪些專案或 lockfile 引用惡意套件，哪些 repo 新增了 .cursorrules 或 CLAUDE.md，哪些 CI cache、容器或開發者機器可能接觸過這些內容。相依關係與資產盤點本身是輔助控制，作用是把一份 IOC（入侵指標）清單，轉成可追蹤、可分派的清查工作，而不是單獨完成偵測或阻擋。

移除事件中已確認惡意的指令檔、套件程式、Git／shell hook、systemd／cron 項目，以及攻擊者新增的 SSH 存取設定，再驗證受影響資產都已清除。憑證撤銷、已簽發token與工作階段的撤除，是另外的應變工作；移除套件不代表這些工作已完成。