Snyk内部审计首次披露：你的AI技能可能在一次静默更新后，悄悄偷走AWS密钥

這篇文章來自 Nesbit.io，一個深耕軟件供應鏈安全的技術博客。作者以傳統包管理器生態十幾年的安全研究為基礎，對當下 AI 技能（Skills）的分發架構進行了系統性解剖，結論相當刺耳：信任一個 AI 技能，在安全語義上幾乎等同於在生產伺服器上直接執行 `curl | bash`。

問題的根源在於 AI 技能本質上是一個「超級包管理器客戶端」。一份技能清單文件可以同時聲明對 Node（NPM）、Python（UV/pip）乃至系統層（Homebrew）的依賴，安裝一個技能實際上是在向多個包管理器同時下達安裝指令。這種疊加效應把過去十年包管理器生態裡積累的所有安全威脅——惡意安裝腳本、依賴混淆、名稱劫持——全部拉進了技能的加載路徑。更關鍵的是，傳統生態中針對各自包管理器的防護機制（如 Node 的 `--ignore-scripts`）無法在跨管理器的加載器中統一配置，配置滯後直接形成代碼執行的敞口。

AI 技能架構的第二個致命問題是將代碼執行與提示詞注入在設計層面強行綁定。傳統代碼包的有效載荷只有代碼；AI 技能的有效載荷是代碼加上自然語言描述。大多數加載器會預設把每個已安裝技能的描述文本注入到對話的系統提示詞中，這意味著惡意指令可以在使用者從未主動觸發該技能的情況下完成注入。這個設計把安全防禦的錨點從「精確的位元組哈希驗證」強行拖移到「模糊的語義分析」，而業界現有的靜態掃描器和 SBOM 工具完全無法追蹤自然語言有效載荷——一段誘導性描述文字的修改會改變文件哈希，但不會改變其語義上的風險。作者將當前的注冊表安全審查直接定性為「合規劇場」。

版本信任和安裝源設計的缺陷使問題進一步惡化。現有技能生態的鎖定文件通常只記錄技能名稱而非位元組哈希，今天鎖定的 1.0.0 版本明天可能解析到由全新擁有者控制的完全不同代碼。靜默升級同樣危險：一個技能在小版本更新中悄悄在 `require *` 環境變量字段加入對 AWS 訪問密鑰的讀取權限，由於授權綁定在名稱而非精確版本上，此變更無需任何用戶確認即直接生效。與此同時，加載器默認把任意 Git 連結作為一等公民接受，等同於加載器放棄了注冊表的審核職責，卻保留了注冊表的分發權力，把整個生態的信任底座壓縮到代碼托管平台的帳號安全層級。研究數據顯示，當面對對抗性偽裝的技能描述時，大模型被欺騙並選擇惡意變體的平均概率高達 77.6%，最大規模模型甚至超過 80%——描述中加入「官方驗證」或誇大能力的詞語，大模型就會像受到社會工程學攻擊的人類一樣毫不猶豫地將其拉入執行上下文。這一切讓人想起 NPM 的 Event Stream 事件：一個庫被惡意接管，波及數百萬設備。歷史的慘劇正在以自然語言作為新載體重演，而行業的安全基線卻尚未對此做出任何結構性回應。

---