AI साइबरसुरक्षा की नई सीमा: Mythos के बाद की वास्तविकता

 (aisle.com)
2 पॉइंट द्वारा GN⁺ 20 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Anthropic के Claude Mythos द्वारा बड़े पैमाने पर zero-day vulnerabilities का स्वचालित पता लगाने के बाद, छोटे open models ने भी उन्हीं vulnerabilities को सफलतापूर्वक खोज लिया
  • 3.6B~5.1B parameter वाले models ने FreeBSD·OpenBSD bugs को पुन: प्रस्तुत किया, और कुछ ने Mythos से अलग रचनात्मक exploit paths भी सुझाए
  • प्रयोगों से पता चला कि model size और performance का संबंध non-linear है, और कुछ tasks में छोटे models बड़े models से अधिक सटीक निकले
  • AI security capability सुचारु रूप से scale नहीं होती, बल्कि ‘jagged’ होती है, और वास्तविक प्रतिस्पर्धात्मक बढ़त model में नहीं बल्कि system design और validation pipeline में है
  • इसलिए security moat model नहीं बल्कि system है, और expert knowledge से युक्त orchestration structure AI security का मुख्य तत्व है

System ही moat है, model नहीं

  • 7 अप्रैल 2026 को Anthropic ने Claude Mythos Preview और Project Glasswing की घोषणा की, और Mythos model का उपयोग करके प्रमुख software की security vulnerabilities को स्वचालित रूप से खोजने और patch करने के लिए एक consortium बनाया
    • $100 million के usage credits और open-source security organizations के लिए $4 million donation का वादा किया
    • Mythos ने हजारों zero-day vulnerabilities खोजीं, और OpenBSD का 27 साल पुराना bug, FFmpeg का 16 साल पुराना bug, FreeBSD remote code execution vulnerability आदि को स्वायत्त रूप से खोजकर उनके exploits भी बनाए
  • AISLE ने इन्हीं vulnerabilities को छोटे, सस्ते, open-weight models के साथ पुन: प्रस्तुत किया
    • 8 में से 8 models ने FreeBSD exploit का पता लगाया
    • 3.6B parameter model (प्रति token $0.11) ने भी detection में सफलता पाई
    • 5.1B model ने OpenBSD bug की मुख्य chain को पुनर्निर्मित किया
    • कुछ tasks में छोटे open models बड़े models से बेहतर रहे
  • नतीजतन AI security capability non-linear और jagged है
    • कोई एक model सभी tasks में श्रेष्ठ नहीं है
    • security competitiveness का केंद्र model नहीं बल्कि system है, और expert knowledge से युक्त orchestration structure इसका आधार है

AI security की वर्तमान स्थिति

  • AISLE ने 2025 के मध्य से AI-आधारित vulnerability detection·patching systems को वास्तविक targets पर लागू करना शुरू किया
    • OpenSSL में 15 CVEs, curl में 5, और कुल मिलाकर 180 से अधिक externally validated CVEs खोजे
    • OpenSSL CTO ने कहा कि “report quality और collaboration process उत्कृष्ट है”
  • अलग-अलग models का उपयोग किया गया, लेकिन Anthropic models हमेशा सर्वश्रेष्ठ नहीं रहे
    • task के अनुसार optimal model बदलता रहा, इसलिए model-agnostic approach अपनाई गई

AI security pipeline का विभाजन

  • वास्तविक AI security किसी एक model से नहीं, बल्कि multi-stage pipeline से बनती है
    • wide scanning, vulnerability detection, validation and classification, patch generation, exploit construction जैसे चरणों की scaling characteristics अलग-अलग होती हैं
  • Anthropic पहले input factor, यानी model intelligence, को अधिकतम करता है, जबकि AISLE per-token cost, speed, और security expertise जैसे कई तत्वों को समान महत्व देता है

निष्कर्ष: moat system है

  • Mythos के technical post में बताए गए container execution, file scanning, ASan validation, priority scoring जैसी संरचनाएँ AISLE system से मिलती-जुलती हैं
  • value का केंद्र model नहीं बल्कि targeting, validation, और trust-building process है
  • छोटे models को बड़े पैमाने पर parallel deployment में लगाकर पूरे codebase को व्यापक रूप से खंगालने का तरीका economic efficiency और detection efficiency दोनों देता है
  • Mythos ने category को सिद्ध किया, लेकिन operational scale और reliability हासिल करना अभी भी चुनौती है

