भेद्यता रिपोर्टें अब विशेष नहीं रहीं
भेद्यता-रिपोर्ट स्पैम की मात्रा और प्रकृति
- अब कई कंपनियों को हर सप्ताह/दिन कई अनचाही रिपोर्टें मिलती हैं, जो अक्सर स्पष्ट रूप से AI-जनित, निम्न-गुणवत्ता वाली, या जबरन वसूली से जुड़ी होती हैं।
- सामान्य पैटर्न: तुच्छ CSS/UI समस्याएँ, गलत वर्गीकृत “critical” निष्कर्ष, या अपेक्षित व्यवहार को भेद्यता के रूप में रिपोर्ट करना।
- मेंटेनर और सुरक्षा टीमें थकान की रिपोर्ट करती हैं और कार्यक्रम बंद करने या उन्हें सख्त करने पर विचार करती हैं (जैसे AI-लिखी रिपोर्टों पर प्रतिबंध, वीडियो PoC की आवश्यकता, “turtle123”-शैली के छिपे टोकन जोड़ना)।
बग बाउंटी, प्रोत्साहन, और कानूनी जोखिम
- स्पैम को रोकने के सुझाव: प्रति-रिपोर्ट छोटे शुल्क (संभवतः non-refundable), संपर्क फ़ॉर्म पर micro-paywalls, या सख्त नियम।
- चिंताएँ: गलत संरेखित प्रोत्साहन (कंपनियाँ भुगतान से बचने के लिए वैध बग अस्वीकार कर सकती हैं), शुल्क रखने की लेखांकन/कानूनी जटिलता, और ठंडा प्रभाव क्योंकि भुगतान शोधकर्ताओं की पहचान उजागर कर सकते हैं और गिरफ्तारी का कथित जोखिम बढ़ा सकते हैं।
- कुछ शोधकर्ता बताते हैं कि गैर-तुच्छ DoS/RCE-शैली की समस्याओं के लिए भी उन्हें अनदेखा किया गया या कम इनाम मिला।
CVE थकान और dependency hell
- कई लोग CVE overload की शिकायत करते हैं, खासकर कम-प्रभाव वाली समस्याओं के लिए उच्च-गंभीरता रेटिंग्स (जैसे build/dev tools में ReDoS, अस्पष्ट file formats)।
- Dependabot और scanners बड़ी मात्रा में alerts पैदा करते हैं, जिनमें dev dependencies भी शामिल हैं; टीमें वास्तविक जोखिम और शोर में अंतर करने के लिए जूझती हैं।
- Counterpoint: dev और build dependencies वास्तविक attack vectors हैं (जैसे supply chain, dev/CI systems से exfiltration), खासकर regulated sectors में।
- परिणामी पैटर्न: कुछ सभी updates अपने-आप merge कर देते हैं; अन्य updates को batch करते हैं या dependency graphs को न्यूनतम करने की कोशिश करते हैं।
सुरक्षा में LLMs: क्षमता और सीमाएँ
- सहमति: LLMs कई shallow या pattern-based bugs खोजने की लागत बहुत कम कर देते हैं और बड़ी मात्रा में false या बढ़ा-चढ़ाकर की गई रिपोर्टें भी उत्पन्न करते हैं।
- कुछ लोग LLMs को कुछ bug classes के लिए low-effort researchers के औसत के बराबर या उसके करीब मानते हैं; अन्य इसे अतिरंजित और अपमानजनक कहकर खारिज करते हैं।
- कई संगठन अब incoming reports को triage करने, severity वर्गीकृत करने, या spam फ़िल्टर करने के लिए LLMs का उपयोग करते हैं; अन्य agentic tooling का प्रस्ताव देते हैं जो code को auto-audit और यहाँ तक कि patch भी कर सके।
- संशयवादी “jagged” intelligence पर ज़ोर देते हैं: मॉडल कठिन bugs चूक सकते हैं, issues hallucinate कर सकते हैं, और अभी भरोसेमंद last-mile impact analysis नहीं दे सकते।
क्या भेद्यता रिपोर्टें अभी भी विशेष हैं?
- एक पक्ष: vulnerabilities मौलिक रूप से ordinary bugs से अलग बनी रहती हैं; confidentiality और coordination और भी महत्वपूर्ण हैं, क्योंकि अब patches को weaponize करना आसान है।
- दूसरा पक्ष: “security report” और “real, impactful vulnerability” के बीच संबंध टूट चुका है, जिससे रिपोर्टें बस अधिक noisy bug tickets जैसी लगती हैं।
- कई लोग तर्क देते हैं कि दुर्लभ संसाधन अब bug-finding नहीं, बल्कि भरोसेमंद triage और वास्तविक-world impact का प्रदर्शन है।
सुरक्षा अभ्यास, formal methods, और संस्कृति
- कुछ लोग memory-safe languages, formal methods, और मजबूत spec-level reasoning की ओर बढ़ने की वकालत करते हैं; अन्य लोग note करते हैं कि undecidability और उच्च लागत पूर्ण verification को सीमित करती है।
- “perfect security or failure” और pragmatic risk management तथा defense-in-depth के बीच तनाव है।
- कई लोग ज्ञात शोधकर्ताओं के साथ trust relationships, बेहतर प्रोत्साहन, और सुरक्षा तथा engineering के बीच अधिक पेशेवर, कम adversarial interaction की भूमिका पर ज़ोर देते हैं।
भविष्य का दृष्टिकोण (अस्पष्ट और विवादित)
- एक दृष्टिकोण: वर्तमान “vulnpocalypse” अस्थायी है; LLMs आसान bugs को निगल लेंगे, फिर pre-release में integrate हो जाएंगे, जिससे external reports घटेंगे।
- Counterview: LLMs insecure code creation को भी बढ़ाएँगे, और कई संगठन robust pre-release scanning कभी नहीं अपनाएँगे, इसलिए volume और noise ऊँचे बने रहेंगे।
- कुछ लोग भविष्यवाणी करते हैं कि public bounty programs slop के कारण सिकुड़ेंगे या बंद हो जाएँगे, जिससे security work trusted networks और internal या curated programs की ओर जाएगा.