幽靈包暗藏漏洞 57.6萬代碼撕碎AI編程神話

AI編程夢被撕碎！最新研究用57.6萬個代碼樣本揭示：超20%代碼依賴的是不存在的軟體包。

蘋果、微軟都曾中招，而Meta和微軟還在高喊「未來AI寫95%代碼」。

AI寫代碼的神話，正在變成安全災難。最近，扎克伯格表示，Meta正在內部開發專門用於編程和AI研究的智能體——這些並不是通用型工具，而是為提升 Meta自家AI項目（如 LLaMA）量身定製的專用智能體。



他預測，在未來的12到18個月內，Meta用於AI開發的大部分代碼將不再由人類編寫，而是由AI智能體生成。

微軟首席技術官Kevin Scott的預測更長遠，但更大膽。

在最近的一檔播客節目中，他預估在未來五年，AI生成的代碼將占據主導地位，表示道：

95%的代碼將由AI生成，人類完全手動編寫的代碼幾乎一行也沒有。


左：微軟首席技術官Kevin Scott；右：播客主持人Harry Stebbings

Scott擁有41年的編程經驗，足以讓他見證行業內的多次變革。

20世紀80年代，組合語言編程開始向高級語言編程轉變，

當時，有些老程式設計師會說：「如果你不會寫組合語言，就不算真正的程式設計師，那是唯一正確的編程方式。」

如今，已經沒人再提這些了。

在他看來，AI的崛起與當年的變革並無太大不同。

Scott認為，「最優秀的程式設計師」會迅速適應AI工具：

一開始，開發者對這些工具持懷疑態度，但現在他們的態度變成了「除非我死了，否則別想讓我放棄這些工具」。

AI已經成為他們工具箱中不可或缺的一部分。

但軟體工程中，「沒有銀彈」：如果開發的次要部分少於整個工作的 9/10，那麼即使不占用任何時間，也不會給生產率帶來數量級的提高。

正如Scott所言：「代碼的創造性和核心設計，仍然完全依賴於人類。」


論文連結：

https://www.cs.unc.edu/techreports/86-020.pdf

擁有超過25年經驗的記者DanGoodin，則報導了AI生成代碼，不僅不能取代人類開發者，甚至可能對軟體供應鏈造成災難性影響。



AI帶來的災難性影響在2025年美國計算機安全協會安全研討會（USENIX Security 2025）上，研究人員計劃發表一篇論文，報告發現的 「軟體包幻覺」現象。

USENIX Security 2025在今年8月13日到8月15日舉行

這項研究顯示，AI生成的計算機代碼中充斥著對並不存在的第三方庫的引用，這為供應鏈攻擊創造了絕佳機會。

攻擊者可以利用惡意軟體包毒害合法程序，進而竊取數據、植入後門，以及實施其他惡意行為。

論文連結：

https://arxiv.org/abs/2406.10279v3

該研究使用16種主流大型語言模型（LLM）生成了57.6萬個代碼樣本。

結果發現，這些樣本中包含的軟體包依賴項里，有44萬個是 「幻覺產物」，也就是說它們根本不存在。

開源模型的虛構依賴比例最高，生成的代碼所包含的依賴項中21%並不存在。

新型軟體攻擊：軟體包混淆這些並不存在的依賴項加劇了所謂的「依賴項混淆攻擊」，對軟體供應鏈構成了威脅。

這類攻擊的原理是讓軟體包訪問錯誤的組件依賴項。

例如，攻擊者發布一個惡意軟體包，給它起一個與合法軟體包相同的名字，但標註一個更新的版本號。在某些情況下，依賴該軟體包的軟體會選擇惡意版本，而不是合法版本，因為惡意版本看起來更新。

這種攻擊方式，也稱為「軟體包混淆」，在2021年的一次概念驗證中首次展示，成功在蘋果、微軟等巨頭公司的網絡中執行了偽造代碼。

這屬於軟體供應鏈攻擊，目的是污染軟體源頭，感染所有下游用戶。

軟體供應鏈攻擊（software supply chain attack）一般步驟

該研究的主要負責人、德克薩斯大學聖安東尼奧分校的博士生Joseph Spracklen，在給媒體的電子郵件中表示：「一旦攻擊者利用虛構軟體包名稱發布包含惡意代碼的軟體包，並依靠模型向毫無戒心的用戶推薦該名稱，如果用戶沒有仔細驗證就安裝了該軟體包，隱藏在其中的惡意代碼就會在用戶系統上執行。」



軟體包幻覺多嚴重？為了評估軟體包幻覺問題的嚴重性，研究人員測試了16種代碼生成AI模型（包括GPT-4、Claude、CodeLlama、DeepSeek Coder、Mistral等），使用兩個獨特的提示數據集，生成了576,000個Python和JavaScript代碼樣本。

結果顯示，推薦的軟體包中有近20%是不存在的。

研究發現，不同LLM和程式語言的虛構軟體包比例差異顯著。

開源模型的平均虛構比例接近22%，而商業模型僅略超5%。Python代碼的虛構比例平均為16%，低於JavaScript的21%。

這種差異可能與模型複雜性和訓練數據有關。

商業模型（如ChatGPT系列）通常擁有比開源模型多10倍以上的參數，參數量更大可能減少幻覺。此外，訓練數據、微調和安全優化也可能影響虛構比例。

至於JavaScript虛構比例高於Python，研究推測這與JavaScript生態系統中軟體包數量（約為Python的10倍）和命名空間複雜性有關。

更大的軟體包生態和複雜命名增加了模型準確回憶包名的難度，導致虛構比例上升。

不同語言模型在Python和JavaScript代碼中的幻覺率

為了驗證LLM是否會反覆幻覺相同的軟體包，研究人員隨機抽取了500個引發幻覺的提示，並對每個提示重複查詢10次。

結果發現：

43%的幻覺軟體包在10次查詢中均被重複提及；39%的幻覺軟體包在10次查詢中完全未重複；58%的幻覺軟體包在10次疊代中被重複提及超過一次。研究人員指出：「這表明，大多數幻覺不是隨機錯誤，而是可重複、持續的現象。這種持久性對惡意攻擊者更有價值，讓幻覺攻擊成為更現實的威脅。」

儘管許多模型在某些情況下能檢測到自己的幻覺，但問題在於，許多開發者依賴AI生成代碼，並盲目信任AI的輸出。

「幻覺」難以根除在AI領域，當大語言模型產生的輸出結果在事實上不正確、毫無意義，或者與分配給它的任務完全無關時，就會出現 「幻覺」 現象。

長期以來，「幻覺」 一直困擾著大語言模型，因為它降低了模型的實用性和可信度；而且事實證明，LLM「幻覺」 很難預測和解決。

幻覺軟體包是否可能源於模型預訓練數據中已刪除的軟體包？

研究人員調查結果發現：已刪除軟體包對幻覺的貢獻「微乎其微」。

他們還發現了「跨語言幻覺」：某個程式語言中的幻覺軟體包名稱與另一種語言中存在的軟體包名稱相同。

而跨語言幻覺在JavaScript中更常見。

此外，大多數幻覺軟體包的名稱與現有軟體包名稱「實質性不同」，但這些名稱往往令人信服，且與上下文高度相關。

對於使用LLM的開發者，研究人員的建議是：在使用AI推薦的代碼之前，仔細檢查推薦的軟體包是否存在，以避免落入供應鏈攻擊的陷阱。

開發者提高警惕和驗證，可以有效降低因軟體包幻覺引發的安全風險，確保代碼安全可靠。