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 生成請遵循相關法律法規及《人工智能生成合成內容標識辦法》使用與傳播。