एआई पहले से कहीं अधिक कमजोरियों का पता लगा सकता है। आगे क्या करना है, यह फैसला फिर भी इंसानों को ही करना होगा।

वर्षों से साइबर सुरक्षा टीमें एक सरल धारणा के आधार पर काम करती रही हैं: अगर हम अधिक कमजोरियों का तेजी से पता लगा सकें, तो सॉफ़्टवेयर को अधिक सुरक्षित बना पाएँगे।

कृत्रिम बुद्धिमत्ता इस धारणा की परीक्षा ले रही है। एआई को लेकर व्यापक चर्चा तेज़ी से अपनाने से हटकर उसके मापनीय लाभों पर केंद्रित हो रही है, वहीं साइबर सुरक्षा एक ऐसी चुनौती उजागर कर रही है जो एआई की रफ़्तार धीमी पड़ने पर भी खत्म नहीं होगी। संगठनों को पहले ही एआई से तैयार कमजोरियों से जुड़े ऐसे निष्कर्षों की बढ़ती संख्या का सामना करना पड़ रहा है, जिनकी पुष्टि, प्राथमिकता तय करने और समाधान के लिए अब भी इंसानी भूमिका ज़रूरी है।

प्रोजेक्ट ग्लासविंग के हालिया निष्कर्ष अब तक के सबसे स्पष्ट उदाहरणों में से एक हैं। बताया जाता है कि Claude Mythos Preview ने कुछ ही महीनों में सॉफ़्टवेयर परियोजनाओं में कमजोरियों से जुड़े 26,000 से अधिक निष्कर्षों की पहचान की। फिर भी, ग्लासविंग की सार्वजनिक प्रकटीकरण सूची का स्वतंत्र विश्लेषण बताता है कि उन निष्कर्षों में से केवल लगभग 10% ही प्रकटीकरण प्रक्रिया तक पहुँचे हैं और अंततः 1% से भी कम कमजोरियों के पैच जारी किए गए हैं।

ये आँकड़े चौंकाने वाले हैं, लेकिन हैरान करने वाले नहीं होने चाहिए। उद्योग ने दशकों तक कमजोरियों की खोज को अधिक कुशल बनाने पर ध्यान दिया है। लेकिन उसने एआई के पैमाने पर कमजोरियों से जुड़े निष्कर्षों को संसाधित करने की क्षमता विकसित नहीं की।

साइबर सुरक्षा में अब सबसे बड़ी अड़चन कमजोरियों का पता लगाना नहीं है। असली सवाल यह है कि उसके बाद क्या होता है।

कमजोरियों का पता लगाना कभी सबसे कठिन काम था ही नहीं

प्रोजेक्ट ग्लासविंग की शुरुआती जानकारी में Anthropic ने बताया कि प्रगति अब कमजोरियों का पता लगाने से कम, और रिपोर्टों की पुष्टि करने, प्रकटीकरण में तालमेल बिठाने तथा समाधान के प्रयासों में सहायता देने के लिए आवश्यक मानवीय काम से अधिक सीमित हो रही थी। कंपनी ने यह भी बताया कि कुछ अनुरक्षकों ने प्रकटीकरण की गति धीमी रखने का अनुरोध किया, क्योंकि उनके पास सामने आ रहे निष्कर्षों की संख्या को संसाधित करने की क्षमता नहीं थी।

यह अंतर इसलिए मायने रखता है क्योंकि कमजोरियों का पता लगाना और उनका समाधान करना मूलतः दो अलग-अलग काम हैं।

कमजोरियों का पता लगाना अब तेज़ी से पैटर्न पहचानने का काम बनता जा रहा है। आधुनिक एआई प्रणालियाँ बड़े कोडबेस का विश्लेषण करने, असामान्य व्यवहार पहचानने, निष्पादन के रास्तों का पता लगाने और संभावित कमज़ोरियों को सामने लाने में माहिर हैं।

समाधान करना अलग बात है। किसी कमजोरी को ठीक करने के लिए संदर्भ की जानकारी आवश्यक है। किसी को यह तय करना होगा कि समस्या वास्तविक है या नहीं, उसके संभावित प्रभाव को समझना होगा, संभावित सुधारों का आकलन करना होगा, यह सुनिश्चित करना होगा कि बदलावों से कोई नई खामी न पैदा हो, प्रकटीकरण की समय-सीमा में तालमेल बिठाना होगा, संबंधित पक्षों से संवाद करना होगा और अंततः नतीजे की ज़िम्मेदारी लेनी होगी।

