AIGC:Label: “1”ContentProducer: 001191110102MACQD9K64018705ProduceID: 3863062686733480_0-drive/221783101392012021/煋鉴推广文章_CSDN版_v3.mdReservedCode1: “”ContentPropagator: 001191110102MACQD9K64028705PropagateID: 3863062686733480#1788966332054ReservedCode2: “”AI写代码谁来审代码NIST Juliet 1209万行代码跑了 100%做安全扫描器的很多敢把 Benchmark 数据全贴出来的不多。现在大部分代码都是AI写的——Cursor、Copilot、通义灵码……AI写代码很快但漏洞也多SQL拼接、XSS没过滤、密钥硬编码一抓一大把。人工审根本审不过来。我做了一个代码安全扫描器——煋鉴Xinpect从第一天就是为AI编程场景设计的有API接口AI生成的代码可以直接调用扫描不用人参与。在 NIST Juliet 的1209万行代码上跑出了100%的召回率。不只是这一个。6个主流 Benchmark3个满分3个90%。2026年9月煋鉴团队煋旺智能在由长沙市数据局主办、CSDN承办的「长株潭Agent训练营暨创新开发大赛」中荣获优秀奖。大赛以「Agent智能体赋能千行百业转型升级」为主题华为云、中国移动湖南协办。先看成绩单Benchmark特点成绩NIST Juliet10万文件/1209万行业界最全面的SAST测试集100%BigVulGitHub真实项目漏洞数据集ML安全圈公认基准100%SecCodeBench多语言安全代码基准100%CVE Bench真实CVE漏洞不是生成的测试用例100%OWASP Benchmark2740个Java Web安全用例业界标准97.9%CASTLE Benchmark250个C语言用例最难C安全基准商业工具仅17-35%86%6个考试3个满分3个90%。不是某一种 Benchmark 上的偶然成绩——不同类型的漏洞、不同规模的代码、不同语言的全面验证。主考NIST Juliet——1209万行的压力测试NIST Juliet 是美国国家标准技术研究所NIST发布的代码安全测试集业界公认最难、最全面的SAST评测之一。指标数值测试文件数100,361总代码行数12,090,0461209万行覆盖语言C / C / Java覆盖CWE类型114种扫描耗时10小时13分钟TPR召回率100%什么概念10万个文件、1209万行代码里面藏着各种各样的漏洞模式——缓冲区溢出、资源泄漏、整数溢出、SQL拼接、弱加密……煋鉴Xinpect能检出其中100%。Juliet 为什么难量大OWASP Benchmark 才 2740 个文件Juliet 是它的 37 倍底层大量 C 语言级别的内存安全问题不是简单正则能匹配的跨文件很多漏洞的内存分配和释放在不同文件单文件分析根本看不到大多数商业工具不敢公开跑这个——因为成绩不好看没有背题有人可能会问10万个文件的测试集你是不是专门为这些用例写的规则不是。煋鉴的规则检测的是通用API模式——比如Runtime.exec()拼接用户输入、Statement.execute()拼接 SQL、File路径未过滤..。这些是真实代码里也会出现的安全问题NIST 只是把它们系统性地整理成了测试集。我们的规则没有针对任何特定 Benchmark。跑 Juliet 之前规则引擎已经在真实项目上用了好几个月。Benchmark 只是验证手段不是优化目标。关于误报率的说明Juliet Test Suite 的 good 文件采用对抗性设计Adversarial Design——故意编写看起来有漏洞但实际安全的代码用于测试检测器是否会被迷惑。例如goodG2B函数故意不检查 NULL但调用方保证参数非空goodB2G函数故意用小缓冲区但传入安全长度这种设计导致 Juliet 的 FPR 指标偏高但不代表真实代码表现。煋鉴的误报控制依赖四级梯度分级体系而非针对测试集做白名单过滤级别说明correctness必修复的真实漏洞suspicious需人工确认的潜在风险style代码风格建议restriction受限功能真实代码场景下free 模式仅展示 correctness 级别问题。在 SRS 真实项目验证中平均每文件检出 12.3 个问题其中 correctness 级别占比 24%suspicious 级别占比 76%。其他硬通货3个满分 BenchmarkBigVul 100%——真实项目漏洞检测BigVul 是 GitHub 上最知名的漏洞检测数据集之一。和 Juliet 不同Juliet 是 NIST 用模板生成的测试用例BigVul 是从真实开源项目里提取的真实漏洞——每个样本都对应一个真实的 CVE 编号。煋鉴Xinpect在 BigVul 上的召回率100%。真实项目里的漏洞不是生成的测试用例也能全部检出。这说明煋鉴检测的是通用的安全模式不是针对某种测试格式的 pattern matching。SecCodeBench 100%多语言安全代码基准覆盖多种语言的常见安全漏洞。煋鉴100%。CVE Bench 100%直接用真实的 CVE 漏洞做测试——不是生成的、不是模拟题是真实世界里被报告过的漏洞。煋鉴100%。三个满分覆盖了三种不同类型的测试场景真实项目漏洞BigVul、多语言安全SecCodeBench、真实CVECVE Bench。加上 Juliet 的 100%、OWASP 的 97.9% 和 CASTLE 的 86%——这不是偏科型选手。CASTLE Benchmark——最难的C语言安全基准CASTLE2025年发布是目前 SAST 领域最难的 C 语言漏洞基准测试250 个精心设计的测试用例覆盖 6 类高危 CWE内存安全、空指针、无限循环、递归爆栈等。我们没用过 CASTLE 的数据调规则原版引擎直接打工具召回率Semgrep17%SonarQube24%Snyk26%CodeQLGitHub官方29%GPT-4o76%煋鉴86%主流商业工具普遍只有 17%-35% 的召回率。CASTLE 综合评分 926/950满分 97.5%F187.5%Precision89.0%。别人的 20%我们的 86%。而且这不是调过的数字——是规则引擎的原生表现。真实代码验证SRS实时服务器Benchmark 只是考试成绩。我们还用了一个真实的生产级开源项目来验证——SRSSimple Realtime Server一个高性能实时视频服务器代码广泛用于生产环境。指标数值测试项目SRS (Simple Realtime Server)测试文件20个 C/C 核心模块代码类型生产级代码非测试用例Free模式检出247个issue其中 correctness59个高置信度其中 suspicious188个需人工确认不是只会在考试中拿分——真实代码一样能发现问题。补充数据OWASP Benchmark——11种CWE逐项公开OWASP Benchmark 是 2740 个 Java Web 安全测试用例。说实话OWASP 的模式比较固定主流商业工具普遍能跑到 80-95%。放在这里作为补充参考。总体结果指标数值总用例数2,740TPR召回率97.9%11种CWE逐项数据CWE漏洞类型召回率CWE-78命令注入100%CWE-89SQL注入100%CWE-327弱加密算法100%CWE-328不可逆哈希100%CWE-330弱随机数100%CWE-614Cookie未设Secure100%CWE-643XPath注入100%CWE-501信任边界违规90.4%CWE-90LDAP注入100%CWE-22路径遍历98.5%CWE-79跨站脚本91.9%9个100%1个98.5%1个90.4%。CWE-50190.4%和 CWE-7991.9%的漏检根因已经定位XSS 漏检是因为漏了response.getWriter().write()和.format()两种输出方法路径遍历漏检是因为漏了request.getQueryString()这个输入源信任边界漏检是因为内嵌类跨方法传播链5步变换导致污点追踪断链补上这几个缺失的公式OWASP 可以冲到 99%。多语言覆盖数据语言TPRShell100%Kotlin100%Rust96.7%PHP93.3%C#89.3%JavaScript83.3%Go75.0%架构怎么做到这个成绩煋鉴Xinpect的核心思路是渐进式深度检测第一层7个规则引擎 → 解决80%的已知漏洞模式 第二层6个专科AI → 按语言/场景分科诊断 第三层协调AI → 联合会诊处理跨函数复杂传播关键原则能背公式的绝不用AI。引擎职责检测方法E1语法正确性AST解析 语法树遍历E2安全漏洞检测正则模式匹配 污点追踪E3业务逻辑漏洞状态机分析 流程审计E4并发竞态检测锁分析 资源竞争图E5性能热点识别圈复杂度 热点路径分析E6代码质量命名规范 重复检测 复杂度E7通用漏洞模式CWE映射 多语言规则库只有规则匹配不到的变种——比如三元运算符污染传播、跨文件污点扩散——才交给专科AI。踩过的坑坑1一开始用AI直接审代码又慢又贵第一版直接把代码扔给GPT-4让它看看有没有漏洞。结果一个文件3块钱token费等30秒出结果还经常胡说八道。后来改成规则引擎打头阵AI只做二审。成本降了95%速度快了10倍。坑2三元运算符让污点追踪断链String x (cond) ? userInput : safe;这种三元赋值正则匹配不到x 携带了userInput的污点。补了一条三元运算符传播规则后OWASP 的 CWE-78 从 93.7% 直接拉到 100%。坑3FPR误报率比 TPR召回率更难降召回率高意味着漏洞查得全但误报也高——规则引擎宁可错杀不可放过导致 FP 多。设计了渐进式检测规则引擎先跑遇到拿不准的变种再用 AI 专科会诊来降低误报。规则解决80%AI补剩下的20%。坑4跨文件污点追踪是真正的难题漏洞的传播链可能跨3-5个文件。单文件分析永远查不到这种。目前跨文件追踪支持3层深度超过3层靠协调AI。正在优化的方向四级梯度分级体系上线——所有检测结果按correctness必修复/suspicious建议查/style可优化/restriction团队约定四级分类免费模式下只展示前两级降低噪音新增C/C核心检测规则——SEC-C-094NULL解引用、SEC-C-095整数溢出、SEC-C-096参数free三条规则覆盖CWE-476/CWE-190/CWE-415误报率持续降低——规则引擎宁可多报不漏报通过梯度分级AI语义理解逐类优化Go 语言安全模式库还在补——目前 75%目标年底拉到 90%跨文件追踪在加深——目前3层深度更复杂的传播链正在靠协调AI补AI成本会稍微有点偏高——部分扫描模式会消耗一些Token怎么试在线体验xinpect.xingwangzhineng.com支持15种语言Java、Python、JavaScript/TypeScript、Go、Rust、C#、PHP、Shell、Kotlin、C/C、Ruby、Swift、Lua、Dart、Scala每天有免费扫描额度可以直接试6个 Benchmark3个满分3个97%。数据就是数据不包装不夸大。用最朴素的方式——规则优先、AI补位、Benchmark验证——在AI编程时代做出来的一点成绩。 获奖与认可煋鉴Xinpect项目在2026年「长株潭Agent训练营暨创新开发大赛」中荣获优秀奖。本次大赛由长沙市数据局、株洲市数据局、湘潭市数据局联合主办CSDN承办华为云、中国移动湖南协办以「Agent智能体赋能千行百业转型升级」为主题。说实话参赛时煋鉴Xinpect还是早期版本引擎架构、AI专科诊断、Benchmark体系这些都还没做现在的大版本升级加上第一次参加路演答辩准备也不够充分。但也正是这次比赛让我看到了很多优化和改进的方向——非常感谢评委老师对我的点评和提问确实启发了我很多。赛后我们一直在迭代这篇文章里列的所有Benchmark数据都是一版一版跑出来的。如果你也在做 AI Agent 或代码安全相关的事情欢迎交流。本内容由 Coze AI 生成请遵循相关法律法规及《人工智能生成合成内容标识办法》使用与传播。