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