SQLite महत्वपूर्ण CVE या LLM का स्याही-जैसा शोर?
कई हालिया “critical” SQLite vulnerabilities वास्तव में fabricated निकलीं, संभवतः large language models द्वारा बनाई गईं, फिर भी वे official CVE feeds और enterprise scanners में फैल गईं। टिप्पणीकारों का तर्क है कि यह दिखाता है कि current vulnerability ecosystem कितना overstretched और noisy हो गया है, खासकर उन संगठनों के लिए जो compliance, insurance, या internal policy के तहत हर CVE को context की परवाह किए बिना patch करने को बाध्य हैं। हालांकि कई लोग LLMs को वास्तविक bugs खोजने के शक्तिशाली tools मानते हैं, वे चेतावनी देते हैं कि AI-generated slop triage costs बढ़ा रहा है, CVE data पर भरोसा कमजोर कर रहा है, और मजबूत validation steps जोड़ने का दबाव बना रहा है—संभवतः defensive side पर फिर से AI का उपयोग करके।
संगठनों और सुरक्षा वर्कफ़्लो पर प्रभाव
- कई टिप्पणीकार कहते हैं कि “सभी CVE पैच करो” नीतियाँ (जो SOC2, ISO27001, HIPAA, बीमा शर्तों, सरकारी काम आदि से प्रेरित हैं) पहले से ही मुश्किल से लागू होने योग्य हैं; नकली या कम-गुणवत्ता वाले CVE इसे और खराब कर देते हैं।
- सुरक्षा टीमें रिपोर्ट करती हैं कि उनका अधिकांश समय ऐसे निष्कर्षों को गलत साबित करने में चला जाता है जो शोषण योग्य नहीं हैं या अप्रासंगिक हैं (जैसे headless servers पर Bluetooth कमजोरियाँ, Linux stacks में Windows-only मुद्दे)।
- ऑडिटर, बीमाकर्ता और आंतरिक नीतियाँ अक्सर यह तर्क देने की तुलना में पैच या अपग्रेड करना आसान बना देती हैं कि कोई vuln अप्रासंगिक है, भले ही वह स्पष्ट रूप से पहुँच से बाहर हो।
- कुछ orgs exceptions/risk-based SLAs का उपयोग करके इसे कम करते हैं, लेकिन exceptions को मंज़ूरी दिलाना दर्दनाक और राजनीतिक रूप से संवेदनशील हो सकता है।
CVE ecosystem की समस्याएँ
- CVSS base scores को वास्तविक जोखिम का खराब proxy माना जाता है; environmental/contextual scoring कठिन और श्रमसाध्य है।
- कई CVE अस्पष्ट या अप्रयुक्त components को लक्ष्य बनाते हैं (जैसे libraries के साथ bundled utilities), फिर भी global upgrades मजबूर करते हैं।
- chaining और defense-in-depth “not exploitable” दावों को जटिल बनाते हैं: छोटे bugs भी मिलकर गंभीर बन सकते हैं।
- NIST/NVD पर बहुत बोझ है; CVE assignment मुख्यतः clerical है और submitters पर भरोसा करती है, बिना किसी systematic PoC requirement के।
- बड़े projects का CNAs बनना नियंत्रण वापस लेने की कोशिश है, लेकिन अब वे AI-generated reports की बाढ़ में हैं; कुछ bounty programs ने slop के कारण rewards हटा दिए हैं।
कमजोरी खोज में LLMs
- thread इस बात से सहमत है कि LLMs अब वास्तविक bugs खोजने में सक्षम हैं, खासकर पुराने C/C++ code में; maintainers genuine issues की बढ़ती मात्रा रिपोर्ट कर रहे हैं।
- साथ ही, LLMs code, versions, और exploits पर hallucinate भी करते हैं, जिससे bogus CVEs और triage प्रयास की बर्बादी होती है।
- चिंता है कि attackers scanning LLMs को exploit-writing LLMs और बड़े compute के साथ जोड़कर गहरे, lateral compromise को स्वचालित करेंगे।
- अगला अपेक्षित कदम: ऐसे agents जो auto-reproduce PoCs करें और humans को reports देखने से पहले slop को फ़िल्टर करें, हालांकि cost और reliability अभी खुले मुद्दे हैं।
LLM क्षमताओं और भरोसे पर बहस
- एक पक्ष LLMs को stochastic next-token predictors के रूप में देखता है जिन्हें सख्त human verification की आवश्यकता है, और safety-critical workflows में उन पर ज़रूरत से ज़्यादा भरोसा करने के खिलाफ चेतावनी देता है।
- दूसरा पक्ष तर्क देता है कि, probabilistic होने के बावजूद, वे पहले ही nontrivial problem-solving और code analysis दिखा रहे हैं, और उन्हें शक्तिशाली लेकिन त्रुटिपूर्ण tools के रूप में देखना चाहिए।
- एक व्यापक दार्शनिक बहस भी है कि क्या brains “सिर्फ” probabilistic machines हैं और इसका machine intelligence के लिए क्या अर्थ निकलता है।
प्रस्तावित mitigations और governance
- सुझावों में शामिल हैं: high-severity CVEs के लिए working exploits अनिवार्य करना; finer-grained, usage-aware vulnerability scanners; automated PoC runners; NIST के लिए बेहतर funding; और संभवतः critical domains में AI के दुरुपयोग के लिए professional licensure या मजबूत accountability।