एआई भेद्यता खोज विश्लेषण: VulnCheck स्पीड चेक

रोबोट बग शिकारी ज़रूरी नहीं कि दरवाज़ा तोड़कर अंदर घुस रहा हो। हो सकता है वह बस vulnerability management की घंटी तब तक बजा रहा हो जब तक बैटरी खत्म न हो जाए। VulnCheck के Patrick Garrity प्रमुख सॉफ़्टवेयर सप्लायरों में CVE disclosure volume में तेज़ बढ़ोतरी की रिपोर्ट करते हैं, और यह बिल्कुल वैसा चार्ट है जिसे देखकर security teams चुपचाप दूसरी कॉफी खोल लेती हैं। दिलचस्प बात यह है कि डेटा अभी क्या साबित नहीं करता: कि AI द्वारा खोजी गई flaws पारंपरिक flaws की तुलना में तेज़ी से exploit हो रही हैं। यह फर्क मायने रखता है, क्योंकि AI security पर बातचीत में उतनी ही बारीकी होती है जितनी किसी लाइब्रेरी में leaf blower की। Discovery volume और exploitation speed जुड़े हुए हैं, लेकिन वे एक ही मशीन नहीं हैं। एक queue भरता है। दूसरा तय करता है कि queue में आग लगेगी या नहीं।

VulnCheck: CVE firehose कुछ ज़्यादा ही पानीदार हो गया

VulnCheck रिपोर्ट करता है कि कई सप्लायरों में year to date CVE disclosure volumes तेज़ी से बढ़े हैं, जिनमें Chrome +563.2%, VMware +180.9%, Apache +170.3%, Mozilla +156.9%, HPE +132.3%, और F5 +113.8% पर शामिल हैं। VulnCheck यह भी कहता है कि GitHub CVE issuance year to date +476.07% बढ़ा है, और GitHub के अनुसार यह बढ़ोतरी किसी एक source में केंद्रित होने के बजाय कई reporters और projects में फैली हुई है। यह एक महत्वपूर्ण clue है, क्योंकि pattern किसी एक heroic bug goblin जैसा कम और broad tooling effect जैसा ज़्यादा दिखता है।

VulnCheck causality को लेकर सावधान है, जो ऐसी industry में ताज़गी भरा है जहाँ अगर किसी toaster के पास YAML file हो तो उसे agentic label किया जा सकता है। firm कहती है कि increases AI assisted vulnerability discovery के व्यापक उपयोग से consistent हैं, लेकिन signal अभी भी उभर रहा है और सभी increases को सीधे AI से attributed नहीं किया जा सकता। यह Mozilla, Microsoft, Apache, Curl, और Palo Alto के public examples की ओर भी इशारा करता है, जहाँ AI models का उपयोग vulnerabilities खोजने, validate करने, या triage करने के लिए किया जा रहा है, और results project के हिसाब से mixed हैं।

व्यावहारिक takeaway यह नहीं है कि machine एक perfect auditor बन गई है। बात यह है कि code को poke करने की marginal cost घट रही है, और pokes की संख्या बढ़ती दिख रही है। इसे ऐसे समझें: fuzzing के साथ एक junior analyst जो कभी सोता नहीं, कभी-कभी hallucinate करता है, और जिसे अब भी किसी senior की ज़रूरत है जो विनम्रता से पूछे कि finding reproduce होती है या नहीं।

Cloud Security Alliance: exploit automation वास्तविक है, लेकिन buckets मत मिलाइए

Cloud Security Alliance अपने AI Safety Initiative paper में तर्क देता है कि broader exploit window compress हो रही है। CSA के अनुसार, disclosed vulnerability के लिए mean time to exploit 2022 में लगभग 32 दिनों से घटकर 2023 exploitation activity के लिए लगभग 5 दिन रह गया, और 2025 data ने दिखाया कि newly tracked exploits में से 32.1% CVE की public disclosure date पर या उससे पहले दिखाई दिए। CSA यह भी कहता है कि AI systems published CVEs के लिए working proof of concept exploit code लगभग 10 से 15 मिनट में, प्रति attempt लगभग एक dollar की लागत पर generate कर सकते हैं। ये गंभीर claims हैं, और defenders को इन्हें bedtime reading के तहत file नहीं करना चाहिए, जब तक कि उन्हें region outage के दौरान Kubernetes cluster की तरह सोना पसंद न हो।

