एआई सॉफ्टवेयर चुनने के तरीके को बदल रहा है

एआई सॉफ्टवेयर विकास का एक हिस्सा बन गया है। एपीआई जनरेट करने, टेस्ट लिखने और पूरे एप्लिकेशन को स्कैफोल्ड करने से, कोडिंग सहायक इंजीनियरिंग टीमों को समस्याओं का समाधान करने और सॉफ्टवेयर को तेजी से शिप करने में मदद कर रहे हैं। उत्पादकता लाभों को नकारा नहीं जा सकता है, और संगठन एआई को सॉफ्टवेयर विकास जीवन चक्र में तेजी से अपना रहे हैं।

बहुत सारी चर्चा एआई द्वारा उत्पन्न कोड पर केंद्रित है। क्या डेवलपर एआई-जनरेटेड कोड पर भरोसा कर सकते हैं? क्या यह कमजोरियों को पेश करता है? सुरक्षा टीमें इसे कैसे समीक्षा करनी चाहिए? वे प्रश्न महत्वपूर्ण हैं, लेकिन वे सॉफ्टवेयर विकास में एआई लाने वाला सबसे बड़ा परिवर्तन नहीं हैं। एआई ने केवल कोड उत्पन्न करने से आगे बढ़कर सॉफ्टवेयर चयन के पहले निर्णयों को प्रभावित करना शुरू कर दिया है जो संगठन में प्रवेश करने वाले सॉफ्टवेयर को आकार देते हैं।

एआई कोडिंग सहायक शायद ही कभी शून्य से एप्लिकेशन बनाते हैं, और वे मौजूदा फ्रेमवर्क, ओपन-सोर्स लाइब्रेरी, एसडीके, कंटेनर इमेज, और पैकेज इकोसिस्टम का उपयोग करके समाधान बनाते हैं। प्रत्येक सिफारिश एक एप्लिकेशन के लिए सॉफ्टवेयर फाउंडेशन को आकार देती है, अक्सर एक डेवलपर द्वारा उत्पन्न कोड की पहली पंक्ति की समीक्षा करने से पहले।

दशकों से, सॉफ्टवेयर विकास में पहला विश्वास निर्णय लगभग पूरी तरह से डेवलपर्स का था, लेकिन अब यह धारणा बदलने लगी है। एआई तेजी से पहली सिफारिश कर रहा है, जबकि डेवलपर्स बाद में परिणाम को मान्य करते हैं। यह छोटा सा बदलाव सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा के लिए महत्वपूर्ण परिणाम है।

संगठनों ने सॉफ्टवेयर के निर्माण, परीक्षण और तैनाती के तरीके पर वर्षों से शासन किया है। आगामी चुनौती एआई-मूल विकास वातावरण में सॉफ्टवेयर के चयन को नियंत्रित करना है।

पहला विश्वास निर्णय

प्रत्येक एप्लिकेशन हजारों योगदानकर्ताओं द्वारा बनाए गए सॉफ्टवेयर पर निर्भर करता है। एक नई निर्भरता पेश करने से पहले, डेवलपर्स आमतौर पर दस्तावेज़, फ्रेमवर्क की तुलना करते थे, सामुदायिक अपनाने की समीक्षा करते थे, रिलीज़ कैडेंस की जांच करते थे, और यह जांचते थे कि क्या परियोजना उत्पादन के लिए पर्याप्त परिपक्व थी। डेवलपर्स हमेशा सही विकल्प नहीं चुनते थे, लेकिन प्रत्येक निर्भरता जानबूझकर पेश की गई थी।

आज, एक डेवलपर केवल एआई सहायक को “प्रमाणीकरण और पोस्टग्रेसक्यूएल समर्थन के साथ एक सुरक्षित रेस्ट एपीआई बनाएं।” एआई कुछ ही सेकंड में एक काम करने वाली परियोजना उत्पन्न करता है। इसके साथ, यह एक रनटाइम की सिफारिश करता है, एक फ्रेमवर्क चुनता है, एक बेस कंटेनर इमेज को संदर्भित करता है, प्रमाणीकरण लाइब्रेरी आयात करता है, एसडीके चुनता है, और निर्भरता मैनिफेस्ट जैसे पैकेज.जेसन, रिक्वायरमेंट्स.टेक्सट, या पोम.एक्सएमएल उत्पन्न करता है। पैकेज मैनेजर बाद में निर्माण प्रक्रिया के दौरान उन निर्भरताओं और उनकी पारस्परिक निर्भरताओं को हल करते हैं।

