BrassCoders ने उनके द्वारा जांची गई पंद्रह में से दो AI-जनरेटेड Python स्क्रिप्ट्स में हार्ड-कोडेड सीक्रेट्स (hard-coded secrets) का पता लगाया, जिससे उन डेवलपर्स के लिए एक ठोस जोखिम सामने आया है जो सीधे लार्ज लैंग्वेज मॉडल के आउटपुट से कोड कॉपी-पेस्ट करते हैं। निष्कर्ष बताते हैं कि एक गलत जगह रखी गई की (key) या पासवर्ड, एक सहायक स्निपेट को वर्जन कंट्रोल और प्रोडक्शन एनवायरनमेंट में क्रेडेंशियल लीक में बदल सकता है।

परीक्षण में क्या सामने आया

पहली स्क्रिप्ट, token_check.py, एक ऐसे प्रॉम्प्ट से बनाई गई थी जिसमें सेशन टोकन साइन करने और एक "उपयोग करने योग्य उदाहरण" (usable example) शामिल करने के लिए एक फंक्शन मांगा गया था। कोड को चलाने योग्य बनाने के लिए, मॉडल ने सीधे सोर्स फ़ाइल में एक वास्तविक HMAC साइनिंग की (key) डाल दी।

  • समस्या: सीक्रेट की (key) कोड बेस में ही मौजूद है।
  • जोखिम: रिपॉजिटरी तक रीड एक्सेस रखने वाला कोई भी व्यक्ति उस की (key) को देख सकता है, और कोई भी डिप्लॉयमेंट जो उस फ़ाइल को खींचता है, वह उस सीक्रेट को भी अपना लेता है।
  • परिणाम: यदि कोई हमलावर उस की (key) को प्राप्त कर लेता है, तो वह वैध सेशन टोकन बना (forge) सकता है, जिससे ऑथेंटिकेशन चेक को बायपास किया जा सकता है।

दूसरी स्क्रिप्ट, email_sender.py, SMTP के माध्यम से ईमेल भेजने वाले फंक्शन के अनुरोध का उत्तर थी। मॉडल ने फिर से एक वास्तविक पासवर्ड दिया ताकि उदाहरण तुरंत काम कर सके।

  • समस्या: पासवर्ड फंक्शन कॉल में एक प्लेन-टेक्स्ट स्ट्रिंग के रूप में दिखाई देता है।
  • जोखिम: पासवर्ड बदलने (rotate करने) के लिए कोड में बदलाव और नए डिप्लॉयमेंट की आवश्यकता होती है, और वह क्रेडेंशियल हर उस एनवायरनमेंट में फैल जाता है जो उस फ़ाइल का उपयोग करता है।
  • परिणाम: पासवर्ड को सोर्स कंट्रोल, लॉग्स, या कंपाइल्ड पैकेज से निकाला जा सकता है, जिससे हमलावर को मेल सर्वर का अनधिकृत एक्सेस मिल सकता है।

AI सीक्रेट्स क्यों देता है

लार्ज लैंग्वेज मॉडल प्रॉम्प्ट को पूरा करके टेक्स्ट जनरेट करते हैं। जब कोई उपयोगकर्ता "उपयोग करने योग्य उदाहरण" मांगता है, तो मॉडल इसे "ऐसा कोड जो बिना किसी अतिरिक्त सेटअप के चले" के रूप में व्याख्या करता है। इसलिए, यह गायब मानों—जैसे API कीज़, पासवर्ड, टोकन—को संभावित प्लेसहोल्डर्स के साथ भर देता है। जब तक प्रॉम्प्ट में स्पष्ट रूप से उल्लेख न किया जाए, मॉडल को सीक्रेट-मैनेजमेंट की सर्वोत्तम प्रथाओं (best practices) की जानकारी नहीं होती है।

AI-जनरेटेड कोड के एक हालिया Veracode विश्लेषण में पाया गया कि 45% स्निपेट्स में OWASP Top 10 में सूचीबद्ध कम से कम एक भेद्यता (vulnerability) है, जिसमें क्रेडेंशियल एक्सपोज़र का एक बड़ा हिस्सा है। यह आंकड़ा इस बात पर जोर देता है कि यह समस्या केवल कुछ अपवादों तक सीमित नहीं है; यह इस बात का एक प्रणालीगत उप-उत्पाद (systemic by-product) है कि इन मॉडलों को कैसे प्रशिक्षित और प्रॉम्प्ट किया जाता है।