लेकिन वे VulnCheck की disclosure volume analysis से अलग सवाल का जवाब देते हैं। CSA published CVEs के आसपास broad weaponization pressure का वर्णन कर रहा है, जबकि VulnCheck AI assisted discovery से consistent disclosure volumes में rise flag कर रहा है। यह साबित करने के लिए कि AI discovered flaws खुद exploitation की ओर तेज़ी से बढ़ते हैं, provenance aware telemetry चाहिए जो साफ़-साफ़ अलग करे कि bug कैसे मिला और attackers ने बाद में कैसा व्यवहार किया।

CSA का CVE-Genie example बात को और स्पष्ट करता है। paper कहता है कि multi agent framework ने 2024 और 2025 में published सभी CVEs में से 51% को verifiable exploits के साथ reproduce किया, औसतन $2.77 प्रति CVE की लागत पर। इससे संकेत मिलता है कि exploit validation सस्ता हो सकता है, लेकिन इसका मतलब अपने-आप यह नहीं है कि हर AI found bug तेज़ real world intrusion बन जाता है। Automation lab को accelerate कर सकता है, street map को rewrite किए बिना।

VulnCheck और CSA मिलकर triage समस्या की ओर इशारा करते हैं

VulnCheck और CSA को साथ-साथ पढ़ें, और defender lesson लगभग चिढ़ाने वाली हद तक practical है: AI का पहला impact backlog inflation हो सकता है, जबकि speed story uneven और context dependent रहती है। VulnCheck स्पष्ट रूप से कहता है कि यह कम clear है कि disclosure volume increases sustained रहेंगे या यह temporary surge है क्योंकि frontier AI models को अलग-अलग code पर apply किया जा रहा है। यह uncertainty कोई shrug नहीं है। यह planning input है।

Security teams को AI assisted findings को किसी भी अन्य high volume signal source की तरह treat करना चाहिए: reproducibility demand करें, findings को exposed assets से map करें, exploitability verify करें, और operational blast radius के आधार पर prioritize करें। अगर किसी report में working repro, affected version clarity, या impact तक credible path नहीं है, तो उसे सिर्फ इसलिए किसी boring known exploited issue से ऊपर rank नहीं करना चाहिए क्योंकि उसे खोजते समय AI ने lab coat पहन रखा था। model एक metal detector है, judge नहीं।

CSA का compression data अब भी faster patch decision loops के पक्ष में तर्क देता है, खासकर जब कोई CVE public हो जाए और exploit code test करना सस्ता हो जाए। लेकिन VulnCheck का data हर AI touched CVE को heap के top पर panic sorting करने के खिलाफ तर्क देता है। समझदार posture है provenance aware triage: record करें कि AI ने bug को find, validate, या triage करने में मदद की या नहीं, लेकिन patch call exposure, exploit evidence, affected assets, और confidence पर करें।

आगे क्या देखना है

अगला useful signal कोई और press release नहीं होगा जिसमें दावा हो कि robot ने bug ढूँढ लिया। वह datasets होंगे जो discovery provenance, disclosure quality, exploit availability, और real exploitation timing को connect करें। अगर AI assisted discovery CVE volume बढ़ाता रहता है बिना उन्हीं flaws के लिए exploitation speed में matching, measurable increase के, तो defenders को louder sirens से ज़्यादा better intake automation की ज़रूरत होगी।

Builders के लिए, यह vulnerability management को कम theatrical और ज़्यादा measurable बनाने का निमंत्रण है। discovery method के लिए fields जोड़ें। false positives track करें। validation को exploitability से अलग करें। bug pile ऊँचा होता जा रहा है, लेकिन जवाब pile की पूजा करना नहीं है। जवाब है एक बेहतर shovel बनाना, बेहतर होगा ऐसा जो critical severity rating hallucinate न करे सिर्फ इसलिए कि किसी function name ने spicy लगने की कोशिश की।