आखिरी बात बेहद अहम है। एआई किसी संभावित कमजोरी की पहचान तो कर सकता है, लेकिन उसके बाद जो होता है, उसकी जवाबदेही नहीं ले सकता। पुष्टि करने, प्राथमिकता तय करने, सुधार करने और रिपोर्ट करने के लिए हमेशा ऐसे इंसान की ज़रूरत होगी जो उस परियोजना के प्रति जवाबदेह हो जिसका वह रखरखाव करता है। और इसमें उन लोगों का समय लगता है, जिनके पास अक्सर पूर्णकालिक नौकरी, परिवार और ध्यान माँगने वाली अन्य ज़िम्मेदारियाँ भी होती हैं। कई ओपन-सोर्स परियोजनाओं में सीमित कारक जोखिम की जानकारी का अभाव नहीं है; बल्कि अनुरक्षकों और सुरक्षा टीमों की वह क्षमता है, जिससे वे लगातार बढ़ती संख्या में सामने आ रहे निष्कर्षों का ज़िम्मेदारी से आकलन कर सकें और उन पर कार्रवाई कर सकें।

यही कमजोरियों का पता लगाने और उनका समाधान करने के बीच बुनियादी अंतर है। कमजोरियों का पता लगाना अब ऐसा काम बनता जा रहा है जिसका दायरा बढ़ाने में एआई हमारी मदद कर सकता है। लेकिन समाधान अब भी उन लोगों पर निर्भर है जिनके पास एआई की खोज पर कार्रवाई करने के लिए ज़रूरी संदर्भ, अधिकार और जवाबदेही है।

ओपन-सोर्स की चुनौती

ओपन-सोर्स जगत में यह स्थिति और भी स्पष्ट दिखाई देती है। 98% वाणिज्यिक कोडबेस में ओपन-सोर्स घटक मौजूद हैं, इसलिए दुनिया का अधिकांश डिजिटल बुनियादी ढाँचा ऐसी परियोजनाओं पर निर्भर है जिनका रखरखाव अपेक्षाकृत छोटे योगदानकर्ता समूह करते हैं।

कई मामलों में, इस महत्वपूर्ण सॉफ़्टवेयर का रखरखाव करने वाले लोग स्वयंसेवक होते हैं या ऐसे व्यक्ति होते हैं जो परियोजना की ज़िम्मेदारियों के साथ पूर्णकालिक नौकरी और निजी दायित्व भी निभाते हैं। जैसे-जैसे एआई से सॉफ़्टवेयर की मात्रा और उसमें पहचानी गई कमजोरियाँ बढ़ती हैं, वैसे-वैसे इन अनुरक्षकों की उस गति से काम कर पाने की क्षमता सुरक्षा के समीकरण का अधिक महत्वपूर्ण हिस्सा बन जाती है।

जब कोई एआई प्रणाली अचानक किसी परियोजना-तंत्र में सैकड़ों या हज़ारों संभावित निष्कर्ष सामने ला देती है, तो इन अनुरक्षकों की क्षमता ही सबसे बड़ी अड़चन बन जाती है।

यह अनुरक्षकों की आलोचना नहीं है। यह वास्तविकता का चित्रण है।

एआई-संचालित कमजोरी खोज के उभरने से पहले भी, कई ओपन-सोर्स परियोजनाएँ सीमित संसाधनों, बढ़ती सुरक्षा अपेक्षाओं और रखरखाव के बढ़ते बोझ से जूझ रही थीं। एआई उस व्यवस्था पर दबाव और बढ़ा रहा है जो पहले से ही अपनी क्षमता की सीमा पर काम कर रही थी।

चुनौती सिर्फ यह तय करना नहीं है कि कोई कमजोरी मौजूद है या नहीं। चुनौती वह सब है जो इसके बाद होता है।

किसी को रिपोर्ट की समीक्षा करनी होगी। किसी को समस्या को दोबारा उत्पन्न करके देखना होगा। किसी को तय करना होगा कि क्या यह सुरक्षा जोखिम है। किसी को समाधान विकसित करके उसका परीक्षण करना होगा। किसी को प्रकटीकरण में तालमेल बिठाना होगा और अपडेट जारी करने होंगे। इन ज़िम्मेदारियों को यूँ ही स्वचालित करके खत्म नहीं किया जा सकता।

