AI कमजोरियों में वृद्धि: बेहतर ट्रायाज इसे संभाल सकता है

AI की कमज़ोरियाँ खोजने का सबसे डरावना हिस्सा यह नहीं है कि मशीनें बग ढूँढ लेंगी। मशीनें तो बहुत समय से बग ढूँढती आ रही हैं, ज़्यादातर तब जब इंसान डैशबोर्ड को घूरते हुए यह दिखावा करते हैं कि लाल बैज सजावट के लिए हैं। असली तेज़ समस्या संचालन से जुड़ी है: क्या होता है जब खोज की गति बढ़ जाती है और इंसान, वर्कफ़्लो, और रिलीज़ ट्रेनें ज़िद करके जैविक ही बनी रहती हैं। एक्सप्लॉइट-विनाश के डरावने मॉडल मैं Sam पर छोड़ता हूँ, क्योंकि यहाँ उपयोगी सवाल छोटा और ज़्यादा बनाने लायक है: क्या बेहतर ट्रायाज इस उछाल को संभालने लायक बनाए रख सकता है?

अब बाधा खोज नहीं है

arXiv पेपर When Discovery Outpaces Remediation इस मुद्दे को कतारबंदी की समस्या के रूप में रखता है, जो ताज़गी से भरपूर रूप से गैर-फ़िल्मी है और इसलिए उपयोगी है। लेखक कोड विश्लेषण, बाइनरी विश्लेषण, फ़ज़िंग ऑर्केस्ट्रेशन, और पेनेट्रेशन-टेस्ट योजना के लिए AI सिस्टमों को ऐसी ताकतों के रूप में मॉडल करते हैं जो छिपी हुई कमज़ोरियों की खोज की दर को काफ़ी बढ़ा सकती हैं। उनके एंटरप्राइज़ मॉडल में weighted dependency graph, फिर से भरने वाले vulnerability pools, सीमित remediation capacity, triage degradation, exploit-window compression, और dynamic compromise propagation शामिल हैं। अनुवाद: अगर आपकी intake pipe चौड़ी हो जाती है और आपकी fix pipe वही आकार रखती है, तो बधाई हो, आपने दलदल का आविष्कार कर लिया है।

arXiv पेपर के अनुसार, जब actionable discovery arrivals remediation throughput से ज़्यादा हो जाते हैं, तो backlogs तेज़ी से बढ़ते हैं और systemic risk nonlinear तरीके से बढ़ता है। यही वह उल्टा सबक है जो panic fog के भीतर छिपा है: संकट raw AI capability नहीं है, बल्कि mismatch है। कोई finding संचालन के हिसाब से तभी मायने रखती है जब उसे validate किया गया हो, risk assign किया गया हो, owner तक route किया गया हो, और production में fix किया गया हो। वरना वह बस CVE टोपी पहने एक बहुत महँगा sticky note है।

वही पेपर एक और व्यावहारिक पेच जोड़ता है: hub-dominated topologies में, segmentation propagated compromise को केवल remediation speed की तुलना में अधिक प्रभावी ढंग से घटा सकती है। यह धीरे patch करने का बहाना नहीं है, कृपया इसे hoodie पर print न करवाएँ। इसका मतलब है कि architecture अब भी मायने रखता है, खासकर तब जब एक vulnerable service dependency solar system के केंद्र में एक छोटे, insecure सूरज की तरह बैठी हो।

NHIMG कहता है कि असली दबाव routing है

NHIMG का विश्लेषण, Nucleus का हवाला देते हुए, कहता है कि AI-powered vulnerability research discovery और disclosure को महीनों से घटाकर दिनों में ला रही है, जबकि CVE database में 354,000 से अधिक records हैं। विश्लेषण का तर्क है कि असली चुनौती अब और ज़्यादा issues ढूँढना नहीं है, बल्कि उन्हें इतनी तेज़ी से triage, normalise, और route करना है कि backlog growth remediation capacity से आगे न निकल जाए। normalising शब्द यहाँ बहुत काम कर रहा है, क्योंकि vulnerability data भूकंप के बाद junk drawer की तरह आता है। वही bug, अलग scanner, अलग severity, अलग owner, अलग Tuesday।

NHIMG यह भी नोट करता है कि vulnerability management अब केवल severity scores पर निर्भर रहने के बजाय identity-aware ownership, workflow automation, और risk-based prioritisation पर अधिक निर्भर होता जा रहा है। यही वह जगह है जहाँ AI बिना cape पहने मदद कर सकता है: findings को deduplicate करना, उन्हें asset context से enrich करना, उन्हें responsible teams से map करना, और reachable production risk को scanner confetti से अलग करना। केवल severity के आधार पर triage करना अस्पताल के patients को alphabetically sort करने जैसा है। तकनीकी रूप से व्यवस्थित, चिकित्सकीय रूप से बेतुका।

Daily.dev boring middle में काम कर रहे agents की ओर इशारा करता है

Daily.dev रिपोर्ट करता है कि Checkmarx One ने IDE से production तक vulnerability discovery, triage, और remediation में पाँच AI agents को manage करने वाला orchestration framework जोड़ा है। वही रिपोर्ट कहती है कि Checkmarx ने models, agents, datasets, prompts, और AI-BOM components को track करने के लिए AI Supply Chain Security जोड़ी, और फिर उन पर policy enforce की। यह hoodie पहनकर exploit code लिखने वाले model जितना glamorous नहीं है, लेकिन अधिकतर engineering teams के लिए ज़्यादा relevant है। boring middle वही जगह है जहाँ risk या तो owner वाला ticket बनता है या फिर सबका recurring nightmare।

महत्वपूर्ण बात यह नहीं है कि agent शब्द दिखाई देता है, क्योंकि इस समय हर product में agents हैं जैसे हर cereal box में vitamins होते हैं। उपयोगी हिस्सा development pipeline में orchestration है। अगर कोई AI assistant यह validate कर सकता है कि finding असली है या नहीं, scoped remediation propose कर सकता है, code context attach कर सकता है, और ownership को production assets से tied रख सकता है, तो security team को बड़े inbox के बजाय leverage मिलता है। यही automation और couch के नीचे फँसे Roomba के बीच का अंतर है।

Resilient Cyber कहता है कि पुराने programs चरमरा रहे हैं

Resilient Cyber के Chris Hughes लिखते हैं कि उन्होंने 2024 में Effective Vulnerability Management इसलिए co-author किया क्योंकि industry का approach इस बात से misaligned था कि software कैसे बनाया, deploy किया, और attack किया जा रहा था। उनका तर्क है कि दो साल बाद, वे structural pressures एक order of magnitude तक बढ़ गए हैं, और नए pressures भी उभर रहे हैं। Resilient Cyber, Cloud Security Alliance, SANS, unprompted, और OWASP Gen AI Security Project की The AI Vulnerability Storm की ओर भी इशारा करता है, जिसे अपने programs का पुनर्मूल्यांकन कर रहे security leaders के लिए practitioner-oriented publication बताया गया है।

जो readers ये systems बना रहे हैं या चला रहे हैं, उनके लिए takeaway कोई बड़ा panic button खरीदना नहीं है। arrival rate बनाम remediation throughput मापें, false positives track करें, asset context की आवश्यकता रखें, reachable business risk को prioritize करें, और validated bug से shipped fix तक का रास्ता छोटा करें। ऐसे tools पर ध्यान दें जो code, ownership, runtime exposure, और policy को जोड़ते हैं, न कि ऐसे tools पर जो केवल findings को higher definition में छिड़कते हैं। bug खोजने वाला model hero नहीं है; बंद होने वाला boring ticket है।