Wait until AI agents get compromised...

供應鏈攻擊已從邊緣安全問題演變為所有開發者的核心威脅。講者錄製本影片時，一場嚴重的供應鏈攻擊正在蔓延至眾多NPM與Python套件，未來發展尚不明確。供應鏈攻擊的本質看似簡單卻致命：攻擊者入侵你所依賴的軟體套件，注入惡意代碼竊取.env檔案中的認證、AWS憑證等敏感資訊，並進一步傳播至其他套件，形成蠕蟲式擴散。

過去這類攻擊在技術上一直可行，但其頻率遠低於今日。AI的出現徹底改變了攻擊的成本與規模。攻擊者可用AI大規模分析開源倉庫，研究它們的構建方式、分佈機制與CI/CD工作流程配置。TanStack攻擊案例完美展現了這一點：儘管維護者採用了理論上安全的NPM信任發布流程，攻擊者卻透過分析GitHub Actions的不安全事件觸發配置，利用快取汙染技術將惡意代碼從不信任環境注入信任環境。AI同時簡化了編寫惡意代碼的過程——攻擊者無需遵循編程最佳實踐，只需要代碼能執行任務且難以檢測即可。

更深層的危機來自代碼生成民主化帶來的目標數量爆炸。AI讓非開發者也能編寫軟體，許多人對軟體安全毫無了解。即使是簡單的一次性任務（如合併PDF檔案），使用者也可能透過AI代理引入受污染的依賴，卻完全不知情。GitHub的可靠性問題正反映了這一趨勢：因為AI使代碼生成變得異常容易，推送到GitHub的代碼比以往任何時候都多。這創造了史無前例的攻擊面。

最令人擔憂的是，AI代理本身正成為攻擊者的終極目標。攻擊者不僅可以入侵套件竊取認證，更可以注入惡意代碼來修改Cloud Code、Codex或其他AI代理的系統提示與行為邏輯。想象一個場景：被入侵的AI代理被秘密指示執行隱秘操作——掃描系統秘密、編寫數據竊取程序、向遠程伺服器發送信息——全在使用者不知情的情況下發生。這不是AI模型本身出問題，而是其代碼與系統提示被惡意篡改，是一匹高等級的特洛伊木馬。雖然這場景看似科幻，但講者確信這類攻擊是必然會發生的事件。

應對之策需要多層面的防禦與心態轉變。開發者應在隔離環境（虛擬機、開發容器）中工作，確保憑證不以明文形式存儲，改用Doppler或Inphysical等密鑰管理服務。只安裝至少三天以上的套件版本以減低風險。對AI生成的代碼進行審查，不要盲目信任自動化工具。最關鍵的是認識到一個根本的轉變：在當今環境中，安全漏洞與攻擊是必然會發生的事，我們需要限制災害半徑，而非期待完全防禦。