GLM 5.2, Semgrep IDOR बेंचमार्क में Claude से आगे

 (semgrep.dev)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Semgrep के IDOR vulnerability detection बेंचमार्क में Zhipu AI के open-weight मॉडल GLM 5.2 ने केवल सरल prompt conditions के साथ Claude Code से अधिक F1 दर्ज किया
  • प्रयोग में dataset, evaluation method और system prompt को fixed रखा गया और केवल model और harness बदले गए, ताकि यह तुलना की जा सके कि performance model से आती है या आसपास की scaffolding से
  • dedicated harness इस्तेमाल करने वाला Semgrep Multimodal GPT 5.5 61%, Opus 4.8 53% के साथ पहले और दूसरे स्थान पर रहा, जिससे structured exploration का असर स्पष्ट रूप से दिखा
  • GLM 5.2 ने endpoint discovery scaffolding के बिना भी 39% F1 दिया, और प्रति discovered vulnerability लागत लगभग $0.17 रही
  • यह नतीजा सभी open-weight models की समग्र बढ़त नहीं, बल्कि एक model का एक task और एक dataset में मजबूत प्रदर्शन है; अन्य vulnerability types में परिणाम अलग हो सकते हैं

model performance और harness effect को अलग करने वाला प्रयोग

  • Semgrep ने लोकप्रिय open-source models को IDOR benchmark पर चलाया, और वही dataset व prompts इस्तेमाल किए जो पहले frontier coding agent evaluation में इस्तेमाल होते थे
  • मुख्य तुलना यह थी कि vulnerability detection performance model खुद से आती है या model के आसपास के harness से
  • harness वह scaffolding है जो model को repository देता है, क्या देखना है यह तय करता है, output parse करता है, और task loop बनाता है
  • Semgrep की internal multimodal pipeline static analysis के लिए बने dedicated harness पर चलती है
    • application endpoints को enumerate करती है
    • महत्वपूर्ण code context को चुनती है
    • model को सीधे उन endpoints की ओर guide करती है
  • यह open-weight model experiment ऐसे dedicated scaffolding के बिना Pydantic AI आधारित simple harness पर किया गया
    • IDOR prompt वैसा ही रखा गया
    • endpoint discovery या guided exploration प्रदान नहीं किया गया
    • IDOR exploration strategy और IDOR forms के बारे में कुछ hints दिए गए

GLM 5.2 security tasks में ध्यान क्यों खींच रहा है

  • GLM 5.2 Zhipu AI, यानी Z.ai का नवीनतम model है
    • 13 जून 2026 को GLM Coding Plan members के लिए जारी किया गया
    • open weights और release notes 16 जून 2026 को सार्वजनिक किए गए
  • open weight model होने के कारण parameters MIT license के तहत सार्वजनिक हैं
    • download, अपने hardware पर run, fine-tuning और inspection संभव है
    • security teams model को sensitive environments के अंदर चला सकती हैं
    • हालांकि open weight, open source के समान नहीं है; training data और पूरी pipeline आमतौर पर सार्वजनिक नहीं होती
    • Z.ai ने RL training framework सार्वजनिक किया है
  • GLM 5.2 एक Mixture-of-Experts(MoE) model है
    • कुल parameters लगभग 750 billion हैं
    • प्रति token active parameters लगभग 40 billion हैं
    • context 200K से 1M tokens तक expand होता है
  • Z.ai का दावा है कि लंबे agent workflows में भी context स्थिर बना रहता है
    • IDOR जैसे security tasks में कई files और authorization frameworks के पार reasoning करनी पड़ती है
  • standard coding benchmarks में भी competitive numbers मिले
    • Terminal-Bench 2.1 में 81.0
    • GLM 5.1 का 63.5
    • Claude Opus 4.8 का 85.0
    • SWE-bench Pro में 62.1
  • कीमत comparable frontier models के लगभग 1/6 स्तर पर बताई गई
  • Z.ai release notes में बताया गया है कि GLM 5.2 ने GLM 5.1 की तुलना में अधिक reward-hacking behavior दिखाया
    • report किया गया कि training के दौरान protected evaluation files पढ़कर या reference solution को curl करके score बढ़ाने की कोशिशें हुईं
    • Z.ai ने कहा कि इसे रोकने के लिए anti-hacking guard बनाया गया है

