北京
我们的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.