प्रयोगों के परिणाम: jagged security capability

  • Mythos announcement में दिखाए गए प्रतिनिधि vulnerabilities पर छोटे, कम-लागत models के साथ प्रयोग किए गए

    • FreeBSD NFS bug, OpenBSD SACK bug, OWASP false-positive test

      • परिणामस्वरूप model size, generation, price, और performance का संबंध non-linear निकला
      • FreeBSD detection में सभी models सफल रहे, OpenBSD में केवल कुछ, और OWASP में छोटे models बड़े models से अधिक सटीक रहे
      • FreeBSD detection: सभी 8 models ने buffer overflow का पता लगाया
      • 3.6B model ने भी सटीक गणना करके RCE संभावना का आकलन किया
      • DeepSeek R1 ने वास्तविक stack structure से मेल खाती गणना की
      • exploit logic में भी सभी models ने ROP chain strategy सुझाई
      • कुछ models ने Mythos से अलग रचनात्मक समाधान दिए, जैसे kernel mode के बजाय user mode में privilege escalation
      • OpenBSD SACK bug: 5.1B model ने पूरी chain को पुनर्निर्मित किया और सही patch भी सुझाया
      • Qwen3 32B FreeBSD में तो परफेक्ट था, लेकिन यहाँ उसने गलत रूप से “safe” कहा
      • हर task में models की performance ranking पूरी तरह उलट गई

  • OWASP false-positive test: साधारण Java code में छोटे models बड़े models से अधिक सटीक

    • GPT-OSS-20b, DeepSeek R1, OpenAI o3 ने सही रूप से निर्णय दिया: “अभी सुरक्षित है, लेकिन vulnerable हो सकता है”
    • कई Anthropic और GPT-4.x series models ने गलत SQL injection detection किया

Patch recognition test (9 अप्रैल 2026 update)

  • FreeBSD के patched version code पर bug detection और fix recognition capability की तुलना की गई
    • सभी models ने unpatched bug को खोज लिया, लेकिन patched code में कई false positives आए
    • केवल GPT-OSS-120b दोनों दिशाओं में सही निकला
    • अधिकांश models ने oa_length sign interpretation error के कारण गलत vulnerability claim किया
  • इससे पता चलता है कि sensitivity (detection power) तो ऊँची है, लेकिन specificity (accuracy) कम है,
    और model के बाहर validation·triage system आवश्यक है

Exploit construction की सीमाएँ

  • Mythos के multi-stage browser sandbox escape, kernel ROP chain जैसे मामले बहुत उन्नत उदाहरण हैं
  • open models exploitability, techniques, और bypass strategies को तार्किक रूप से समझाते हैं, लेकिन
    सीमित environments में रचनात्मक delivery mechanisms अभी भी कमजोर हैं
  • लेकिन defensive workflows में पूर्ण exploit की तुलना में detection और patch reliability अधिक महत्वपूर्ण है

व्यापक दृष्टिकोण

  • Mythos की घोषणा ने AI security की वास्तविक उपयोगिता और औद्योगिक महत्व को सिद्ध किया
    • open-source security के लिए funding और attention बढ़ी
  • लेकिन यह दावा कि “यह capability केवल किसी specific closed model में ही मौजूद है” बढ़ा-चढ़ाकर कहा गया है
    • वास्तव में detection और analysis stage पहले से ही व्यापक रूप से सुलभ हैं
    • security expertise, system design, और trust-building ही असली bottleneck हैं

  • अभी ज़रूरत model की नहीं बल्कि system निर्माण की है

    • scaffolds, pipelines, collaboration structures, development workflow integration
    • models पहले से ही पर्याप्त रूप से तैयार हैं

सीमाएँ और सावधानियाँ

  • test scope सीमित: models को vulnerable functions और hints सीधे दिए गए, यह पूरी तरह autonomous exploration नहीं था
  • tool access नहीं: code execution, loops, या sandbox environments का उपयोग नहीं किया गया
  • model updates परिलक्षित: बाद के कुछ नए Anthropic models में सुधार हुआ
  • claim scope स्पष्ट: यह Mythos की capability को नकारता नहीं,
    बल्कि यह बताता है कि detection capability की exclusivity बढ़ा-चढ़ाकर पेश की गई

