एआई द्वारा लिखित कोड ने एसएएसटी को क्या पकड़ने की आवश्यकता है

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

लेकिन कार्यात्मक कोड और सुरक्षित कोड एक ही चीज नहीं हैं।

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

यह अंतर महत्वपूर्ण है क्योंकि स्टेटिक एप्लिकेशन सिक्योरिटी टेस्टिंग, या एसएएसटी, मानव गति से कोड लिखने वाले डेवलपर्स और सुरक्षा टीमों के लिए बनाया गया था जो जोखिम के पredictable पैटर्न की समीक्षा करते थे। एआई ने दोनों पक्षों को बदल दिया है। कोड की मात्रा बढ़ रही है, कमिट छोटे हो रहे हैं, और असुरक्षित पैटर्न अब बड़े पैमाने पर उत्पन्न किए जा सकते हैं।

परिणाम एक नया प्रश्न है: जब कोड का लेखक मानव नहीं है, तो एसएएसटी को क्या पकड़ना चाहिए?

कार्यात्मक कोड अब एक मजबूत संकेत नहीं है

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

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

एक मानव समीक्षक एआई-लिखित फ़ंक्शन को देख सकता है और सोच सकता है, “यह सामान्य दिखता है।” यही जोखिम है। कई एआई-जनरेटेड कमजोरियां विदेशी नहीं हैं। वे परिचित मुद्दे हैं जैसे इंजेक्शन दोष, कमजोर मान्यता, असुरक्षित डिफ़ॉल्ट, असुरक्षित डिसेरियलाइजेशन, लॉगिंग समस्याएं, और पुराने निर्भरता विकल्प।

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

आउटपुट उत्पादन के लिए तैयार दिख सकता है, लेकिन अंतर्निहित जोखिम पूरी तरह से अलग हो सकता है।

पुराना एसएएसटी मॉडल मानव बोतलनेक के लिए बनाया गया था

पारंपरिक एसएएसटी का हमेशा एक कठिन काम रहा है। यह स्रोत कोड को स्कैन करता है, ज्ञात कमजोरियों के लिए पैटर्न को मैप करता है, और टीमों को सूचित करता है जब तक कि कमजोर कोड जहाज न हो जाए। एक पारंपरिक विकास चक्र में, यह पहले से ही घर्षण पैदा करता है: बहुत सारे अलर्ट, बहुत सारे झूठे सकारात्मक, और सब कुछ को ठीक करने के लिए पर्याप्त समय नहीं है।

एआई इसे और अधिक कठिन बना देता है क्योंकि यह सॉफ्टवेयर विकास में एक छिपी हुई बाधा को हटा देता है: मानव टाइपिंग की गति।

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

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

एआई मशीन गति से सुरक्षा ऋण पेश करता है

तकनीकी ऋण नया नहीं है। सुरक्षा ऋण इसका अधिक खतरनाक चचेरा भाई है: यह तब जमा होता है जब कमजोरियां, कमजोर धारणाएं, और जोखिम भरे शॉर्टकट कोडबेस में रहते हैं क्योंकि वे आज ठीक करने के लिए पर्याप्त तत्काल नहीं हैं।
एआई इस प्रक्रिया को तेज कर सकता है।

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

एआई के लिए एसएएसटी को अब कुछ विशिष्ट पैटर्न को पहचानने की आवश्यकता है:

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

यह केवल खराब कोड को खोजने के बारे में नहीं है। यह कोड के उत्पादन के बिना पर्याप्त संदर्भ का पता लगाने के बारे में है।

एसएएसटी को इरादे को समझने की आवश्यकता है, न कि केवल वाक्य रचना

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

एक एंडपॉइंट पर विचार करें जो ग्राहक रिकॉर्ड पुनर्प्राप्त करता है। कोड पैरामीटरीकृत क्वेरी का उपयोग कर सकता है, त्रुटियों को सही से संभाल सकता है, और मानक इंजेक्शन जांच पास कर सकता है। लेकिन क्या यह किरायेदार अलगाव लागू करता है? क्या यह वर्तमान उपयोगकर्ता को अनुरोधित रिकॉर्ड तक पहुंचने की अनुमति देने की पुष्टि करता है? क्या यह संवेदनशील डेटा लॉग करता है?

यह एक गोपनीयता प्रश्न भी उठाता है: यदि एआई-जनरेटेड तर्क को बदल देता है कि अनुप्रयोग क्या संग्रहीत करता है, लॉग करता है, या उजागर करता है, तो टीमों को अपने एप्लिकेशन डेटा संग्रह व्यवहार को सुरक्षा समीक्षा के हिस्से के रूप में समझने की आवश्यकता है।

यह हमेशा वाक्य रचना की समस्या नहीं है। यह इरादे की समस्या है।

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

डेवलपर्स को अभी भी सुरक्षा सीखने की आवश्यकता है, बस अलग तरह से

बेहतर उपकरण मदद करेंगे, लेकिन वे मानव जिम्मेदारी को दूर नहीं करेंगे। एआई कोडिंग सहायक डेवलपर्स को अधिक उत्पादक बनाते हैं, लेकिन वे टीमों को ऐसा कोड स्वीकार करने के लिए भी आसान बनाते हैं जिसे वे पूरी तरह से नहीं समझते हैं।

यह एक प्रशिक्षण चुनौती पैदा करता है। पारंपरिक वार्षिक सुरक्षा प्रशिक्षण बहुत धीमा है और दैनिक काम से बहुत दूर है। डेवलपर्स को छोटे, व्यावहारिक पाठों की आवश्यकता होती है जो उन निर्णयों के करीब वितरित किए जाते हैं जो वे कर रहे हैं। यह वह जगह है जहां माइक्रोलर्निंग प्रासंगिक हो जाता है: छोटे, केंद्रित शिक्षण क्षण सुरक्षित कोडिंग आदतों को मजबूत कर सकते हैं बिना इंजीनियरों को उनके कार्य प्रवाह से घंटों के लिए बाहर निकाले।

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

समीक्षा प्रक्रिया को बदलने की आवश्यकता है

कोड समीक्षा ने पहले परिचित प्रश्नों का उत्तर दिया था: क्या कोड पढ़ने योग्य है? क्या यह समस्या का समाधान करता है? क्या यह कुछ तोड़ता है?

एआई-लिखित कोड नई प्रश्न जोड़ता है। क्या प्रॉम्प्ट सुरक्षा-जागरूक था? क्या मॉडल ने एक निर्भरता पेश की? क्या यह पैटर्न को रिपॉजिटरी के अन्य भाग से कॉपी किया बिना इसके क्यों अस्तित्व में था? क्या डेवलपर ने तर्क की पुष्टि की या केवल आउटपुट की?

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

नीचे की रेखा

एआई एसएएसटी को अप्रासंगिक नहीं बना रहा है। यह एसएएसटी को और अधिक महत्वपूर्ण बना रहा है।

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

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

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