軟體供應鏈攻擊過去主要是騙人：騙開發者裝錯套件、騙 maintainer 交出帳號、騙使用者跑惡意 script。
２０２６ 年開始，攻擊者多了一個新目標：騙 AI coding agent。
CSO Online ５月５日整理 ReversingLabs 的追蹤報告，指出一個名為 PromptMink 的攻擊活動正在利用「LLM Optimization abuse」與「knowledge injection」包裝惡意套件，讓 AI coding agent 更容易發現、推薦、安裝它。
這和傳統套件攻擊差別很大。以前惡意套件的 README 是寫給人看的，現在 README 也可能是寫給模型看的。
PromptMink 是什麼？
根據 CSO 與 ReversingLabs 的整理，PromptMink 被歸因於 North Korea APT Famous Chollima。它的目標集中在加密貨幣與 fintech 開發者，手法是發布看似有用的套件，再把真正惡意 payload 放在第二層依賴裡。
| 項目 | 內容 |
|---|---|
| 活動名稱 | PromptMink |
| 追蹤單位 | ReversingLabs |
| 報導日期 | ２０２６ 年 ５ 月 ５ 日 |
| 歸因 | Famous Chollima，北韓相關 APT |
| 主要目標 | crypto、fintech、Solana／Ethereum 開發者與 coding agent |
| 代表誘餌套件 | @solana-launchpad/sdk、@validate-ethereum-address/core |
| 惡意依賴 | @hash-validator/v2、@validate-sdk/v2 等 |
| 主要風險 | infostealer、SSH key 植入、專案原始碼壓縮外傳、遠端存取 |
這裡的關鍵不是「又有一個惡意 npm 套件」。真正值得注意的是，研究者發現這些套件的文件寫得特別像在討好 LLM：
- 描述很完整，功能看起來剛好對應常見開發任務。
- README 充滿可信語氣、整合範例與關鍵字。
- 套件本身可能有部分合法功能，讓 agent 或人類更難一眼判斷是假的。
- 惡意 payload 藏在第二層依賴，讓第一層誘餌更像正常工具。
這就是 LLMO abuse：不是用 SEO 騙搜尋引擎，而是用文件與語意包裝騙模型選套件。
攻擊者為什麼要騙 agent？
因為 coding agent 的工作方式，剛好創造了新入口。
一個人類開發者要裝新套件，通常至少會看幾個訊號：下載數、GitHub stars、維護者、issue、版本歷史、同事是否用過、套件名是否眼熟。
但 coding agent 在自動寫程式時，常會根據語意去推理：
「我需要一個 Solana launchpad SDK。」
「這個套件名稱看起來符合。」
「README 說支援快速整合。」
「範例剛好能完成任務。」
「那就加入依賴。」
如果企業流程允許 agent 自動修改 package.json、執行 install、跑測試甚至開 PR，那攻擊者就不一定需要說服人類。只要讓模型在候選套件中選中它，就可能進入 codebase。
這是供應鏈攻擊的新型態：
惡意文件不是給人類看的廣告，而是給模型看的 prompt。
Slopsquatting：模型幻覺也會變成攻擊入口
另一個更麻煩的方向是 slopsquatting。
傳統 typo-squatting 是註冊拼錯的熱門套件名，例如把 requests 拼成類似名字。Slopsquatting 則是利用模型幻覺：模型可能憑空捏出一個不存在、但聽起來合理的套件名；攻擊者搶先註冊這個名字，等 agent 或開發者照著安裝。
CSO 報導提到，Aikido Security 的研究者 Charlie Eriksen 曾註冊一個被 LLM 幻覺出的 npm 套件 react-codeshift，結果看到實際下載請求，並發現相關 skill 或程式碼擴散到多個 repository。
這個案例最可怕的地方是：套件不是攻擊者先創造需求，而是模型先創造了不存在的依賴，攻擊者再補上陷阱。
對 coding agent 來說，這是天然弱點。模型擅長補齊合理答案，但 package registry 是現實世界，不是語意世界。聽起來合理的套件名，不代表它真的可信。
和 Laravel-Lang 事件差在哪？
Laravel-Lang 供應鏈攻擊 是「既有信任被改寫」：開發者原本信任的套件與版本標籤，被攻擊者重寫到惡意 commit。
PromptMink／slopsquatting 則是「選擇入口被污染」：agent 在幫你挑新依賴時，被文件、語意、套件命名與模型幻覺引導到錯誤選項。
兩者差別如下：
| 類型 | 攻擊點 | 風險 |
|---|---|---|
| Laravel-Lang 類型 | 已存在的套件、tag、release 信任 | 你以為自己裝的是舊版，實際內容被換掉 |
| PromptMink 類型 | agent 選擇新套件的語意過程 | agent 以為自己找到合適依賴，實際裝進惡意套件 |
| Slopsquatting 類型 | 模型幻覺出的套件名 | 不存在的依賴被攻擊者搶先註冊 |
這三種攻擊合在一起，說明一件事：
AI coding agent 讓軟體供應鏈多了一層「模型選擇風險」。
以前要保護 supply chain，重點是 package registry、maintainer 帳號、CI pipeline、lockfile。現在還要多看一層：agent 是怎麼決定要用哪個套件的？
為什麼這會變成大問題？
因為企業正在把 coding agent 放進正式開發流程。
以前的 vibe coding 可能只是個人 side project，裝錯套件頂多砍掉重來。但現在 agent 會被接進：
- 企業 repo
- CI/CD
- dependency update bot
- security fix workflow
- code review assistant
- internal scaffold generator
- MCP toolchain
- 私有套件 registry
一旦 agent 有權限改依賴、跑 install、開 PR、讀 repo、讀 .env、讀 CI secret，供應鏈攻擊的爆炸半徑就會變大。
攻擊者也會因此調整策略。未來惡意套件不一定會寫得粗糙，它可能會：
- 提供真的可用的基本功能。
- README 寫得極度完整。
- 用大量範例覆蓋常見 agent query。
- 在文件裡塞進「適合 Claude Code／Cursor／Codex 使用」這類語意提示。
- 把 payload 藏到第二層或第三層依賴。
- 讓惡意行為只在 CI、特定 OS、特定環境變數存在時觸發。
這不是科幻。這是傳統供應鏈攻擊遇到 agentic coding 後的自然演化。
企業該怎麼防？
最重要的一句話是：
不要讓 coding agent 自動安裝未審查依賴。
具體做法可以拆成七層。
１．Trusted registry 與 allowlist
Agent 只能從公司核准的 registry 或 mirror 安裝套件。新套件進入前要經過審查，不讓 agent 直接打公共 npm、PyPI、crates.io。
２．依賴新增必須人類確認
Agent 可以建議套件，但不能自行合併 dependency change。PR 介面要明確標示新增套件、transitive dependencies、install scripts、maintainer、最近發布紀錄。
３．鎖定工具與版本
不要讓 agent 自由選 package manager、自由改 install command、自由使用 npx 下載即執行。尤其 npx、curl pipe shell、postinstall script 都要高度限制。
４．SBOM 變成基本配備
Software Bill of Materials 不能只為法規準備。每次 agent 改依賴，都要更新 SBOM，讓團隊知道 codebase 新增了哪些直接與間接元件。
５．掃 README，也掃行為
傳統套件審查常看 metadata。現在還要看 README 是否過度 LLM-oriented、是否用奇怪關鍵字堆疊、是否把 agent 當主要使用者，並搭配 sandbox 執行觀察出網、檔案讀取、環境變數存取。
６．CI secrets 最小化
就算惡意套件進來，也不要讓它讀到 production 等級祕密。Build job、test job、release job、deploy job 的 token 要分開，權限越短越好。
７．把 agent 決策寫進 audit log
未來追查事件時，不只要看「誰 commit 了 dependency change」，還要看：
- 哪個 agent 建議了套件？
- 當時 prompt 是什麼？
- agent 看了哪些文件？
- 它為什麼判斷這個套件合適？
- 有沒有其他候選被排除？
這些紀錄會成為新型 supply-chain forensics。
這篇真正的重點
AI coding agent 的危險不在於它會不會寫錯程式。寫錯程式還能測，還能 review。
更大的風險是：它可能很有自信地把錯誤信任帶進你的供應鏈。
Laravel-Lang 類事件提醒我們，既有套件也可能被污染。PromptMink 類事件提醒我們，新套件選擇本身也可能被操縱。Slopsquatting 則提醒我們，模型幻覺不只會產生錯誤文字，還可能產生真實下載行為。
所以未來成熟的 coding agent 工作流，不會是「讓 agent 自動解決一切」。比較可靠的路線是：
讓 agent 寫程式，但讓系統審查它信任了誰。