Dependabot malware alert 怎麼處理？先確認能否修補，再收斂供應鏈風險
Dependabot 出現 malware alert 時，第一個問題不是「為什麼沒有自動升級 PR？」而是「這個套件是否有安全的替代版本，且它是否已進入我的安裝或執行路徑？」
GitHub 在 2026 年 7 月擴大 Dependabot 的惡意套件資料來源：GitHub Advisory Database 會匯入 OpenSSF malicious-packages advisories，涵蓋 npm、PyPI 等更多 ecosystem。已啟用 malware alert 的 repository 會自動得到新的比對範圍。
先開啟並找到正確 alert
到 repository 或 organization 的 Settings → Code security → Dependabot 開啟 Malware alerts。Advisory 清單可使用 type:malware 篩選；但不要把「有 alert」和「有修補版本」混為一談。
GitHub 文件說明，許多惡意套件的下游使用者沒有可直接升級的修補版本，因此 Dependabot 不一定會產生更新 PR。這正是它與一般 CVE security update 不同的地方。
收到 alert 後的處理順序
| 順序 | 要確認的事 | 目的 |
|---|---|---|
| 1 | direct 還是 transitive dependency、實際版本與 lockfile | 判定影響面 |
| 2 | 套件是否在 install、build 或 production runtime 被執行 | 判定緊急性 |
| 3 | advisory 是否列出安全版本、撤版或替代套件 | 選擇修補路徑 |
| 4 | CI、registry 和發布 token 是否可能被讀取 | 收斂 credential 風險 |
| 5 | 移除／替換後重建 lockfile、測試與監控 | 留下可重現證據 |
先在 repository 釐清關係，而不是直接刪除 lockfile：
pnpm why 套件名稱rg -n '套件名稱' package.json pnpm-lock.yaml如果是 transitive dependency，通常要找上游套件的安全版本、移除不再需要的 direct dependency，或採用 maintainer 指示的替代方案。若根本沒有安全版，暫時 pin 住版本不等於已經修好；仍需評估移除、隔離或替換。
將 malware alert 和一般更新分流
上一篇 Dependabot 三天冷卻期 處理的是一般 version update 的等待期；malware alert 則是已辨識到的供應鏈風險。兩者不應共用「等 bot 開 PR 再看」的流程。
在處理期間，檢查是否有曾經使用該套件的 CI token、registry publish token 或 deployment secret。若套件 lifecycle script 或 build 已在高權限環境執行，依組織事件流程評估 token 輪替與 audit log；不要因為 alert 關閉就假設沒有留下後續風險。
最後留下判斷紀錄
一筆好 triage 至少記錄 advisory URL、命中的版本與依賴路徑、是否執行、採用的移除／替換方式、測試結果及是否輪替憑證。這能讓之後遇到同類 package typosquatting 或維護者帳號遭入侵時，不必從零決定。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。