हमारे पास हर जगह सुरक्षा ठीक करने के लिए एक साल है
बड़े भाषा मॉडलों में प्रगति इस डर को बढ़ा रही है कि स्वचालित उपकरण जल्द ही बड़े पैमाने पर सॉफ़्टवेयर कमजोरियाँ ढूँढने और उनका दुरुपयोग करने में सक्षम हो जाएंगे, जिससे आज की ही पहले से नाज़ुक सुरक्षा स्थिति और भी अधिक खतरनाक बन जाएगी। टिप्पणीकार बहस करते हैं कि क्या पारंपरिक जवाब—patching, memory-safe भाषाएँ, और formal verification—इस गति से कदम मिला सकते हैं, या क्या microkernel-आधारित सिस्टम, dependency में आक्रामक कमी, air-gapped critical infrastructure, और सख़्त विनियमन जैसी गहरी बदलावों की आवश्यकता है। कई लोग AI के मज़बूत रक्षात्मक उपयोग भी देखते हैं, लेकिन तर्क देते हैं कि प्रोत्साहन, शासन, और वास्तविक दुनिया की जटिलता यह असंभव बनाती है कि रक्षा नए स्वचालित हमलों की गति से या उतनी व्यापकता से आगे बढ़ पाएगी।
आक्रामक सुरक्षा त्वरक के रूप में LLMs
- कई टिप्पणीकारों का कहना है कि जब LLMs को उत्पादन कोडबेस पर लगाया जाता है, तो वे मिनटों में वास्तविक कमजोरियाँ ढूँढ लेते हैं।
- चिंता है कि सस्ते, अनसेंसर स्थानीय मॉडल “for‑loop attacks” को संभव बना देते हैं: CT logs, altcoin repos, ecommerce stacks, आदि को स्कैन करना।
- डर है कि एंटरप्राइज़ सॉफ़्टवेयर और appliances में मौजूद अस्पष्ट बग्स की “long tail” बड़े पैमाने पर exploitable हो जाती है।
- कुछ लोग मानते हैं कि “एक साल” की समयसीमा बहुत उदार है; अन्य लोग नोट करते हैं कि हम दशकों से इसी तरह के “security ठीक करने का आख़िरी मौका” मोड में रहे हैं।
रक्षात्मक उपयोग और उनकी सीमाएँ
- LLMs fuzzing, property tests, code review, और formal proofs में मदद कर सकते हैं, लेकिन रक्षकों को संगठनात्मक घर्षण का सामना करना पड़ता है: approvals, testing, vendor patches।
- असमानता: हमलावरों को केवल एक सफल exploit चाहिए; रक्षकों को लगातार सभी जोखिमों का प्रबंधन करना होता है।
- सुझाव है कि भविष्य में “baseline security” बेहतर हो सकती है, एक बार जब LLMs कम-लटके फल (low-hanging fruit) को छाँट दें।
सिस्टम, OS मॉडल, और attack surface
- microkernels, capability systems, air-gaps, data diodes, और trusted code को न्यूनतम रखने के लिए मजबूत समर्थन; Linux/Windows को मौलिक रूप से बहुत बड़े और ambient-authority-आधारित माना गया है।
- अन्य लोग जो मौजूद है उसे व्यावहारिक रूप से harden करने पर ज़ोर देते हैं: defense-in-depth, sandboxing, zero trust, app whitelisting, सख़्त network exposure।
वेब, CMS, और dependency bloat
- WordPress, ecommerce platforms, और plugins/modules अक्सर fragile security के उदाहरण के रूप में आते हैं; कई लोग static sites या “headless CMS” approaches की सिफ़ारिश करते हैं।
- आपत्तियाँ: गैर-तकनीकी उपयोगकर्ता rich platforms पर निर्भर हैं; static/JAMstack tooling और Git-centric workflows अभी उनकी ज़रूरतों को पूरा नहीं करते।
भाषाएँ, hardware mitigations, और C/C++
- बहुत से लोग memory-safe languages और memory tagging जैसी hardware features का समर्थन करते हैं; अन्य का तर्क है कि adoption बहुत धीमा है।
- “नया C/C++ मत लिखो” बनाम “यदि सावधानी रखें तो C/C++ ठीक हैं” बहस बार-बार आती है; C++ में RAII की प्रशंसा होती है, लेकिन language complexity और legacy footguns की आलोचना की जाती है।
विनियमन, प्रोत्साहन, और risk culture
- बार-बार यह अवलोकन: breaches के गंभीर परिणाम शायद ही होते हैं, इसलिए व्यवसाय वास्तविक resilience के बजाय audits और checkbox compliance के लिए optimize करते हैं।
- कुछ लोग mandatory breach reporting और liability की माँग करते हैं, financial auditing की तरह; अन्य लोग सभी breaches का पता लगाने और रिपोर्ट करने की व्यावहारिक कठिनाई की ओर इशारा करते हैं।
व्यापक AI और सामाजिक जोखिम
- थ्रेड AI-सक्षम social engineering, bio risks, terrorism, और “great filter”/ASI scenarios की चिंताओं तक फैल जाता है, और इनकी वास्तविकता या निकटता को लेकर तीखा मतभेद रहता है।