हाल के महीनों में, हमने कंप्यूटर-जनित चेहरों, बिल्ली के चित्रों, वीडियो, निबंधों और यहां तक कि कला की गुणवत्ता पर आश्चर्य व्यक्त किया है। GitHub Copilot, Tabnine, Polycode जैसे टूल के साथ आर्टिफिशियल इंटेलिजेंस (AI) और मशीन लर्निंग (ML) भी चुपचाप सॉफ्टवेयर विकास में शामिल हो गए हैं। और दूसरे एआई स्टेरॉयड पर मौजूदा कोड स्वत: पूर्ण कार्यक्षमता डालने का तार्किक अगला कदम उठाना। हालांकि, कैट पिक्स के विपरीत, एप्लिकेशन कोड की उत्पत्ति, गुणवत्ता और सुरक्षा के व्यापक प्रभाव हो सकते हैं - और कम से कम सुरक्षा के लिए, शोध से पता चलता है कि जोखिम वास्तविक है।
पूर्व शैक्षिक अनुसंधान पहले ही दिखाया जा चुका है कि GitHub Copilot अक्सर सुरक्षा कमजोरियों के साथ कोड उत्पन्न करता है। अभी हाल ही में, इनविक्टी सुरक्षा इंजीनियर कादिर अर्सलान के व्यावहारिक विश्लेषण से यह पता चला है असुरक्षित कोड सुझाव कोपायलट के मामले में अपवाद के बजाय अभी भी नियम हैं। अर्सलान ने पाया कि कई सामान्य कार्यों के सुझावों में केवल पूरी तरह से नंगी हड्डियाँ शामिल होती हैं, जो अक्सर सबसे बुनियादी और कम से कम सुरक्षित मार्ग अपनाती हैं, और बिना संशोधन के उन्हें स्वीकार करने से कार्यात्मक लेकिन कमजोर अनुप्रयोग हो सकते हैं।
कोपायलट जैसा उपकरण (डिज़ाइन के अनुसार) स्वत: पूर्णता एक पायदान ऊपर है, स्निपेट्स का सुझाव देने के लिए ओपन सोर्स कोड पर प्रशिक्षित है जो समान संदर्भ में प्रासंगिक हो सकता है। यह सुझावों की गुणवत्ता और सुरक्षा को प्रशिक्षण सेट की गुणवत्ता और सुरक्षा से निकटता से जोड़ता है। इसलिए बड़े प्रश्न कोपायलट या किसी अन्य विशिष्ट उपकरण के बारे में नहीं हैं, बल्कि सामान्य तौर पर एआई-जनरेटेड सॉफ़्टवेयर कोड के बारे में हैं।
यह मान लेना उचित है कि कोपायलट केवल भाले की नोक है और आने वाले वर्षों में इसी तरह के जनरेटर आम हो जाएंगे। इसका मतलब है कि हमें, प्रौद्योगिकी उद्योग को, यह पूछना शुरू करना होगा कि इस तरह का कोड कैसे उत्पन्न किया जा रहा है, इसका उपयोग कैसे किया जाता है, और चीजें गलत होने पर कौन जिम्मेदारी लेगा।
सतनाव सिंड्रोम
पारंपरिक कोड स्वत: पूर्णता, जो फ़ंक्शन नामों को पूरा करने के लिए फ़ंक्शन परिभाषाओं को देखती है और आपको याद दिलाती है कि आपको किन तर्कों की आवश्यकता है, एक बड़े पैमाने पर समय बचाने वाला है। चूँकि ये सुझाव स्वयं दस्तावेज़ों को खोजने का एक शॉर्टकट मात्र हैं, इसलिए हमने आईडीई द्वारा सुझाए गए किसी भी सुझाव पर पूरी तरह भरोसा करना सीख लिया है। एक बार जब एआई-संचालित टूल आ जाता है, तो उसके सुझावों के सही होने की गारंटी नहीं रह जाती है - लेकिन वे अभी भी मित्रवत और भरोसेमंद लगते हैं, इसलिए उन्हें स्वीकार किए जाने की अधिक संभावना है।
विशेष रूप से कम अनुभवी डेवलपर्स के लिए, कोड का मुफ्त ब्लॉक प्राप्त करने की सुविधा मानसिकता में बदलाव को प्रोत्साहित करती है, "क्या यह कोड जो मैं लिखूंगा उसके काफी करीब है" से "मैं इस कोड को कैसे संशोधित कर सकता हूं ताकि यह मेरे लिए काम करे।"
GitHub बहुत स्पष्ट रूप से कहता है कि कोपायलट सुझावों का हमेशा सावधानीपूर्वक विश्लेषण, समीक्षा और परीक्षण किया जाना चाहिए, लेकिन मानव स्वभाव यह तय करता है कि सबपर कोड भी कभी-कभी इसे उत्पादन में लाएगा। यह कुछ-कुछ सड़क के बजाय अपने जीपीएस को देखते हुए गाड़ी चलाने जैसा है।
आपूर्ति श्रृंखला सुरक्षा मुद्दे
RSI Log4j सुरक्षा संकट हाल ही में सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा और विशेष रूप से ओपन सोर्स सुरक्षा को सुर्खियों में लाया गया है व्हाइट हाउस ज्ञापन सुरक्षित सॉफ़्टवेयर विकास और एक नए पर ओपन सोर्स सुरक्षा में सुधार पर बिल. इन और अन्य पहलों के साथ, आपके अनुप्रयोगों में किसी भी ओपन सोर्स कोड को जल्द ही सामग्री के सॉफ्टवेयर बिल (एसबीओएम) में लिखने की आवश्यकता हो सकती है, जो केवल तभी संभव है जब आप जानबूझकर एक विशिष्ट निर्भरता शामिल करते हैं। सॉफ़्टवेयर संरचना विश्लेषण (एससीए) उपकरण भी पुराने या कमजोर ओपन सोर्स घटकों का पता लगाने और चिह्नित करने के लिए उस ज्ञान पर निर्भर करते हैं।
लेकिन क्या होगा यदि आपके एप्लिकेशन में एआई-जनरेटेड कोड शामिल है, जो अंततः एक ओपन सोर्स प्रशिक्षण सेट से उत्पन्न होता है? सैद्धांतिक रूप से, यदि एक भी महत्वपूर्ण सुझाव मौजूदा कोड के समान है और उसे वैसे ही स्वीकार किया जाता है, तो आपके सॉफ़्टवेयर में ओपन सोर्स कोड हो सकता है, लेकिन आपके एसबीओएम में नहीं। इससे अनुपालन संबंधी समस्याएं हो सकती हैं, यदि कोड असुरक्षित हो जाता है और उल्लंघन होता है तो दायित्व की संभावना का उल्लेख नहीं किया जा सकता है - और एससीए आपकी मदद नहीं करेगा, क्योंकि यह केवल कमजोर निर्भरताएं ढूंढ सकता है, आपके अपने कोड में कमजोरियां नहीं। .
लाइसेंसिंग और एट्रिब्यूशन संबंधी कठिनाइयाँ
विचार की उस श्रृंखला को जारी रखते हुए, ओपन सोर्स कोड का उपयोग करने के लिए, आपको इसकी लाइसेंसिंग शर्तों का पालन करना होगा। विशिष्ट ओपन सोर्स लाइसेंस के आधार पर, आपको कम से कम एट्रिब्यूशन प्रदान करने या कभी-कभी ओपन सोर्स के रूप में अपना कोड जारी करने की आवश्यकता होगी। कुछ लाइसेंस व्यावसायिक उपयोग को पूरी तरह से प्रतिबंधित करते हैं। लाइसेंस जो भी हो, आपको यह जानना होगा कि कोड कहां से आया और इसका लाइसेंस कैसे दिया गया है।
फिर, क्या होगा यदि आपके एप्लिकेशन में एआई-जनरेटेड कोड है जो मौजूदा ओपन सोर्स कोड के समान है? यदि आपके पास ऑडिट था, तो क्या यह पाया जाएगा कि आप आवश्यक एट्रिब्यूशन के बिना कोड का उपयोग कर रहे हैं? या हो सकता है कि अनुपालन में बने रहने के लिए आपको अपने कुछ वाणिज्यिक कोड को स्रोत खोलने की आवश्यकता हो? शायद वर्तमान उपकरणों के साथ यह अभी तक एक यथार्थवादी जोखिम नहीं है, लेकिन ये ऐसे प्रश्न हैं जो हम सभी को आज पूछना चाहिए, 10 वर्षों में नहीं। (और स्पष्ट होने के लिए, GitHub Copilot के पास आपूर्ति श्रृंखला जोखिमों को कम करने के लिए मौजूदा कोड से मेल खाने वाले सुझावों को ब्लॉक करने के लिए एक वैकल्पिक फ़िल्टर है।)
गहरे सुरक्षा निहितार्थ
सुरक्षा पर वापस जाएं, तो एआई/एमएल मॉडल अपने प्रशिक्षण सेट जितना ही अच्छा (और उतना ही बुरा) है। हमने इसे अतीत में देखा है - उदाहरण के लिए, के मामलों में नस्लीय पूर्वाग्रह दिखाने वाला चेहरा पहचान एल्गोरिदम उस डेटा के कारण जिस पर उन्हें प्रशिक्षित किया गया था। इसलिए यदि हमारे पास शोध से पता चलता है कि एक कोड जनरेटर अक्सर सुरक्षा पर विचार किए बिना सुझाव देता है, तो हम अनुमान लगा सकते हैं कि इसका शिक्षण सेट (यानी, सार्वजनिक रूप से उपलब्ध कोड) ऐसा ही था। और क्या होगा यदि असुरक्षित एआई-जनरेटेड कोड उस कोड बेस में वापस फीड हो जाए? क्या सुझाव कभी सुरक्षित हो सकते हैं?
सुरक्षा प्रश्न यहीं नहीं रुकते. यदि एआई-आधारित कोड जनरेटर लोकप्रियता हासिल करते हैं और नए कोड के सार्थक अनुपात का हिसाब रखना शुरू करते हैं, तो संभावना है कि कोई उन पर हमला करने की कोशिश करेगा। एआई छवि पहचान को उसके शिक्षण सेट में जहर देकर मूर्ख बनाना पहले से ही संभव है। देर-सबेर, दुर्भावनापूर्ण अभिनेता इस उम्मीद में सार्वजनिक रिपॉजिटरी में विशिष्ट रूप से कमजोर कोड डालने का प्रयास करेंगे कि यह सुझावों में आएगा और अंततः एक उत्पादन एप्लिकेशन में समाप्त हो जाएगा, जिससे इसे एक आसान हमले के लिए खोल दिया जाएगा।
और मोनोकल्चर के बारे में क्या? यदि कई एप्लिकेशन एक ही अत्यधिक संवेदनशील सुझाव का उपयोग करते हैं, तो इसका मूल जो भी हो, हम भेद्यता महामारी या शायद एआई-विशिष्ट कमजोरियों को भी देख सकते हैं।
एआई पर नजर रखना
इनमें से कुछ परिदृश्य आज दूर की कौड़ी लग सकते हैं, लेकिन वे सभी चीजें हैं जिन पर हमें तकनीकी उद्योग में चर्चा करने की आवश्यकता है। फिर से, GitHub Copilot केवल इसलिए सुर्खियों में है क्योंकि यह वर्तमान में अग्रणी है, और GitHub AI-जनित सुझावों की चेतावनियों के बारे में स्पष्ट चेतावनी प्रदान करता है। आपके फोन पर स्वत: पूर्ण होने या आपके सतनाव में रूट सुझावों की तरह, वे हमारे जीवन को आसान बनाने के लिए केवल संकेत हैं, और उन्हें लेना या छोड़ना हम पर निर्भर है।
विकास दक्षता में तेजी से सुधार करने की अपनी क्षमता के साथ, एआई-आधारित कोड जनरेटर सॉफ्टवेयर दुनिया का एक स्थायी हिस्सा बनने की संभावना है। एप्लिकेशन सुरक्षा के संदर्भ में, हालांकि, यह संभावित रूप से कमजोर कोड का एक और स्रोत है जिसे उत्पादन में अनुमति देने से पहले कठोर सुरक्षा परीक्षण पास करने की आवश्यकता होती है। हम कमजोरियों (और संभावित रूप से अनियंत्रित निर्भरता) को सीधे आपके प्रथम-पक्ष कोड में डालने का एक नया तरीका देख रहे हैं, इसलिए एआई-संवर्धित कोडबेस को परीक्षण होने तक अविश्वसनीय मानना समझ में आता है - और इसका मतलब है कि हर चीज का जितनी बार आप परीक्षण करते हैं कर सकना।
यहां तक कि कोपायलट जैसे अपेक्षाकृत पारदर्शी एमएल समाधान पहले से ही कुछ कानूनी और नैतिक सवाल उठाते हैं, सुरक्षा चिंताओं का तो जिक्र ही नहीं। लेकिन जरा कल्पना करें कि एक दिन, कोई नया उपकरण कोड उत्पन्न करना शुरू कर देता है जो पूरी तरह से काम करता है और सुरक्षा परीक्षण पास करता है, एक छोटी सी जानकारी को छोड़कर: कोई नहीं जानता कि यह कैसे काम करता है। तभी घबराने का समय है।