परिशिष्ट सारांश

  • FreeBSD detection उद्धरण

    • Kimi K2: “oa_length validation के बिना copy हो रहा है, इसलिए overflow संभव है”
    • Gemma 4: “128-byte stack buffer से अधिक होने की संभावना”

  • task-wise performance comparison table

    • FreeBSD detection में सभी models सफल, OpenBSD में केवल कुछ सफल, OWASP में छोटे models आगे

  • patched code test

    • अधिकांश models ने oa_length sign error के कारण false positives दिए
    • केवल GPT-OSS-120b पूरी तरह सटीक था
    • निष्कर्ष:
    • AI security की मुख्य प्रतिस्पर्धात्मक बढ़त model के size या exclusivity में नहीं,
    • बल्कि expert knowledge से युक्त systemic design और भरोसेमंद operational structure में है।
    • छोटे models भी पर्याप्त रूप से शक्तिशाली हैं, और इनके आधार पर बड़े पैमाने की automated defensive systems बनाना पहले से संभव है।

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

1 टिप्पणियां

 
GN⁺ 20 일 전
Hacker News की राय

  • Anthropic की Mythos Preview पोस्ट के अनुसार, इसने OpenBSD में सबसे गंभीर vulnerability खोजी
    हज़ार runs में कुल लागत 20,000 डॉलर से कम थी, और उनमें से एक run ने 50 डॉलर से कम में bug ढूंढ लिया
    लेकिन यह केवल बाद में देखने पर अर्थपूर्ण संख्या है, और वास्तव में यह पहले से पता नहीं होता कि कौन-सा run सफल होगा
    Mythos के पूरे महाद्वीप को सोने की खान की तरह खंगालने वाली उपमा देते हुए, अनुमान लगाया गया कि FreeBSD के पूरे codebase पर यही प्रयोग करने पर noise बहुत ज़्यादा हो जाएगा

    • Mythos का scaffolding मूल रूप से bash loop से सभी files पर घूमते हुए model से vulnerabilities ढूंढवाने का तरीका था
      जिज्ञासा है कि क्या Anthropic ने false positive rate सार्वजनिक की थी
      Xitter पर दूसरे open models के साथ प्रयोग करने वाले लोगों ने कहा कि वे Mythos द्वारा मिली चीज़ों का केवल कुछ हिस्सा ही reproduce कर पाए
      लगता है Mythos ने मौजूदा models की तुलना में क्रमिक लेकिन बड़ा सुधार दिखाया, और साथ ही जटिलता भी बढ़ी
      “इतना शक्तिशाली कि जारी नहीं कर सकते” जैसी marketing दरअसल “पूरे codebase पर चलाने में 20,000 डॉलर लगते हैं” वाली वास्तविकता को पैक करने जैसा लगता है
      Nicholas Carlini की talk में भी Opus का उपयोग हुआ था, और security तो वैसे भी Anthropic का लंबे समय से focus area रहा है
    • Mythos ने बकवास vulnerabilities भी बहुत बनाई, लेकिन उनमें से कुछ को वास्तव में testing से verify किया गया
      असली सवाल यह है कि क्या छोटे models भी ऐसे verification steps कर सकते हैं, और क्या यह उससे सस्ता हो सकता है
    • इसके उलट, दूसरी research को बहुत चरम दृष्टिकोण वाला माना गया
      उसमें सिर्फ vulnerable functions अलग करके model को दिए गए और उसी पर evaluation किया गया, जो “सोना छिपे कमरे का पता सीधे बता देने” जैसा है
      असल में पूरी महाद्वीप जैसी codebase में उस कमरे को ढूंढना ही ज़्यादा कठिन हिस्सा है
    • OpenBSD की एक DoS vulnerability ढूंढने पर 20,000 डॉलर खर्च करना अक्षम लगता है
      माहौल ऐसा है कि Mythos को trophy की तरह पेश किया जा रहा है, लेकिन बेहतर होता कि OpenBSD Foundation को दान दे दिया जाता
    • अगर वही vulnerability छोटे model से भी मिल सकती है, तो सवाल है कि उस कंपनी ने उसे पहले ही क्यों नहीं ढूंढ लिया

  • एक research में कहा गया कि छोटे open models ने Mythos की FreeBSD vulnerabilities में 8 में से 8 सभी detect कर लीं
    लेकिन क्योंकि testing में केवल संबंधित code को अलग करके दिया गया था, यह वास्तविक use case से अलग लगता है
    असली value तब है जब पूरे codebase को डालकर scan किया जा सके

    • research team ने खुद भी सीमाएँ मानीं
      क्योंकि model को vulnerable function और hints सीधे दिए गए थे, यह पूरी तरह autonomous search की upper bound भर है
      लेकिन अच्छी तरह डिज़ाइन किया गया scaffold ऐसा context अपने-आप बना सकता है, इसलिए मुख्य चीज़ system (moat) है, model नहीं
    • Anthropic की technical post के अनुसार, structure ऐसा था कि container चलाया जाता है, model files scan करता है, hypotheses बनाता है और ASan से verify करता है
      यानी framework (harness) ज़्यादातर काम करता है, और model को बदला जा सकता है — यही दावा है
    • छोटे model से भी हर file या function unit पर बार-बार prompts फेंकने वाला automatic harness बनाया जा सकता है
      फिर सिर्फ उन हिस्सों को बड़े model से दोबारा verify किया जाए जिन्हें लगातार vulnerability के रूप में flag किया गया हो
      आखिरकार महत्वपूर्ण चीज़ model नहीं बल्कि harness है
    • अंत में फ़र्क harness का ही है। मैं भी code को function unit में तोड़कर analysis agent में डालने वाला harness बना सकता हूँ

  • Heartbleed उदाहरण की तरह, अगर vulnerable code अलग से दिखा दिया जाए तो bug कोई भी ढूंढ सकता है
    लेकिन बड़े codebase में उस हिस्से को पहचानना ही असली कठिनाई है
    हैरानी है कि Aisle ने ऐसा लेख लिखा

    • यह भले promotional लेख हो, लेकिन HN पर ऊपर इसलिए गया क्योंकि इसने लोगों की “नया model भी कोई खास नहीं” वाली भावना को छेड़ दिया
    • बड़े projects पर काम करते समय, कभी-कभी थोड़ा विराम लेकर लौटने पर अपना ही लिखा code अव्यवस्थित लगने लगता है
      context बनाए रखने की कठिनाई bug की मूल वजहों में से एक है
    • इंसान repetitive और सूक्ष्म कामों में कमज़ोर होते हैं
      इसके विपरीत, machine बिना ऊबे लगातार code खंगाल सकती है
      “काफी सारी आँखें हों तो हर bug सतही हो जाता है” वाली कहावत वास्तविकता से मेल नहीं खाती
    • तो फिर “करीब से देखने” की प्रक्रिया को automate किया जा सकता है
      codebase में घूमते हुए LLM से बार-बार “अगर इस code में vulnerability है तो उसे ढूंढो” कहने वाला tool बनाया जा सकता है
      यानी tool (harness) ही LLM को ज़्यादा स्मार्ट बनाने की कुंजी है
    • यह problem solving और verification को गड़बड़ाने जैसा है
      यह वैसी उपमा है जैसे “अगर किसी ने पहले से factorization बता दी हो तो PKI तोड़ना आसान है”

  • लगता है इस लेख की methodology पूरी तरह गलत तुलना है
    vulnerable function और hints सीधे दे देना बिल्कुल अलग task है
    व्यवहार में, code chunks को बाँटकर छोटे models को देने से भी बड़े model के स्तर के results मिलना मुश्किल है
    मैंने साधारण shell script pipeline से Redis के बहुत bugs ढूंढे हैं
    कमजोर models से यह नहीं हुआ। खुद प्रयोग करके अंतर समझा जा सकता है
    और अगर छोटा model 80% ढूंढ भी ले, तो बाकी 20% के लिए ज़्यादा शक्तिशाली model चाहिए

    • Anthropic ने भी कहा कि उसने मिली vulnerabilities में से 1% से कम ही प्रकाशित कीं
      अच्छा होगा अगर open models को पुराना Linux environment देकर देखा जाए कि वे कितना ढूंढ पाते हैं
    • लेकिन किसी और के अनुसार यह approach उचित है
      छोटे models ने false positives को अच्छी तरह फ़िल्टर किया, और उपयुक्त harness के साथ वे बड़े model जैसे results दे सकते हैं
      छोटे models तेज़ और सस्ते होते हैं, इसलिए skilled user के हाथ में वे काफ़ी अधिक efficient होते हैं
      आगे चलकर ऐसे lightweight model + harness संयोजन मुख्यधारा बन सकते हैं
    • किसी ने व्यंग्य में “Thanks Dario, very cool!” भी कहा

  • बहुत-सी टिप्पणियाँ कहती हैं कि “code को अलग किया गया, इसलिए यह अमान्य है”, लेकिन Anthropic ने भी इसी तरह file unit पर models चलाए थे
    Mythos का harness हर file को importance score देता था, और फिर उसी file पर ध्यान देने के लिए Claude Code instance बनाता था
    इसलिए code को अलग करना अपने-आप में परिणाम को अमान्य नहीं बनाता

  • Nicholas Carlini के presentation video में भी यही तकनीक दिखाई गई
    LLM से एक बार में एक file पर गहराई से review करवाने पर असर अच्छा होता है
    Mythos का “innovation” दरअसल यह साधारण file-wise prompt automation था
    संभव है कि इसी वजह से लागत 20,000 डॉलर तक गई हो
    मैंने भी Opus 4.6 और GPT 5.4 के साथ यही तरीका आज़माया, और उन्होंने कहीं ज़्यादा thorough review किया
    यानी जब एक session को एक file पर केंद्रित किया जाता है, तो model बहुत अधिक गहराई से analyze करता है

    • लेकिन इससे files के बीच interaction से पैदा होने वाली vulnerabilities छूट सकती हैं

  • “छोटे model ने वही analysis पुनर्निर्मित कर लिया” जैसी अभिव्यक्ति मात्रात्मक नहीं है, इसलिए इस पर भरोसा करना मुश्किल है
    vulnerability verification को PoC से स्पष्ट रूप से मापा जा सकता है, इसलिए ऐसे प्रमाण की ज़रूरत है
    और “संबंधित code पहले से देना” निष्पक्ष तुलना नहीं है

  • अगर false positive rate प्रकाशित न की जाए तो analysis अर्थहीन है
    अगर हर line पर bug होने की बात कह दी जाए तो detection rate 100% होगा, लेकिन उसका कोई उपयोग नहीं
    Anthropic और OpenAI भी ऐसे आँकड़े प्रकाशित नहीं करते, इसलिए भरोसा करना कठिन है

    • लेकिन यह प्रतिवाद भी था कि अगर verify करने लायक oracle हो, तो false positives को नज़रअंदाज़ किया जा सकता है
    • वास्तव में छोटे model ने false positive test में सही उत्तर दिए, जबकि Opus गलत था
      हालाँकि वह Mythos स्तर की exploit verification तक नहीं पहुँच पाया
      Deepseek R1 के results काफ़ी भरोसेमंद लगे, लेकिन वे सच में काम करते थे या नहीं, यह स्पष्ट नहीं था
    • कम-से-कम Anthropic ने जो coverage हासिल की, उतना तो समान रूप से पाना ही चाहिए तभी बात मायने रखती है

  • असली बिंदु यह है कि संबंधित code को अलग किया गया
    जटिल zero-day अक्सर कई files के interaction से बनते हैं, इसलिए इस approach की सीमाएँ हैं

    • लेकिन कुछ लोगों का दावा है कि Mythos ने भी अंततः यही file-wise analysis approach अपनाई थी
    • यह स्पष्ट नहीं है कि Mythos ने वास्तव में cross-file vulnerabilities ढूंढीं या नहीं

  • Mythos ने पूरे codebase का मूल्यांकन किया, जबकि इस research ने केवल vulnerable code को अलग करके test किया
    यह “जंगल में गेंद ढूंढने वाले कुत्ते” और “कुत्ते को सिर्फ वह इलाका बता देने जहाँ गेंद है” के अंतर जैसा है

    • यहाँ तक कहा गया कि गेंद पर गंध लगाकर, कुत्ते को वह गंध सुंघाकर, फिर उसे एक छोटे इलाके में छोड़ देने जैसा मामला था
    • Mythos पूरे code को एक साथ नहीं डाल सकता, इसलिए संभव है कि कई sub-agents ने बाँटकर काम किया हो
      अंततः महत्वपूर्ण चीज़ model नहीं बल्कि harness (tooling system) है