क्या AI द्वारा बनाया गया कोड वाकई सुरक्षित है? एक बिल्डर का FAQ

यह सवाल मुझे लगभग हर ऑनबोर्डिंग कॉल में किसी न किसी रूप में मिलता है, आमतौर पर सावधानी से पूछा गया, जैसे पूछने वाले को आधी उम्मीद हो कि उसे चिंता करने से रोका जाएगा। उन्हें रोका नहीं जाना चाहिए। सुरक्षा उन चंद क्षेत्रों में से एक है जहां एक स्वस्थ मात्रा में सावधानी सही ढंग से संतुलित है, चाहे कोड किसी इंसान ने लिखा हो या किसी मॉडल ने। नीचे वे सवाल हैं जो मुझे वाकई मिलते हैं, जितना सीधा हो सके उतना जवाब दिया गया है।

क्या AI द्वारा लिखा गया कोड इंसान द्वारा लिखे कोड से कम सुरक्षित है?

औसतन, और बिना जांच के छोड़ दिया जाए तो, हां — थोड़ा सा। कुछ साल पहले के एक स्टैनफोर्ड अध्ययन (पेरी एट अल., जिसे अक्सर इस पर पहली असली नज़र माना जाता है) में पाया गया कि AI कोडिंग असिस्टेंट का इस्तेमाल करने वाले डेवलपर्स ने कंट्रोल ग्रुप की तुलना में कम सुरक्षित कोड बनाया — और, यह वह हिस्सा है जो आपको ज़्यादा चिंतित करना चाहिए — अपने ही कोड को उससे ज़्यादा सुरक्षित रेट किया जितना वह वास्तव में था। भरोसा बढ़ गया जबकि गुणवत्ता घट गई। Veracode के हाल के GenAI कोड सिक्योरिटी स्कैन इस पर एक मोटा आंकड़ा भी देते हैं: उनके द्वारा टेस्ट किए गए लगभग 4 में से 10 AI-जनरेटेड कोड सैंपल में कम से कम एक एक्सप्लॉयटेबल खामी पाई गई, आमतौर पर कोई सामान्य चीज़ जैसे मिसिंग इनपुट चेक या कमज़ोर डिफ़ॉल्ट। इसका मतलब यह नहीं कि AI-लिखित कोड जन्मजात रूप से बर्बाद है। इसका मतलब है कि बिना रिव्यू किए गए AI-लिखित कोड में वही जोखिम है जो बिना रिव्यू किए गए इंसानी कोड में होता है, और असली खतरा "बिना रिव्यू" वाले हिस्से में ही रहता है। एक मॉडल जो तेज़ी से लिखता है और कभी जांचा नहीं जाता, वही गलतियां भेजेगा जो एक जूनियर डेवलपर शुक्रवार दोपहर को करता है — बस तेज़ी से, और ज़्यादा मात्रा में।

मेरी API keys और सीक्रेट्स का क्या होता है?

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

क्या कोई मेरी साइट को किसी प्रॉम्प्ट के ज़रिए हैक कर सकता है, जैसे प्रॉम्प्ट इंजेक्शन अटैक?

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

क्या बिल्डर कोड भेजने से पहले खुद उसमें कमज़ोरियां जांचता है?