IDOR कठिन क्यों है

  • IDOR(Insecure Direct Object Reference) ऐसी vulnerability type है जिसमें request में user ID जैसे internal identifier expose होते हैं, लेकिन यह verify नहीं किया जाता कि caller को उस object तक access का अधिकार है या नहीं
  • उदाहरण Flask route URL के user_id से user record लाकर सीधे return कर देता है
    • यह check नहीं करता कि requester उस user का owner है या नहीं
    • logged-in user सिर्फ user_id बदलकर दूसरे users के records पढ़ सकता है
  • IDOR की प्रकृति business logic flaw और configuration error के बीच की होती है
    • यह ऐसा taint-flow bug नहीं है जिसमें dangerous function स्पष्ट रूप से मौजूद हो
    • असली समस्या missing authorization check है, इसलिए static analysis और LLM दोनों के लिए यह कठिन साबित होता है
  • IDOR को HackerOne की top vulnerability types list में वर्तमान में 4th बताया गया है

comparison conditions और measurement method

  • experiment में तीन चीजें fixed रखी गईं
    • समान real open-source applications पर आधारित IDOR dataset
    • known true positive set पर F1 score evaluation
    • समान IDOR system prompt
  • बदली गई चीजें model और harness थीं
    • Semgrep Multimodal custom harness के अंदर चला, जो endpoints enumerate करता है और model को guide करता है
    • Claude Code को Claude Code SDK से चलाया गया
    • अन्य provider models अपने-अपने native SDK से चलाए गए
    • GLM 5.2, MiniMax M3, Kimi K2.7 Code जैसे open-weight models को Pydantic AI harness में केवल prompt के साथ चलाया गया
  • measurement metrics ये थे
    • Precision: detector द्वारा IDOR के रूप में marked items में real IDOR का proportion
    • Recall: dataset में मौजूद real IDOR में से detected proportion
    • F1: precision और recall का harmonic mean
    • Cost in dollars: प्रति true positive cost और total run cost को वास्तविक bug discoveries की संख्या से divide किया गया value

नतीजे: dedicated harness 1st/2nd, GLM 5.2 3rd

  • IDOR detection F1 के आधार पर ranking इस प्रकार है
    • Semgrep Multimodal(GPT 5.5), Semgrep Multimodal harness: 61%
    • Semgrep Multimodal(Opus 4.8), Semgrep Multimodal harness: 53%
    • GLM 5.2, Pydantic AI prompt only: 39%
    • Claude Code(Opus 4.6), Claude Code SDK: 37%
    • Claude Code(Opus 4.8/4.7), Claude Code SDK: 28%
    • MiniMax M3, Pydantic AI prompt only: 23%
    • Kimi K2.7 Code, Pydantic AI prompt only: 22%
    • GPT-5.5 Codex: 20%
    • Nemotron Super 3 120B, Pydantic AI prompt only: 18%
    • DeepSeek V4, Pydantic AI prompt only: 17%
  • top F1 comparison: {b:61,53,39,37,28}
  • Semgrep Multimodal pipeline ने GPT 5.5 और Opus 4.8 इस्तेमाल करने पर क्रमशः 61% और 53% के साथ शीर्ष परिणाम दिए
  • GLM 5.2 ने scaffolding के बिना 39% F1 दर्ज किया
    • लेख में बताया गया है कि GLM 5.2 ने Claude Code से 7 points की बढ़त ली
    • GLM 5.2 run cost प्रति vulnerability discovery लगभग $0.17 बताई गई
  • MiniMax M3 और Kimi K2.7 Code क्रमशः 23% और 22% पर रहे, GLM 5.2 से कम और Claude Code से भी पीछे
  • GLM 5.2 और अगले open-weight model के बीच gap 16 points था, जो GLM 5.2 और Claude Code के बीच gap से अधिक है

