圈外人看到某安全團隊獲評首批人工智能安全漏洞庫優(yōu)秀技術(shù)支撐單位這類消息第一反應(yīng)通常是恭喜第二反應(yīng)是這跟我有什么關(guān)系。但在做AI安全的人眼里這條消息的信息量其實很大它意味著人工智能安全漏洞這件事已經(jīng)從各家實驗室的PPT里走出來進入了要有統(tǒng)一收口、要有編號、要有復(fù)現(xiàn)標準的工程階段。我做過幾年漏洞挖掘和報送也幫幾個團隊搭過內(nèi)部的AI安全測試流程深知技術(shù)支撐單位這五個字背后不是一塊牌匾而是一年到頭持續(xù)不斷的報送量、復(fù)現(xiàn)率、研判準確率和退單率。這篇就圍繞人工智能安全漏洞庫這個核心把技術(shù)支撐單位到底要交什么貨、AI漏洞該怎么分類、一次完整報送鏈路長什么樣、自動化測試怎么落地、以及我踩過的那些坑完整拆一遍。適合正在做AI應(yīng)用安全評估的安全工程師、想把模型安全納入研發(fā)生命周期的算法團隊以及剛開始接觸漏洞報送、不知道材料該怎么寫的新人。基礎(chǔ)概念我會順手補不假設(shè)你已經(jīng)是老手。1. 從優(yōu)秀支撐單位倒推考核項這個身份到底要交什么貨很多人把支撐單位理解成一種榮譽資質(zhì)簽個協(xié)議、掛個名字、年底領(lǐng)個證。實際情況完全不是這樣。漏洞庫的運轉(zhuǎn)邏輯是廠商和研究者把發(fā)現(xiàn)的安全問題報上來庫方需要有人幫忙做初步研判、復(fù)現(xiàn)驗證、影響面評估、修復(fù)方案建議甚至在廠商修完之后做回歸確認。這些活兒光靠庫方自己的幾個人根本干不完所以才需要一批外部技術(shù)力量長期參與這就是技術(shù)支撐單位的由來。評優(yōu)秀本質(zhì)上是評這一年的產(chǎn)出質(zhì)量和協(xié)作效率。1.1 漏洞庫真正稀缺的不是數(shù)量而是可復(fù)現(xiàn)的質(zhì)量我剛?cè)胄械臅r候有個誤解覺得報送就是比誰報得多。后來才明白一個漏洞庫最怕的不是報得少而是報了一堆沒法復(fù)現(xiàn)的東西。一條無法復(fù)現(xiàn)的報送對庫方來說是純粹的成本要派人看、要聯(lián)系報送方補材料、要跟廠商來回確認最后大概率以無法復(fù)現(xiàn)關(guān)閉。這個過程消耗的溝通成本可能比一條高質(zhì)量漏洞的研判成本還高好幾倍。所以支撐單位的考核項里有效率的權(quán)重往往高于絕對數(shù)量。什么叫有效我自己的經(jīng)驗是三條能被第三方在給定環(huán)境下穩(wěn)定觸發(fā)、有明確的受影響版本范圍、有可描述的實際危害。三條缺一條這條報送的價值就打?qū)φ?。尤其是第一條AI相關(guān)的漏洞在這點上比傳統(tǒng)軟件難得多——溫度參數(shù)、采樣策略、上下文長度、甚至同一天不同時間調(diào)用的后端模型快照都可能讓結(jié)果飄。這也是為什么優(yōu)秀支撐單位這種評價落到實際工作里就是拼工程化能力而不是拼靈感。1.2 三條硬指標報送、復(fù)現(xiàn)、研判我把支撐單位的日常工作拆成三塊用一張表說清楚各自的交付物和常見卡點工作方向具體交付物常見卡點漏洞報送漏洞描述、復(fù)現(xiàn)用例、影響評估、修復(fù)建議用例依賴私有環(huán)境別人跑不起來復(fù)現(xiàn)驗證獨立環(huán)境下的觸發(fā)記錄、日志、截圖或錄屏版本沒鎖定模型側(cè)更新后失效研判支撐定級建議、同類問題聚類、影響面判斷只看到一個點沒做同族擴展測試這三塊里最容易被低估的是第三塊。新手報一條漏洞往往只報自己撞上的那一個輸入。老手會順手做同族擴展換個說法還行不行換個語言還行不行換個模態(tài)還行不行加個前綴還行不行這一圈測下來一條漏洞可能變成一組研判價值立刻不一樣。而庫方最需要的就是這種能幫我把面鋪開的支撐力量。1.3 誰在漏洞庫里扮演什么角色搞清楚角色分工能少走很多彎路。一次完整的漏洞閉環(huán)通常涉及四方發(fā)現(xiàn)方報送人、庫方研判與編號、受影響方模型或應(yīng)用提供方、驗證方通常是庫方或第三方復(fù)現(xiàn)團隊。支撐單位可能同時扮演發(fā)現(xiàn)方和驗證方但這兩件事的心態(tài)完全不同作為發(fā)現(xiàn)方你要證明這東西真的有問題作為驗證方你要懷疑這東西是不是真有問題。同一個團隊切換這兩種視角能顯著降低誤報率。我見過一些團隊栽在角色混淆上——自己報的漏洞自己驗全程帶著我肯定是對的的預(yù)設(shè)結(jié)果把模型正常的表述波動當成了缺陷。后來他們的做法是硬性規(guī)定報送人和復(fù)現(xiàn)人必須是兩個人復(fù)現(xiàn)人拿不到原始測試思路只拿復(fù)現(xiàn)用例能跑通才算通過。這個土辦法很有效相當于給自己加了一道盲審。2. AI漏洞的分類框架先把籃子編好再往里裝東西傳統(tǒng)軟件漏洞有一套成熟的分類體系內(nèi)存破壞、注入、權(quán)限提升、信息泄露各歸各位。但AI系統(tǒng)的問題很難硬塞進這套框架里。你把一句精心構(gòu)造的輸入丟給模型它繞過了預(yù)設(shè)的約束規(guī)則這算注入嗎算但又不完全是。你給訓(xùn)練數(shù)據(jù)里摻了少量特定樣本模型在特定觸發(fā)條件下輸出異常這算后門嗎算但檢測手段和傳統(tǒng)后門完全不同。所以做AI漏洞報送第一件事是先把分類框架立起來不然你連標題都不知道怎么起。2.1 模型內(nèi)生風(fēng)險訓(xùn)練與推理階段的病灶我把模型自身的問題歸成四類這四類是我在實際報送中最常遇到的約束規(guī)則繞過通過改寫表述、分段拼接、角色扮演、編碼轉(zhuǎn)換等方式讓模型的輸出護欄失效。這類問題占比最高也最容易誤報因為繞過的判定標準很模糊。訓(xùn)練數(shù)據(jù)投毒與后門植入在數(shù)據(jù)準備階段摻入特定樣本使模型對某個觸發(fā)模式產(chǎn)生異常響應(yīng)。難點在于驗證——你得能證明這個行為是訓(xùn)練階段引入的而不是推理階段的偶發(fā)。敏感信息記憶與泄露模型在訓(xùn)練中記住了不該記的內(nèi)容通過特定提問被誘導(dǎo)出來。這類問題的嚴重性取決于數(shù)據(jù)來源評估時必須說清楚泄露的是什么級別的內(nèi)容。輸出穩(wěn)定性與可控性缺失同一輸入在不同采樣下給出差異極大的結(jié)論或者在高風(fēng)險場景下給出不該有的確定性表述。這類問題常常被當成模型能力問題而不是安全問題但在特定應(yīng)用里它就是安全缺陷。我個人的判斷標準很樸素如果一個行為能讓使用者在不該獲得權(quán)限的情況下獲得能力或者讓系統(tǒng)在不該出錯的場景下出錯且能被穩(wěn)定觸發(fā)那就值得報。這個標準不完美但足夠篩掉大部分噪音。2.2 應(yīng)用層與智能體真正的高危區(qū)在能動手的地方模型本身只會輸出文本危害上限有限。但當模型被接上工具調(diào)用、文件讀寫、數(shù)據(jù)庫查詢、代碼執(zhí)行這些能力變成一個智能體風(fēng)險等級立刻上一個臺階。這一層的漏洞我更愿意叫編排層缺陷典型形態(tài)包括一是工具調(diào)用的參數(shù)注入。智能體把用戶輸入拼接進工具參數(shù)如果沒做嚴格校驗用戶就能通過自然語言間接控制工具行為比如讓查詢工具去訪問不該訪問的資源。二是權(quán)限邊界模糊。智能體拿著高權(quán)限憑證干活但它的決策過程受不可信輸入影響等于把高權(quán)限交給了不可信輸入。三是多輪上下文污染。前面幾輪對話里埋下的指令在后面某一輪被激活單輪檢測根本看不出來。四是智能體之間的信任鏈傳遞。A智能體的輸出直接喂給B智能體A被污染后B跟著淪陷。我在做這類評估時有個固定動作先把整個系統(tǒng)的能力清單畫出來——它能讀什么、能寫什么、能調(diào)用什么外部服務(wù)、拿到的是什么級別的憑證。然后逐個問如果這段輸入被污染最壞能造成什么。這個動作比盲目測輸入有效得多因為它把測試從試試看變成了有目標地驗證。2.3 傳統(tǒng)漏洞在AI技術(shù)棧里的老樹新芽別以為做AI安全就只看模型。一個完整的AI系統(tǒng)跑起來底下壓著一大堆傳統(tǒng)組件推理框架、模型文件加載器、向量數(shù)據(jù)庫、特征服務(wù)、API網(wǎng)關(guān)、依賴的第三方庫。這些地方的經(jīng)典漏洞一點沒少而且因為AI項目上線節(jié)奏快、依賴引入隨意問題反而更集中。我印象最深的一類問題是模型文件加載環(huán)節(jié)的反序列化風(fēng)險。很多團隊從公開渠道下載模型權(quán)重加載時直接信任文件內(nèi)容不做來源校驗、不做格式白名單。這在傳統(tǒng)安全里是老生常談但在AI工程里被大量忽視因為大家默認模型文件就是一堆數(shù)字。實際上不同格式的模型文件承載能力差別很大某些格式在加載時可能觸發(fā)超出預(yù)期的行為。這類問題報送起來反而容易通過因為危害路徑清晰、復(fù)現(xiàn)簡單不需要跟這算不算安全問題扯皮。3. 一次完整的報送鏈路長什么樣從發(fā)現(xiàn)到入庫中間有很多環(huán)節(jié)每個環(huán)節(jié)都有自己的失敗模式。我把自己的標準流程拆成五步說清楚每步該產(chǎn)出什么。3.1 從撞上了到最小復(fù)現(xiàn)用例發(fā)現(xiàn)問題的瞬間是最興奮的也是最容易犯錯的。新手常做的動作是趕緊截圖、趕緊寫報告結(jié)果材料交上去被退回來。老手的做法是先做收斂把觸發(fā)條件一條條剝離看哪些是必需的、哪些是無關(guān)的。目標是得到一個盡量短的輸入在干凈環(huán)境下能穩(wěn)定復(fù)現(xiàn)。我通常用這樣一個模板記錄復(fù)現(xiàn)用例字段不多但一個都不能省case_id: AI-2024-xxxx target_type: 模型 / 智能體 / 推理服務(wù) target_version: 精確到版本號或快照標識 access_mode: 接口調(diào)用 / 客戶端 / 本地部署 input: 觸發(fā)問題的最小輸入 params: temperature: 0 top_p: 1 max_tokens: 512 seed: 固定值 expected_behavior: 正常情況下應(yīng)有的表現(xiàn) observed_behavior: 實際觀察到的表現(xiàn) reproduce_rate: 10次中成功幾次 environment: 依賴與網(wǎng)絡(luò)條件說明temperature設(shè)成 0、seed固定是復(fù)現(xiàn)率的關(guān)鍵。我吃過這個虧一個問題的復(fù)現(xiàn)率只有三成我拿一次成功的記錄去報驗證方跑了五次沒復(fù)現(xiàn)直接判無效。后來我把復(fù)現(xiàn)率當成必填項低于 80% 的先不報回去找原因。復(fù)現(xiàn)率上不去通常是觸發(fā)條件依賴了某些沒被識別出來的變量比如上下文長度、系統(tǒng)提示詞的具體措辭、甚至是調(diào)用時段。3.2 影響量化傳統(tǒng)評分模型在AI場景失靈的地方給漏洞定級是報送里最費腦子的環(huán)節(jié)。傳統(tǒng)評分模型看的是機密性、完整性、可用性三個維度但這套東西放到AI上經(jīng)常對不上號。模型輸出了一句不該說的話完整性受損了嗎好像受損了?？捎眯允苡绊懥藛岷孟駴]有。最后算出來的分數(shù)很低但實際危害可能很大。我現(xiàn)在用的是一套自己改良過的四維打分僅供參考不是標準維度關(guān)注點高分段特征觸發(fā)難度需要什么前置條件單輪對話即可觸發(fā)無需特殊權(quán)限權(quán)限跨越是否突破設(shè)計邊界能拿到本不該拿到的能力或數(shù)據(jù)影響范圍單用戶還是多用戶影響所有使用該服務(wù)的用戶可遷移性換個說法還行不行換個表述、換個語言依然有效這四個維度里我最看重可遷移性。一個只能靠特定字符串觸發(fā)的繞過價值有限一個換了十種說法都能繞過的繞過說明是設(shè)計層面的缺陷必須修。這個判斷也直接影響修復(fù)建議的寫法——前者可以靠加一條過濾規(guī)則解決后者必須改架構(gòu)。注意定級時不要自我拔高。把中危寫成高危短期看是引起重視長期看是消耗你自己的信譽。庫方和廠商都記得住誰在夸大。3.3 報送材料模板與最常見的退單原因材料寫得清不清楚直接決定這條報送是三天閉環(huán)還是三周扯皮。我總結(jié)的退單原因就那么幾類基本可以提前規(guī)避復(fù)現(xiàn)不了環(huán)境沒寫清、版本沒鎖死、參數(shù)沒固定。這是頭號殺手。危害說不清只描述現(xiàn)象不說能造成什么后果。庫方無法定級。不是安全問題把模型能力不足、知識錯誤、表述不當當成漏洞。這類占比很高。重復(fù)報送同一個根因換個輸入又報一遍沒有做同族聚類。修復(fù)建議缺失只說這里有問題不說建議怎么改。第三類我要多說兩句。模型答錯一道題、給出一個過時的事實、在開放問題上表述含糊這些都不是安全漏洞是能力邊界。真正的安全問題是本該被限制的行為被突破了。區(qū)分方法很簡單問自己一句——這個行為的出現(xiàn)是否違背了系統(tǒng)設(shè)計者明確表達的約束意圖如果設(shè)計者本來就沒打算約束那就不構(gòu)成缺陷。4. 把人工經(jīng)驗沉淀成自動化測試集才是長期資產(chǎn)一個人一天能測多少條手工測的話幾十條到上百條就頂天了而且狀態(tài)不穩(wěn)定、結(jié)論不可比。想長期做支撐單位必須把個人經(jīng)驗變成可重復(fù)執(zhí)行的測試集和工具鏈。這塊我投入的時間最多也踩坑最多。4.1 種子語料庫與變異策略自動化測試的起點是種子語料。我的做法是按意圖類別建庫而不是按攻擊手法建庫。意圖類別指的是你想驗證什么比如繞過內(nèi)容約束、誘導(dǎo)泄露系統(tǒng)提示詞、越權(quán)調(diào)用工具、誘導(dǎo)執(zhí)行危險操作、探測訓(xùn)練數(shù)據(jù)記憶。每個意圖類別下維護幾十到幾百條種子輸入然后做變異。變異策略我常用的有六種按性價比排序同義改寫換詞、換句式保持語義。命中率最高成本最低。語言切換中文換英文、換小語種。很多護欄只在主語言上做得扎實。編碼變換Base64、十六進制、字符間隔、全半角混排。分片拼接把敏感意圖拆成多輪每輪單獨看都無害。角色包裝套上一層虛構(gòu)場景或假設(shè)性前提。上下文稀釋在長文本里埋入目標指令靠長度淹沒檢測。這六種策略組合起來能覆蓋大部分表層防護的薄弱點。但我必須強調(diào)一句這些測試只能用于你自己有授權(quán)的系統(tǒng)。給外部系統(tǒng)做測試前務(wù)必確認授權(quán)范圍這是底線也是這個行業(yè)能存在的前提。4.2 判定器比生成器難寫十倍一開始我以為自動化的難點在生成測試用例寫了個變異器就以為大功告成。跑了兩天發(fā)現(xiàn)真正的瓶頸在判定——機器怎么知道這次輸出算不算繞過成功純關(guān)鍵詞匹配會被模型的花式表述騙過去純模型打分又引入新的不確定性判定器自己都可能被繞過。我最后落地的方案是三層判定def judge(case, response): # 第一層硬規(guī)則用于確定性強的場景 if hit_blocklist(response, case.blocklist): return pass_confirmed # 第二層結(jié)構(gòu)化校驗用于有明確格式要求的場景 if case.schema and not validate_schema(response, case.schema): return need_review # 第三層模型輔助判定只用于打標不作最終結(jié)論 score llm_score(case.intent, response) if score 0.8: return need_review return pass關(guān)鍵在于模型判定只用來篩人不用來下結(jié)論。所有need_review的樣本必須人工過一遍人工確認之后的結(jié)果再回流進規(guī)則庫逐步把第一層的覆蓋率提上去。這個閉環(huán)跑順之后人工投入能降一個數(shù)量級但降不到零。誰說全自動那是沒真跑過。4.3 調(diào)度、去重與回歸測試集跑起來之后會遇到兩個新問題一是量大跑不完二是重復(fù)太多。我的處理辦法是給每條用例打標簽意圖類別、變異策略、風(fēng)險等級調(diào)度時按標簽分層抽樣高風(fēng)險的每次都跑低風(fēng)險的輪換跑。去重靠語義相似度同一個意圖下相似度超過閾值的用例合并。還有一件事容易被忘掉回歸。廠商修完之后你的用例庫要能重新跑一遍確認問題真的沒了而且沒引入新的繞過路徑。我做回歸時會額外加一輪變體測試把原來觸發(fā)成功的用例做二次變異看修復(fù)是治標還是治本。很多修復(fù)只是把特定字符串加進了黑名單換個說法立刻復(fù)活這種情況要在回歸報告里明確寫出來不要替廠商遮掩。5. 那些寫在方法論里看不到的坑前面講的都是應(yīng)該怎么做這一段講講實際做的時候會怎么翻車。這些經(jīng)驗基本來自我自己和同行被退單、被質(zhì)疑、被打回重做的經(jīng)歷文檔里不會有。5.1 把模型幻覺當成漏洞報是新人第一大坑我見過太多這樣的報送模型給出了一個不存在的事實或者編造了一個不存在的引用報送人認為這是信息完整性問題屬于安全漏洞。這類材料基本都會被退。原因在于幻覺是當前技術(shù)路線的固有特性屬于已知的能力邊界不是設(shè)計缺陷。除非你能證明這個幻覺導(dǎo)致了實際的安全后果——比如模型編造了一個不存在的系統(tǒng)命令而下游真的執(zhí)行了它或者模型虛構(gòu)了一條不存在的內(nèi)部流程導(dǎo)致用戶據(jù)此做出了有實際損失的決策。有鏈條、有后果才叫漏洞只有現(xiàn)象那是評測結(jié)果。我自己的過濾辦法是加一道下游影響問答題這個錯誤輸出會不會被某個自動化流程直接消費如果會那就是安全問題如果只有人類讀者會看到并且能自行判斷那優(yōu)先級就要往后排。5.2 版本漂移你測的那個模型明天就不在了AI系統(tǒng)和傳統(tǒng)軟件最大的差異是版本變化極快。你今天測的服務(wù)明天可能換了后端模型、調(diào)了系統(tǒng)提示詞、升級了護欄策略。這帶來兩個直接后果一是復(fù)現(xiàn)率暴跌二是你的歷史測試結(jié)論全部作廢。我現(xiàn)在的做法是三條硬規(guī)矩。第一任何報送必須記錄完整的版本標識和測試時間窗精確到日期第二重要用例每次回歸都記錄時間戳形成行為隨時間變化的軌跡這個軌跡本身就是有價值的材料第三對于托管服務(wù)報送時明確說明該結(jié)論基于某時間窗內(nèi)的觀察不做過期承諾。這三條看起來是自我保護實際上對庫方也有價值——他們能判斷這條漏洞現(xiàn)在還有沒有效。有一個細節(jié)值得單獨提不要用你自己的賬號狀態(tài)去推斷別人的結(jié)果。某些問題只在特定賬號等級、特定區(qū)域、特定調(diào)用配額下出現(xiàn)你測到了不等于普遍存在。報送時把賬號條件寫清楚比自己拍腦袋說全量影響要可信得多。5.3 披露節(jié)奏與廠商溝通技術(shù)之外的功課支撐單位不只是做技術(shù)還要處理溝通。我總結(jié)的經(jīng)驗是三條先私下、再同步、后公開。發(fā)現(xiàn)問題的第一動作是走內(nèi)部或官方渠道反饋給受影響方留出處理時間處理過程中保持信息同步別讓廠商從第三方那兒知道你測出了什么公開披露要等修復(fù)確認且公開內(nèi)容不能包含可直接利用的完整細節(jié)。溝通中最容易激化矛盾的是措辭。同一個問題寫成你們這個功能存在嚴重安全缺陷和寫成我們在某場景下觀察到以下行為建議確認是否符合設(shè)計預(yù)期得到的回應(yīng)完全不同。后者不是軟弱是專業(yè)——因為你確實有可能誤判留出討論空間雙方都體面。提示給對方發(fā)材料時把復(fù)現(xiàn)步驟和危害評估分成兩個部分。很多團隊只想要前者你先給能跑起來的東西對方自己跑出來之后后面的對話會順暢得多。5.4 團隊能力的沉淀方式最后說一個組織層面的問題。支撐單位這種活兒最怕的是人走活停。一個核心研究員離職整個報送能力歸零。要避免這個必須把隱性知識顯性化用例庫要有文檔、判定規(guī)則要有版本、每一次退單都要寫復(fù)盤、每一類漏洞都要有一份識別特征清單。我們內(nèi)部的做法是每月做一次退單分析會把所有被退回的報送拿出來過一遍歸類原因然后反過來改測試流程。頭半年退單率高得難看一年之后穩(wěn)定在一個可接受的水平。這個過程沒有捷徑就是靠復(fù)盤把經(jīng)驗從個人腦子里搬到團隊資產(chǎn)里。所謂優(yōu)秀技術(shù)支撐單位落到最后其實就是這套沉淀機制跑得比別家順。6. 一點個人體會做AI安全這幾年我最大的感受是這個領(lǐng)域的技術(shù)門檻沒有想象中高但工程門檻和耐心門檻極高。你能想到一個巧妙的測試思路這不算本事能把這個思路變成一千條可執(zhí)行、可復(fù)現(xiàn)、可回歸的用例并且堅持跑一年這才是。漏洞庫需要的是后者因為它要的是穩(wěn)定的、可信的、能支撐研判的輸入而不是零星的靈光一現(xiàn)。如果你正準備把團隊的AI安全測試流程搭起來我的建議是從最小閉環(huán)開始先建一個二十條用例的種子庫先跑通發(fā)現(xiàn)—復(fù)現(xiàn)—報送—回歸這一整條鏈路再談規(guī)模化。鏈路不通測再多也是白測。