अधिकांश डेवलपर्स एआई द्वारा उत्पन्न एप्लिकेशन की समीक्षा करते हैं, लेकिन केवल कुछ ही एआई द्वारा बनाए गए प्रत्येक सॉफ्टवेयर निर्णय की जांच करते हैं। एआई ने सॉफ्टवेयर चयन को जो पहले घंटों के शोध में लेता था, उसे सेकंड में संकुचित कर दिया है और तेजी से डेवलपर्स की ओर से पहली सिफारिश कर रहा है।

प्रत्येक सिफारिश एक विश्वास निर्णय है

प्रत्येक सॉफ्टवेयर कलाकृति अपनी विश्वास श्रृंखला लाती है। एक लाइब्रेरी में मンテनर, योगदानकर्ता, रिलीज़ प्रक्रियाएं, हस्ताक्षर अभ्यास, निर्भरताएं और प्रोवेनेंस होते हैं। एक कंटेनर इमेज अपस्ट्रीम वितरण से सॉफ्टवेयर विरासत में मिलता है, और एक एसडीके अतिरिक्त पैकेज पेश करता है, प्रत्येक उस विश्वास श्रृंखला का विस्तार करता है।

एक एआई सिफारिश तेजी से सैकड़ों सॉफ्टवेयर कलाकृतियों में विस्तारित हो सकती है जो एक एप्लिकेशन का हिस्सा बन जाती हैं। ओपन सोर्स ने हमेशा इस तरह काम किया है। जो बदल रहा है वह यह है कि पहले विश्वास निर्णय कौन लेता है। ऐतिहासिक रूप से, डेवलपर्स उन घटकों का मूल्यांकन और चयन करते थे जिन पर वे भरोसा करते थे। तेजी से एआई सिस्टम प्रारंभिक सिफारिशें कर रहे हैं, जबकि डेवलपर्स बाद में परिणाम को मान्य करते हैं।

यह एक छोटा सा बदलाव लगता है, लेकिन यह सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा के बारे में सोचने के तरीके को मूल रूप से बदलता है।

एआई कार्यशील सॉफ्टवेयर के लिए अनुकूलन करता है, संगठनात्मक विश्वास नहीं

इसका मतलब यह नहीं है कि एआई खराब सिफारिशें कर रहा है। इसके विपरीत।

एआई कोडिंग सहायक सॉफ्टवेयर की सिफारिश करने में अच्छे हैं क्योंकि उन्होंने लाखों उदाहरणों से सीखा है कि डेवलपर्स समान समस्याओं का समाधान कैसे करते हैं। परिणामस्वरूप, लोकप्रिय फ्रेमवर्क, अच्छी तरह से समर्थित लाइब्रेरी, और परिचित कार्यान्वयन पैटर्न स्वाभाविक रूप से उनकी सिफारिशों में दिखाई देते हैं, और यही उन उपकरणों को इतना मूल्यवान बनाता है।

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

कार्यक्षमता, लोकप्रियता और संभावना कोड उत्पन्न करने के लिए उपयोगी संकेत हैं, लेकिन उन्हें कभी भी सत्यापन के विकल्प के रूप में उपयोग नहीं किया जाना चाहिए।

हमें बायां एकीकरण क्यों करने की आवश्यकता है

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

वे उपकरण अभी भी आवश्यक हैं, लेकिन वे समस्या के एक अलग हिस्से को संबोधित करते हैं।

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

यही कारण है कि मुझे लगता है कि संगठनों को बायां एकीकरण की आवश्यकता है।

बायां एकीकरण का विचार सरल है: सॉफ्टवेयर का विश्वास स्थापित किया जाना चाहिए जब यह एक एप्लिकेशन का हिस्सा बन जाता है, न कि बाद में। जैसे ही एआई सॉफ्टवेयर विकास में एक सक्रिय भागीदार बन जाता है, यह सिद्धांत और भी महत्वपूर्ण हो जाता है। शासन को सॉफ्टवेयर का चयन करने के बिंदु पर स्थानांतरित करने की आवश्यकता है, न कि जहां यह अंततः स्कैन किया जाता है।

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

एआई युग में सॉफ्टवेयर चयन का शासन

संगठन पहले से ही परिभाषित करते हैं कि सॉफ्टवेयर कहां चल सकता है, यह कैसे तैनात किया जाता है, और इसके लिए कौन अधिकृत है। तेजी से, वे यह भी परिभाषित करेंगे कि एआई को कौन सा सॉफ्टवेयर सिफारिश करने की अनुमति है।

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

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

जो संगठन सफल होंगे वे विश्वसनीय सॉफ्टवेयर स्रोत स्थापित करेंगे, एआई द्वारा सिफारिश की गई सॉफ्टवेयर कलाकृतियों की पुष्टि करेंगे, और विकास प्रवाह में प्रवेश करने से पहले शासन को एकीकृत करेंगे।

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