真實測評：開源的AI系統之下可能跑著一個帶有20年前漏洞的組件

去年，奇安信代碼安全實驗室做了一件挺扎心的事：他們把國內企業最常用的10款開源大模型推理框架全部拆開，逐個檢查。結果出來后，參與的工程師半天沒說話——10款框架，無一例外，全都帶著已知高危漏洞，沒有一款是干凈的。

其中一個細節特別讓人脊背發涼：在OpenLLM這個框架里，他們挖出了一個叫CVE-2025-27520的超危漏洞。攻擊者只要利用它，就能直接拿下托管這個AI框架的服務器最高權限——root shell，通俗說就是你的服務器徹底被他接管了。這不是紙上談兵，奇安信團隊實打實復現了整個攻擊過程，報告里截圖清清楚楚。那些正用這套框架跑業務的企業，可能到現在還蒙在鼓里，以為服務器大門鎖得嚴嚴實實。

前面六篇我們聊的AI投毒、后門、感知欺騙、會話劫持，這些攻擊雖然狠，但都有個共同點：得一個一個目標去打，一次只能毒一個系統。供應鏈攻擊的思路完全反過來。它不盯著單個AI下手，而是把“毒”直接下到所有AI都要依賴的底層框架、庫、組件里。一旦得手，所有用這個工具的AI系統瞬間全中招。這就是“毒水源”跟“毒水杯”的區別——覆蓋面不是1+1，而是乘法級爆炸。這也正是為什么供應鏈攻擊在AI安全領域，被公認為范圍最廣、藏得最深、影響最持久的一類威脅。

奇安信2025年的報告把數據擺得明明白白：國內企業平均每個軟件項目要用168個開源組件，這些組件里平均藏著66個已知漏洞。報告還特別提到，多個項目里居然還躺著20年前就登記過的開源漏洞——那些2005年前后就該修好的老古董，現在還安安靜靜地待在代碼里，沒人動過。這不是哪家公司特別馬虎，而是整個行業都在還“技術債”：開發節奏太快，組件更新太頻繁，誰有工夫把祖傳依賴庫一個個清查干凈？

2020年的SolarWinds事件就是活生生的教科書。那次黑客潛入美國一家IT管理軟件公司，在官方更新包里悄悄塞進惡意代碼。結果18000多家企業和政府機構——包括美國財政部、國務院、國防部、國家安全局——都把這個“正版更新”裝了進去，被滲透長達9個月都沒人察覺。SolarWinds可怕的地方不在于技術多黑科技，而在于它徹底打破了信任：你以為最可靠的“官方渠道”，本身就能成為攻擊武器。放到今天AI時代，這個邏輯一模一樣。你從GitHub、PyPI這些官方渠道拉下來的推理框架，通過pip、conda正常安裝的依賴，可能從一開始就帶著問題。而且AI供應鏈比SolarWinds那時候更分散、更碎片，管控起來也更難。

開源生態這些年飛速發展，確實給企業省了無數時間和錢。但代價也藏在沒人愛提的地方。根據報告，2024年全球主流開源軟件包生態里的項目總量首次突破1000萬，其中74.5%的項目已經“不活躍”——維護者早就不更新了，可這些組件還在被無數下游項目引用，埋在依賴樹的角落里，帶著多年前的漏洞靜靜等待被利用。一個被遺棄的庫沒人管，卻拖累了成千上萬的上游系統，這已經是開源生態的結構性問題，不是哪一家能單獨解決的。

聽到這兒，肯定有人會問：那以后干脆別用開源框架了？其實沒必要這么極端。問題從來不在開源本身，而在于用完之后沒人管。行業里已經有成熟的打法，而且技術門檻并不高。

第一步，先建軟件物料清單（SBOM），就像食品包裝上的配料表一樣，把AI系統里每一個組件、每一個版本、每一個已知漏洞都列清楚。你連自己用了什么都不知道，談何管理？

第二步，上軟件成分分析工具（SCA），讓工具自動掃依賴樹，把有漏洞的組件標出來，按危險等級排隊修復，而不是出事了才臨時抱佛腳。

第三步，建立依賴更新機制，定期跟蹤核心組件的安全補丁。20年前的漏洞到現在還在，就是因為沒人把這件事當成日常工作去做。

這三步說起來簡單，做起來考驗的是企業到底把安全當真事還是當擺設。

最后留三個問題給大家在評論區聊聊：

1. 你或者你的技術團隊，現在知道自己公司的AI系統到底用了哪些開源組件、這些組件有沒有已知漏洞嗎？

2. “74.5%的開源項目已經停止維護但還在被使用”——你覺得這個問題的根本責任，應該落在用了廢棄組件的開發者身上，還是沒建審計機制的企業頭上，還是整個行業和生態都得一起扛？

3. 如果今天有人告訴你，你正在用的那款大模型推理框架里有個攻擊者已經能利用的漏洞，你知道該找誰、要多久能把它徹底修掉嗎？

歡迎把你的答案和真實經歷寫在下面，咱們一起把AI供應鏈安全這件事聊得更透。