北京
我們的AI應用安全檢測器getdebug，在自己剛搭好的公開基準上跑了一圈，召回率只有23%——這意味著每四個真實漏洞，它只能揪出不到一個。
這個基準叫CodeSecBench Tier C，六個故意埋坑的AI應用倉庫，每個約40個文件，分別用了Next.js、Vite+Express+LangChain、SvelteKit+Anthropic等不同技術棧。每個倉庫藏了12到18個標記好的漏洞，涵蓋AI應用六大安全類別，總共149個標注行，外加33個安全近鄰和27個邊界案例。還有個“已知安全”控制文件，掃出任何東西都算誤報。
倉庫路徑全部刻意隨機化，避免基于名稱匹配偷跑。要考的是真正的檢測能力，不是背答案。
我們用getdebug 0.5.1分析前兩個倉庫，對比真相標記，召回率23%。但這個低分很“有用”——漏報高度集中，都栽在同樣的模式上：一是通過args.X的Shell和SQL注入，比如execAsync(args.command)或sql.unsafe(args.query)；二是在JSON響應體里明文返回API密鑰，像Response.json({apiKey: process.env.X_API_KEY})。
現有規則只認exec(tool.input.X)這類帶類型工具引用的形態，而現實中的AI應用直接用args作為函數參數，根本不在原本的白名單里。API密鑰泄露更是完全沒有針對規則。
好在這兩種形狀都能用正則覆蓋。我們用了一下午，新增兩條規則：一條把args加入合法標識符前綴，并擴展SQL不安全調用名單；另一條專門捕捉Response.json中包含apiKey的敏感字段。60分鐘后重新掃描，檢測器在同一個基準上的表現提升了15%。
一個公開的、貼近真實AI應用形態的漏洞基準，讓優化方向一下子清晰起來——比起內部那幾十個微型測試用例，這種差距肉眼可見。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