एआई से तैयार निष्कर्षों की संख्या लगातार बढ़ने के साथ, ओपन-सोर्स सॉफ़्टवेयर पर निर्भर संगठनों की निर्भरता उन लोगों के स्वास्थ्य और उनके काम को टिकाऊ बनाए रखने की क्षमता पर भी बढ़ती जाएगी, जो उसका रखरखाव करते हैं।

एआई से कमजोरियों की खोज में आने वाले उछाल की तैयारी

तो उद्यमों को क्या करना चाहिए? सबसे पहले, संगठनों को यह समझना होगा कि एआई-संचालित खोज भविष्य की समस्या नहीं है। यह पहले से हो रही है। Project Glasswing ने दिखाया कि अत्याधुनिक मॉडल इतनी व्यापक स्तर पर कमजोरियों का पता लगा सकते हैं, जिसकी कल्पना कुछ साल पहले तक करना भी मुश्किल होता।

दूसरे, सुरक्षा प्रमुखों को यह आकलन करना चाहिए कि क्या उनकी कमजोरियों को दूर करने की प्रक्रियाएँ, खोज की क्षमताओं के साथ-साथ बढ़ सकती हैं। कई संगठनों ने कमजोरियों का पता लगाने में भारी निवेश किया है, जबकि उन्हें दूर करने के लिए जिम्मेदार लोगों और प्रक्रियाओं में अपेक्षाकृत कम निवेश किया है।

तीसरे, उद्यमों को सॉफ़्टवेयर रखरखाव को सुरक्षा के एक कार्य के रूप में अधिक गंभीरता से लेना चाहिए। सुरक्षा पर अक्सर रोकथाम और पहचान के संदर्भ में चर्चा होती है, लेकिन दीर्घकालिक रखरखाव जोखिम प्रबंधन के सबसे महत्वपूर्ण और कम आंके गए घटकों में से एक बना हुआ है। एआई के कारण कमजोरियों का पता लगाना आसान हो सकता है, लेकिन इससे समय के साथ महत्वपूर्ण सॉफ़्टवेयर को सुरक्षित रखने की जिम्मेदारी कम नहीं होती। संगठनों को सॉफ़्टवेयर के पूरे जीवनचक्र की जिम्मेदारी संभालने की ऐसी रणनीति चाहिए, जिससे वे सोच-समझकर आधुनिकीकरण कर सकें—न कि जोखिम सामने आने पर जल्दबाज़ी में माइग्रेशन या प्रतिक्रियात्मक सुधार के लिए मजबूर हों।

अंततः, संगठनों को उन व्यापक पारिस्थितिक तंत्रों का समर्थन करना चाहिए जिन पर वे निर्भर हैं। जैसे-जैसे एआई ओपन-सोर्स सॉफ़्टवेयर में कमजोरियों की खोज तेज़ करेगा, उसका रखरखाव करने वालों पर माँगें बढ़ती जाएँगी। सॉफ़्टवेयर आपूर्ति शृंखला की सुरक्षा आखिरकार इस बात पर निर्भर करती है कि रखरखावकर्ताओं के पास जवाब देने के लिए आवश्यक संसाधन हैं या नहीं।

एआई कमजोरियों का पता तेज़ी से लगा सकता है। लेकिन उनका पता लग जाने से सॉफ़्टवेयर सुरक्षित नहीं हो जाता। असली चुनौती जोखिम की पुष्टि करने, महत्वपूर्ण मुद्दों को प्राथमिकता देने, जाँचे-परखे समाधान उपलब्ध कराने और समय के साथ सॉफ़्टवेयर को सुरक्षित बनाए रखने में है। कमजोरियों की खोज तेज़ होने के साथ, संगठनों को विशेषज्ञता, जवाबदेही और स्पष्ट सेवा-स्तरों से समर्थित, लगातार सुधार करने की क्षमता की आवश्यकता होगी।

क्योंकि साइबर सुरक्षा की सबसे कठिन चुनौती कमजोरी का पता लगाना नहीं है। चुनौती यह है कि उसके बाद क्या होता है।