डेवलपर्स अभी कौन से बचाव के कदम उठा सकते हैं

सबसे सरल बचाव यह है कि किसी भी सीक्रेट को कोड फ़ाइल से बाहर रखा जाए। एनवायरनमेंट वेरिएबल्स (Environment variables) सबसे आम और भाषा-स्वतंत्र (language-agnostic) तरीका हैं:

# token_check.py – secure version
import os
import hmac
import hashlib

SECRET_KEY = os.environ["HMAC_SECRET_KEY"]

def sign_token(data: bytes) -> str:
    return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()

# email_sender.py – secure version
import os
import smtplib

smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)

os.environ का उपयोग करने से रनटाइम एनवायरनमेंट से वैल्यू प्राप्त होती है, जिससे वह वर्जन कंट्रोल से बाहर रहती है और सोर्स फ़ाइलों को छुए बिना उसे बदला (rotate) जा सकता है। यही पैटर्न उन कॉन्फ़िगरेशन फ़ाइलों के साथ भी काम करता है जिन्हें कमिट से बाहर रखा जाता है, या सीक्रेट-मैनेजमेंट सेवाओं, या कंटेनर-ऑर्केस्ट्रेटेड सीक्रेट्स के साथ भी काम करता है।

अतिरिक्त सुरक्षा उपाय

  • कोड रिव्यूज (Code reviews) जो सामान्य सीक्रेट पैटर्न (जैसे लंबी अल्फ़ान्यूमेरिक सीक्वेंस) से मेल खाने वाली लिटरल स्ट्रिंग्स को फ्लैग करें।
  • स्टैटिक एनालिसिस टूल्स (Static analysis tools) जो नए जोड़े गए फ़ाइलों में हार्ड-कोडेड क्रेडेंशियल्स का पता लगाने के लिए ट्यून किए गए हों।
  • प्रॉम्प्ट इंजीनियरिंग (Prompt engineering): मॉडल से स्पष्ट रूप से कहें कि "सभी सीक्रेट्स के लिए एनवायरनमेंट वेरिएबल्स का उपयोग करें" या "वास्तविक क्रेडेंशियल्स को छोड़ दें।"
  • पोस्ट-जनरेशन लिंटिंग (Post-generation linting): कोड को प्रोजेक्ट में कॉपी करने से पहले एक त्वरित स्क्रिप्ट चलाएं जो संदिग्ध लिटरल की तलाश करती है।

काउंटर-पॉइंट: क्या इसका मतलब है कि AI कोड असुरक्षित है?

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

आगे क्या ध्यान रखें

  • टूलिंग अपडेट्स (Tooling updates): AI प्लेटफॉर्म सुरक्षा फिल्टर शामिल करना शुरू कर रहे हैं जो सीक्रेट्स को प्लेसहोल्डर्स से बदल देते हैं। इन बदलावों पर नज़र रखने से जोखिम कम हो सकता है।
  • पॉलिसी में बदलाव: संगठन AI-असिस्टेड कोडिंग के लिए दिशा-निर्देशों को औपचारिक रूप दे सकते हैं, जिसमें CI पाइपलाइन के हिस्से के रूप में सीक्रेट-मैनेजमेंट चेक अनिवार्य हों।
  • कम्युनिटी पैटर्न: जैसे-जैसे डेवलपर्स अधिक "सुरक्षित प्रॉम्प्ट" साझा करेंगे, टोकन साइनिंग या ईमेल डिलीवरी जैसे सामान्य कार्यों के लिए बेस्ट-प्रैक्टिस टेम्पलेट्स डिफ़ॉल्ट आउटपुट बन सकते हैं।

मुख्य बात: AI कुछ ही सेकंड में functional code तैयार कर सकता है, लेकिन जब तक डेवलपर्स secret-management अनुशासन लागू नहीं करते, इस सुविधा की एक छिपी हुई कीमत होती है—उजागर क्रेडेंशियल्स जो पूरे सिस्टम को खतरे में डाल सकते हैं। हर स्निपेट को एक ड्राफ्ट की तरह मानें, किसी भी वास्तविक सीक्रेट्स को हटा दें, और कमिट करने से पहले उन्हें environment variables या किसी समर्पित vault के माध्यम से इंजेक्ट करें।