क्या यही नया साइबर सामान्य है?

कुल सवाल: “नया सामान्य” या अस्थायी उछाल?

• कुछ लोगों का कहना है कि यह एक संक्रमणकालीन “गोल्ड रश” है: LLM लंबे समय से जमा बग्स का बैकलॉग साफ कर रहे हैं, इसलिए नए उच्च-प्रभाव वाले vulnerabilities की दर अंततः घटेगी, जब कोड को अधिक व्यवस्थित तरीके से स्कैन और फिर से लिखा जाएगा।
• अन्य इसे सचमुच का “नया सामान्य” (या इससे भी बुरा) मानते हैं: कई मोर्चों पर near-zero-day exploitation, जहाँ disclosure और mass exploitation के बीच की खिड़की बहुत तेजी से सिकुड़ रही है।
• तीसरा दृष्टिकोण: यह बस पुराने सामान्य का ही 11 तक बढ़ा हुआ रूप है; worms, खराब CAs, और लापरवाह सॉफ्टवेयर हमेशा मौजूद रहे हैं, लेकिन LLM discovery और exploitation दोनों को तेज़ कर रहे हैं।

AI की दोहरी भूमिका: हमलावर और रक्षक

• हमलावर अब LLMs के साथ code review, fuzzing, exploit development और OSINT सस्ते में कर सकते हैं। इससे अस्पष्ट, “सैद्धांतिक” bugs व्यावहारिक रूप से exploitable बन जाते हैं।
• रक्षक भी LLMs का उपयोग कर सकते हैं: continuous pentesting, automated code reviews, dependency upgrades, और legacy code की scanning। कुछ लोगों ने LLM tooling अपनाने के बाद customer-reported issues कम होने और pen-test outcomes बेहतर होने की रिपोर्ट दी है।
• coordinated disclosure पर बहस: किसी bug के बारे में संकेत ही attackers के लिए काफी हो सकते हैं कि वे LLMs से exploit जल्दी reconstruct कर लें, जिससे पारंपरिक embargo मॉडल कमजोर पड़ता है।

AI-जनित कोड की सुरक्षा

• एक पक्ष: AI-जनित कोड सुरक्षा के मामले में “बदनाम रूप से खराब” है, और आसानी से SQLi, XSS, missing auth, खराब configs, और unsafe deployment patterns भेज देता है—खासकर जब developers bots पर blind trust करते हैं और review छोड़ देते हैं।
• दूसरा पक्ष: आधुनिक frontier models बहुत defensive code लिख सकते हैं और कई high-priority issues पकड़ सकते हैं, खासकर जब उन्हें multi-step “generate → review → audit” pipelines और स्पष्ट security prompts के साथ इस्तेमाल किया जाए।
• चिंताएँ:
  • “Vibe coding” और मानव निरीक्षण के बिना code flooding।
  • AI का पुराने या unmaintained libraries चुनना, या hardened ones को पुनः उपयोग करने के बजाय उन्हें फिर से implement करना।
  • पुराने models पर आधारित पुरानी studies पर अत्यधिक निर्भरता।

सीमित बनाम अनंत vulnerabilities

• कुछ लोग कहते हैं कि हर codebase में गंभीर bugs का एक सीमित pool होता है; जब LLMs उन्हें खोजकर खत्म कर देंगे, तो स्थिति शांत हो जाएगी।
• अन्य इसका विरोध करते हैं: लगातार बदलाव, जटिल specifications, और Turing-complete systems नए vulnerabilities बनाते रहते हैं; केवल formally verified या radically simplified stacks ही इसे सार्थक रूप से सीमित कर सकते हैं।

सॉफ्टवेयर प्रैक्टिस और architecture में बदलाव

• मांगें:
  • Memory-safe languages (जैसे C/C++ से दूर जाना), सरल architectures, कम dependencies, और छोटे attack surfaces।
  • LLM security scanning को tests/CI की तरह मानना: एक मानक pre-release step।
  • संभवतः अधिक LTS/security-only releases और अधिक static/simple systems; कुछ लोग critical systems को offline करने की बात भी करते हैं।
• इस पर संदेह है कि मौजूदा incentives (speed, cost-cutting, “ship it”) आवश्यक अनुशासन को समर्थन देंगे।

अन्य बार-बार आने वाले विषय

• source बंद करना (जैसे NHS-style) कमजोर सुरक्षा माना जाता है: decompilation और AI-assisted fuzzing फिर भी काम करते हैं।
• चिंता कि छोटी टीमें और non-“big players” तेज़, opaque disclosure cycles से अनुपातहीन रूप से प्रभावित होंगे।
• व्यापक सहमति कि मानव सुरक्षा जागरूकता कम है, निवेश लगातार कम रहा है, और सांस्कृतिक/नियामक बदलाव के बिना LLMs ताकत और कमजोरियों दोनों को बढ़ा देंगे.