ऑटोमेटेड चेक्स आमतौर पर उबाऊ, हाई-फ़्रीक्वेंसी चीज़ों को भरोसेमंद ढंग से पकड़ लेते हैं: हार्डकोडेड सीक्रेट्स, किसी ऐसे एंडपॉइंट पर मिसिंग ऑथ जिसे स्पष्ट रूप से चाहिए, स्ट्रिंग कॉन्कैटेनेशन से बना SQL बजाय पैरामीटर के, जाने-माने CVE वाली डिपेंडेंसीज़। जो चीज़ ये अच्छी तरह नहीं पकड़ते वह है बिज़नेस-लॉजिक की खामियां — जहां कोड की हर अलग लाइन ठीक है और कमज़ोरी दो फ़ीचर्स के बीच के गैप में है जिसे किसी ने साथ में जांचने के बारे में सोचा ही नहीं। एक डिस्काउंट कोड जो रेफरल बोनस के साथ अनंत रूप से स्टैक होता है। एक पासवर्ड रीसेट फ़्लो जो लीक कर देता है कि सिस्टम में कोई ईमेल मौजूद है या नहीं। इनके लिए किसी ऐसे व्यक्ति की ज़रूरत होती है जो समझता हो कि ऐप किसलिए है, न कि सिर्फ यह कि कोड क्या करता है, और अभी तक कोई स्कैनर — चाहे AI हो या कुछ और — भरोसेमंद ढंग से इन्हें नहीं ढूंढ पाता। ऑटोमेटेड रिव्यू एक फ़्लोर है, सीलिंग नहीं।

इसके द्वारा इंस्टॉल किए जाने वाले थर्ड-पार्टी पैकेज के बारे में क्या — क्या यह सप्लाई-चेन रिस्क है?

हां, और ईमानदारी से यह खुद AI-लिखित कोड से भी बड़ा असली दुनिया का जोखिम है। ज़्यादातर ऐप्स लाइन काउंट के हिसाब से 80-95% डिपेंडेंसीज़ होते हैं; बिल्डर जो कोड लिखता है वह npm, PyPI, या जो भी इकोसिस्टम स्टैक इस्तेमाल करता है, उसके ऊपर एक पतली परत है। एक दुर्भावनापूर्ण या हाईजैक किया गया पैकेज आपको समझौता कर सकता है, चाहे उसके आस-पास के ग्लू कोड को किसी ने भी लिखा हो — यह असल दुनिया में कैसे होता है यह देखने के लिए event-stream और colors.js घटनाओं को देखें। समाधान उबाऊ लेकिन असरदार हैं: लेटेस्ट ट्रैक करने के बजाय वर्ज़न पिन करें, पिछले हफ़्ते पब्लिश हुए पैकेजों की तुलना में असली मेंटेनेंस हिस्ट्री वाले पैकेजों को प्राथमिकता दें, और डिपेंडेंसी ऑडिट (`npm audit`, `pip-audit`, जो भी आपके स्टैक में फ़िट हो) चलाएं — लॉन्च से पहले एक बार के बजाय, एक स्थायी आदत के रूप में।

अगर कोई ब्रीच हो तो इसका दायित्व किस पर है?

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

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

क्या मुझे लॉन्च से पहले असली सुरक्षा ऑडिट के लिए भुगतान करना चाहिए?

अगर आप पेमेंट ले रहे हैं, कुछ भी स्टोर कर रहे हैं जिसे कोई रेगुलेटर PII कहेगा, या किसी बिज़नेस ग्राहक के लिए बना रहे हैं जो वैसे भी SOC 2 रिपोर्ट मांगेगा — तो हां, और लागत को आपको इससे रोकने न दें। एक छोटे ऐप पर फ़ोकस्ड ऑडिट स्कोप के आधार पर कुछ सौ से लेकर कुछ हज़ार डॉलर तक चलता है, जो ब्रीच नोटिफिकेशन लेटर की तुलना में सस्ता है। अगर आप कोई शौकिया प्रोजेक्ट, कोई इंटरनल टूल, या ऐसी कोई चीज़ बना रहे हैं जिसमें असली यूज़र डेटा दांव पर नहीं है, तो पेड ऑडिट ज़रूरत से ज़्यादा है; इसके बजाय मुफ़्त और सस्ती परत चलाएं — डिपेंडेंसी स्कैनिंग, हर ऑथ बाउंड्री का मैनुअल क्लिक-थ्रू (क्या यूज़र A URL बदलकर यूज़र B की चीज़ें देख सकता है?), और पैसे या पासवर्ड को छूने वाली किसी भी चीज़ पर एक और इंसान की नज़र।

लोग सबसे आम सुरक्षा गलती क्या करते हैं, और यह कब होती है?

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