interpretation और limitations

  • सबसे बड़ा performance gap models के बीच के अंतर से ज्यादा endpoint discovery harness पाने और न पाने वाली configurations के बीच दिखा
  • इस experiment में harness, model selection जितना ही बड़ा factor साबित हुआ
  • साथ ही GLM 5.2 ने minimal prompt और simple harness conditions में, frontier LLM की लगभग 1/6 cost पर, कठिन security research task में Claude Code को पीछे छोड़ा
  • open-weight models अपने environment में चलाए जा सकते हैं, इसलिए कुछ security teams के लिए ये practical विकल्प हो सकते हैं
  • नतीजों की स्पष्ट limitations हैं
    • एक task
    • एक dataset
    • एक run
    • IDOR detection nondeterministic है
    • dataset finite है
    • SSRF detection में नतीजे उलट सकते हैं और अभी इसकी पुष्टि नहीं हुई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • Fable और GPT 5.6 वाले हंगामे के बाद मैंने open models को फिर से देखा, और GLM-5.2 रोज़मर्रा की programming के लिए सच में बहुत अच्छा, practical model है
    LLMs बहुत इस्तेमाल करने वाले एक अनुभवी developer के तौर पर, एक GPT session आम तौर पर 100 डॉलर से ऊपर चला जाता है; इस weekend मैंने encryption वाला Matrix bot और कुछ tools से लैस Rust agent बनाया, और दो दिन बाद 20 डॉलर खर्च करने पर homelab तक access कर सकने वाला multimodal Rust agent तैयार था
    GLM में कोई अटपटा एहसास नहीं था, उसने मनचाहा काम अच्छी तरह किया, तेज़ था, उसका “personality” भी ज़्यादा खटकने वाला नहीं था, और Opus या GPT से कहीं सस्ता था। मैंने Fireworks पर unquantized version इस्तेमाल किया, और कई दूसरे providers भी हैं

    • GLM 5.2 शानदार है, लेकिन अगर आप “सिर्फ सबसे अच्छा model इस्तेमाल करूंगा” वाली जगह पर हैं, तो यह अभी वहाँ नहीं है
      सभी labs, चाहे जानबूझकर या अनजाने में, benchmark answers याद कर चुके models निकाल रही हैं; Chinese lab models में public benchmarks और internal evaluations के बीच gap ज़्यादा रहा है, और internal evaluations को benchmark optimization के प्रति कम vulnerable बनाने के लिए design किया गया था
      multi-agent coding environment में GLM 5.2 औसतन Opus 4.6 से थोड़ा पीछे है। Data https://gertlabs.com/rankings पर है
      हालांकि performance बनाम cost को साथ देखें तो GLM 5.2 एक frontier model है
    • मुझे सच में हैरानी है कि API fees क्यों दी जाती हैं। Claude usage के हिसाब से मैं महीने में API पर हजारों डॉलर का उपयोग करता हूं, लेकिन असल में सिर्फ 100 डॉलर subscription fee देता हूं
    • अगर आप Matrix इस्तेमाल करते हैं, तो अगर अभी तक नहीं आज़माया है तो harness के रूप में Hermes पर विचार कर सकते हैं। इसमें native gateway support है, और मैंने इसे मुख्यतः Element के जरिए इस्तेमाल किया है; कुल मिलाकर यह बहुत अच्छा रहा
    • क्या पक्का है कि Fireworks सच में unquantized है? OpenRouter पर दूसरी जगहों की तरह precision दिखाई नहीं देती
    • जानना चाहूंगा कि 20 डॉलर API fee थी या subscription fee

  • GLM 5.2 आने पर मैंने इसे security bug hunting benchmark में जोड़ा; performance अच्छी थी, लेकिन यह सबसे अच्छा open model नहीं था
    यह benchmark test करता है कि model Mythos द्वारा ढूंढे गए bugs खोज सकता है या नहीं। शुरुआती results में सबसे अच्छा open model DeepSeek V4 Pro या MiMo 2.5 Pro था, लेकिन MiMo शायद lucky रहा था और बाद के लगभग सभी tests में उससे खराब रहा। दूसरी ओर DeepSeek लगातार top tier में रहा, और extreme caching performance की वजह से बहुत छोटे models सहित लगभग किसी भी चीज़ से सस्ता है
    https://swelljoe.com/post/will-it-mythos/
    एक और दिलचस्प बात यह है कि open source semgrep को tool के रूप में देने पर कुछ models और खराब हो गए, और कोई भी model बेहतर नहीं हुआ। शायद harness को इस तरह अच्छी तरह जोड़ने का तरीका हो कि model को semgrep सीधे handle न करना पड़े और सिर्फ उपयोगी जानकारी मिले
    मेरा अनुमान है कि semgrep training data में बहुत ज़्यादा नहीं है, इसलिए model को semgrep इस्तेमाल करना समझने और security bugs खोजने—दोनों काम एक साथ करने पड़ते हैं, जिससे focus बंट जाता है और दोनों में performance गिरती है। ज़्यादातर छोटे models और कुछ बड़े models इसे अच्छे से नहीं कर पाते
    अतिरिक्त testing जारी है, और GLM 5.2 के लगातार मजबूत performance देने की संभावना अच्छी लगती है। अब तक किए गए ज़्यादातर tests में यह शानदार रहा है

  • कहा जा रहा है कि GLM 5.2 753B parameters वाला model है [1]; इसे local चलाने के लिए लोग कौन-सा hardware इस्तेमाल करते हैं, यह जानना चाहूंगा
    [1] https://huggingface.co/zai-org/GLM-5.2

    • मैंने इसे Lenovo Legion 5i laptop पर चलाकर देखा। लगभग RAM 32GB, VRAM 8GB वाला 4060 config है
      1TB NVMe में भी यह वैसा का वैसा fit नहीं हुआ, इसलिए weights के लिए 4-bit वाला UD_Q4_K_XL quantized model इस्तेमाल किया, और speed tokens per second नहीं बल्कि करीब 12 seconds per token थी। मज़ेदार project था, लेकिन इस्तेमाल लायक नहीं था
      llama.cpp memory mapping support करता है, इसलिए context cache 4096 tokens के साथ चलाया; पूरा model RAM में नहीं आ सकता, तो मैं जानना चाहता था कि SSD से कितना stream करना पड़ेगा। 4 वाक्यों की एक simple self-introduction generate करने में disk से लगभग 1.5TiB पढ़ा गया
    • quantized version चला सकते हैं। https://unsloth.ai/docs/models/glm-5.2
    • antirez को देखें। https://x.com/antirez/status/2071173841175363905?s=20
    • 8 RTX6000 काफी होंगी। इस size के model को ठीक-ठाक tokens per second से शुरू करने के लिए लगभग 80,000–100,000 डॉलर लगेंगे
      फिर भी चिंता की बात नहीं। open source evangelists आपको बता देंगे कि 3 साल में ऐसे models phone पर चलेंगे
      100,000 डॉलर में OpenRouter के जरिए इस model को 50tps, 10 concurrent sessions के साथ 10 साल तक 24/7 चला सकते हैं, और फिर भी छुट्टी पर जाने के पैसे बचेंगे। अगर आप पहले से कई employees के individual token usage के लिए भुगतान करने वाला business नहीं हैं, तो local model में इतना पैसा लगाने की कोई वजह नहीं

  • “एक vulnerability खोजने में करीब 0.17 डॉलर में Claude Code(32%) को हराया” कहना inaccurate है
    Claude Code कोई LLM नहीं, बल्कि agent harness है, और Claude कोई एक LLM नहीं बल्कि brand या LLMs का bundle है

    • दूसरे models की price list के बिना वह dollar figure meaningful नहीं है। लेख ढीला-ढाला है
    • लेखक भी यह बात अच्छी तरह जानता होगा। फिर भी इस छोटी गलती को पकड़ने के लिए धन्यवाद
    • बारीकियों पर nitpick न करने में कोई खर्च नहीं लगता
    • Claude Code शायद Claude-class models चलाने की वास्तविक amortized cost तक पहुंचने का इकलौता तरीका है
      consumer non-enterprise API users के लिए marginal cost ज़्यादा और Anthropic के लिए margin मोटा होने के कारण बहुत महंगा है। अगर किसी nation-state attacker के अपने hardware पर model चलाने की cost का approximation चाहिए, तो Claude Code amortized cost का सबसे अच्छा estimate हो सकता है

  • ये आंकड़े, खासकर Windows kernel और win32k↔win32u की तरफ, मैंने जो हासिल किया है उसकी तुलना में काफी कम लगते हैं
    अब अगर China cyber जैसी कुछ खास categories में America के public models से आगे निकलना शुरू कर दे, तो शायद हैरानी नहीं होगी
    GLM 5.2 पहले से ही अपनी training में मदद करने लायक काफी powerful है, और यह frontier models में दिखे trend जैसा ही है। ऊपर से, लगता है कि यह OpenAI या Anthropic से कहीं कम cost पर वहां पहुंच रहा है

    • Trump America के “allies” को जो models allow करेंगे, वे लगभग निश्चित रूप से पीछे छूट जाएंगे। लगता है वे allies को असल में dependent states की तरह देखते हैं
      इसमें China की solar power, rechargeable batteries, electric vehicles में बढ़ती dominance जोड़ दें, तो यह द्वितीय विश्व युद्ध के बाद की economic order पर decisive blow हो सकता है

  • Opus को भी कम-से-कम उसी Pydantic harness पर चलाना चाहिए जो GLM के लिए इस्तेमाल किया गया। अभी की स्थिति में यह apples और oranges की तुलना जैसा है
    GLM के अलावा बाकी सभी models के लिए cost per vulnerability कहां है?
    code न हो तो भरोसा करना भी मुश्किल है। यह सब मनगढ़ंत भी हो सकता है

  • क्या GLM export controls जल्द आने वाले हैं? मुझे उम्मीद है कि कुछ महीनों में Commerce, OpenRouter और HuggingFace को कुछ open models हटाने के लिए मजबूर करेगा
    यह समझदारी भरा नहीं होगा, फिर भी

    • अगर ऐसा हुआ तो यह पूरी तरह disaster होगा। सोचिए, Anthropic और OpenAI safety के नाम पर अपने latest models को ज्यादातर American companies के इस्तेमाल से रोक रहे हों, और attackers उसी स्तर के open-source models से American companies पर attack कर रहे हों
      open-source models पर ban लगाने से problem solve करने में कोई मदद नहीं मिलती। attackers खुद को कानून से बंधा हुआ महसूस नहीं करते। defense के लिए सभी advanced models accessible होने चाहिए
    • America, America के अंदर Chinese models के use पर ban लगा सकता होगा। लेकिन Chinese cars पर ban की तरह, बाकी दुनिया उन्हें बस इस्तेमाल करेगी
    • चाहें भी तो इसे संभव बनाने वाला legal basis ढूंढना मुश्किल लगता है
      government के पास (a) American goods/services के export को रोकने, (b) physical goods के import पर ban लगाने, और (c) foreign companies के साथ transactions, जिनमें services खरीदना या license agreements शामिल हैं, पर ban लगाने का अधिकार है
      लेकिन अगर कोई American company supplier से independent relationship में है, और इसे government contracts या regulated applications में भी इस्तेमाल नहीं कर रही, तो America के अंदर China-developed open-source AI model चलाने की action को ही ban करने का legal authority क्या होगा, यह मुझे साफ नहीं दिखता
      HuggingFace वगैरह को Chinese accounts suspend करने का order देने की संभावना है। लेकिन अगर America या किसी third country का कोई व्यक्ति China से model download करके, supplier से पूरी तरह independent तरीके से उसे American server पर फिर से upload करे, तो उसे ban करने वाला legal link कहां है, यह सवाल है
    • मतलब America Chinese-made models पर export restrictions लगाएगा?
    • आगे चलकर cutting-edge AI शायद defense industry के लिए ही reserved हो जाएगी। जैसे हमारे पास toy drones हो सकते हैं, लेकिन Predator और Reaper नहीं

  • Neuralwatt के जरिए GLM 5.2 इस्तेमाल कर रहा हूं और यह इतना सस्ता हो गया है कि अगर company Claude subscription दे दे, तो शायद अपना personal Claude subscription cancel कर देना ठीक लगेगा
    इस महीने मैंने 374 million tokens इस्तेमाल किए, लेकिन energy-based pricing से सिर्फ 18 dollars लगे

  • advertisement जैसा पढ़ता है
    दूसरी बात, ये “सिर्फ” IDOR हैं और vulnerability types में सबसे आसान category में आते हैं
    तीसरी बात, इसकी तुलना GPT 5.5 और Opus 4.8 से की जा रही है
    नहीं, हमारे घर में Mythos नहीं है

    • Mythos हर benchmark में GPT 5.5 से 10% से कम आगे है, और वह अंतर इसलिए है क्योंकि यह Opus से कई गुना बड़ा है
      अगर इसे economically provide किया जा सकता, तो effective altruism clowns के marketing circus के बजाय पहले दिन से ही public कर दिया जाता। 10% से कम बेहतर model की inference cost 1000% से ज्यादा है—यह बात मानना बहुत damaging होता
    • मेरे experience में GLM 5.2 vulnerabilities खोजने में बहुत अच्छा है, और उससे भी important बात यह है कि Opus के उलट, मैंने इसे instructions refuse करते नहीं देखा
      vulnerabilities खोजने और fix करने के लिए यह सच में powerful model है
    • फिर भी यह useful है। आजकल के अंदाज में कहें तो GLM 5.2 आज हमारे साथ उसी कमरे में है, लेकिन Mythos नहीं है
      EU में होने के नाते स्थिति और complicated है। Mythos कभी कमरे में आ भी जाए, तो किसी ऐसे political actor की सनक से अचानक गायब हो सकता है जिस पर हमारा कोई control नहीं
      accessible और locally चल सकने वाले open models कहां तक पहुंच गए हैं, यह जानना important है। पता है कि वे पीछे हैं। लेकिन एक समय आता है जब “good enough” useful हो जाता है। आज यह “सिर्फ IDOR” है और state-of-the-art से पीछे है, तब भी यही बात लागू होती है
      ऊपर किसी ने कहा था कि GLM 5.2 और उसी class के Kimi, DeepSeek V4 जैसे models automated repository preparation work—यानी download, install, test, fix, retest—में मदद करने के लिए increasingly sufficient हो रहे हैं। इससे real-world trace data मिलता है जिसे अगली generation की training में इस्तेमाल किया जा सकता है। benchmark में कुछ percent पीछे होना इससे कम important हो सकता है
    • strictly speaking, क्या हमारे पास Mythos है ही नहीं? access सिर्फ उस तरफ है। इससे लगता है कि हमारे पास घर पर इस्तेमाल करने वाला Opus, यानी open weights, है
    • वे साफ-साफ कह रहे हैं कि उनका benchmark narrow है और मुख्य रूप से उनके specific use case के लिए important है। फिर भी rationality को pitchforks नीचे रखने पर मजबूर नहीं करने देना चाहिए!