BrassCoders ने त्यांनी तपासलेल्या पंधरा AI-जनरेटेड पायथन स्क्रिप्ट्सपैकी दोनमध्ये हार्ड-कोडेड सीक्रेट्स (hard-coded secrets) शोधले आहेत, ज्यामुळे लार्ज लँग्वेज मॉडेलच्या आउटपुटमधून थेट कोड कॉपी-पेस्ट करणाऱ्या डेव्हलपर्ससाठी एक ठोस धोका निर्माण झाला आहे. या निष्कर्षांवरून असे दिसून येते की, एक चुकीची की (key) किंवा पासवर्ड संपूर्ण व्हर्जन कंट्रोल आणि प्रोडक्शन एन्व्हायरमेंटमध्ये क्रेडेंशियल लीक (credential leak) करण्यास कारणीभूत ठरू शकतो.

चाचणीतून काय समोर आले

पहिली स्क्रिप्ट, token_check.py, एका अशा प्रॉम्प्टमधून तयार करण्यात आली होती ज्यामध्ये सेशन टोकन्स साइन करण्यासाठी आणि एक “वापरण्यायोग्य उदाहरण” (usable example) समाविष्ट करण्यासाठी फंक्शन मागितले होते. कोड रन करण्यायोग्य बनवण्यासाठी, मॉडेलने सोर्स फाईलमध्ये थेट HMAC साइनिंग की टाकली होती.

  • समस्या: सीक्रेट की कोडबेसमध्येच आहे.
  • धोका: रिपॉझिटरीला रीड ॲक्सेस असलेल्या कोणालाही ही की दिसू शकते, आणि ही फाईल वापरणारे कोणतेही डिप्लॉयमेंट त्या सीक्रेटला वारसा म्हणून प्राप्त करते.
  • परिणाम: ज्या अटॅकरला ही की मिळते, तो वैध सेशन टोकन्स तयार करू शकतो आणि ऑथेंटिकेशन चेक बायपास करू शकतो.

दुसरी स्क्रिप्ट, email_sender.py, SMTP द्वारे ईमेल पाठवणाऱ्या फंक्शनच्या विनंतीला उत्तर देत होती. मॉडेलने पुन्हा एकदा प्रत्यक्ष पासवर्ड दिला जेणेकरून उदाहरण लगेच काम करेल.

  • समस्या: फंक्शन कॉलमध्ये पासवर्ड प्लेन-टेक्स्ट स्ट्रिंग म्हणून दिसतो.
  • धोका: पासवर्ड बदलण्यासाठी कोडमध्ये बदल आणि नवीन डिप्लॉयमेंट आवश्यक असते, आणि हे क्रेडेंशियल फाईल वापरणाऱ्या प्रत्येक एन्व्हायरमेंटमध्ये पसरते.
  • परिणाम: सोर्स कंट्रोल, लॉग्स किंवा कंपाईल केलेल्या पॅकेजेसमधून पासवर्ड चोरला जाऊ शकतो, ज्यामुळे एखाद्या शत्रूला मेल सर्व्हरचा अनधिकृत प्रवेश मिळू शकतो.

AI सीक्रेट्स का देते

लार्ज लँग्वेज मॉडेल्स प्रॉम्प्ट पूर्ण करून मजकूर तयार करतात. जेव्हा एखादा वापरकर्ता “वापरण्यायोग्य उदाहरण” मागतो, तेव्हा मॉडेल त्याचा अर्थ “असा कोड जो अतिरिक्त सेटअपशिवाय चालतो” असा करते. त्यामुळे ते API कीज, पासवर्ड्स, टोकन्स यांसारखी गहाळ मूल्ये संभाव्य प्लेसहोल्डर्सनी भरून काढते. जोपर्यंत प्रॉम्प्टमध्ये स्पष्टपणे उल्लेख केला जात नाही, तोपर्यंत मॉडेलला सीक्रेट-मॅनेजमेंटच्या सर्वोत्तम पद्धतींची (best practices) जाणीव नसते.

AI-जनरेटेड कोडच्या अलीकडील Veracode विश्लेषणामध्ये असे आढळले की 45% स्निपेट्समध्ये OWASP Top 10 मध्ये सूचीबद्ध किमान एक त्रुटी (vulnerability) आहे, ज्यामध्ये क्रेडेंशियल एक्सपोजरचा वाटा मोठा आहे. ही आकडेवारी अधोरेखित करते की ही समस्या केवळ काही अपवादांपुरती मर्यादित नाही; तर ही मॉडेल्स कशा प्रकारे प्रशिक्षित आणि प्रॉम्प्ट केली जातात याचा एक प्रणालीगत परिणाम आहे.

डेव्हलपर्स आता कोणती प्रतिबंधात्मक पावले उचलू शकतात

सर्वात सोपा बचाव म्हणजे कोणत्याही सीक्रेटला कोड फाईलपासून दूर ठेवणे. एन्व्हायरमेंट व्हेरिएबल्स (Environment variables) ही सर्वात सामान्य आणि कोणत्याही भाषेसाठी लागू होणारी पद्धत आहे:

# 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 वापरल्याने रनटाइम एन्व्हायरमेंटमधून व्हॅल्यू घेतली जाते, ज्यामुळे ती व्हर्जन कंट्रोलपासून दूर राहते आणि सोर्स फाईल्सना स्पर्श न करता ती बदलणे (rotation) शक्य होते. हीच पद्धत कमिट्समधून वगळलेल्या कॉन्फिगरेशन फाईल्स, सीक्रेट-मॅनेजमेंट सर्व्हिसेस किंवा कंटेनर-ऑर्केस्ट्रेटेड सीक्रेट्ससोबतही काम करते.

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

  • कोड रिव्ह्यू (Code reviews) जे सामान्य सीक्रेट पॅटर्नशी जुळणाऱ्या स्ट्रिंग्सना (उदा. लांब अल्फान्यूमेरिक सिक्वेन्स) फ्लॅग करतात.
  • स्टॅटिक अनालिसिस टूल्स (Static analysis tools) जे नवीन जोडलेल्या फाईल्समधील हार्ड-कोडेड क्रेडेंशियल्स शोधण्यासाठी ट्यून केलेले आहेत.
  • प्रॉम्प्ट इंजिनीअरिंग (Prompt engineering): मॉडेलला स्पष्टपणे “सर्व सीक्रेट्ससाठी एन्व्हायरमेंट व्हेरिएबल्स वापरा” किंवा “खरे क्रेडेंशियल्स वगळा” असे सांगणे.
  • पोस्ट-जनरेशन लिंटिंग (Post-generation linting): कोड प्रोजेक्टमध्ये कॉपी करण्यापूर्वी संशयास्पद स्ट्रिंग्स शोधण्यासाठी एक क्विक स्क्रिप्ट चालवणे.

प्रतिवाद: याचा अर्थ AI कोड असुरक्षित आहे का?

हार्ड-कोडेड सीक्रेट्स असण्याचा अर्थ असा नाही की AI-जनरेटेड कोड सार्वत्रिकपणे असुरक्षित आहे. अनेक प्रकरणांमध्ये, मॉडेल स्वच्छ आणि सुव्यवस्थित लॉजिक तयार करते जे डेव्हलपमेंटचा वेग वाढवू शकते. धोका तेव्हा निर्माण होतो जेव्हा डेव्हलपर्स सुरक्षा ऑडिट न करता आउटपुटला 'प्रोडक्शन-रेडी' मानतात. AI कडे एक ड्राफ्टिंग असिस्टंट म्हणून पहा, स्थापित सुरक्षा पद्धतींचा पर्याय म्हणून नाही.

पुढे काय पाहावे

  • टूलिंग अपडेट्स (Tooling updates): AI प्लॅटफॉर्म्स आता सुरक्षा फिल्टर्स समाविष्ट करण्यास सुरुवात करत आहेत जे सीक्रेट्सना प्लेसहोल्डर्सनी बदलतात. त्या बदलांवर लक्ष ठेवल्यास धोका कमी होऊ शकतो.
  • धोरणात्मक बदल (Policy shifts): संस्था AI-असिस्टेड कोडिंगसाठी मार्गदर्शक तत्त्वे औपचारिक करू शकतात, ज्यामध्ये CI पाइपलाइनचा भाग म्हणून सीक्रेट-मॅनेजमेंट चेक अनिवार्य केले जातील.
  • कम्युनिटी पॅटर्न (Community patterns): डेव्हलपर्स अधिक “सुरक्षित प्रॉम्प्ट्स” शेअर करत असताना, टोकन साइनिंग किंवा ईमेल डिलिव्हरी यांसारख्या सामान्य कामांसाठी बेस्ट-प्रॅक्टिस टेम्पलेट्स डीफॉल्ट आउटपुट बनू शकतात.

मुख्य निष्कर्ष: AI काही सेकंदात functional code तयार करू शकते, परंतु जोपर्यंत डेव्हलपर्स सिक्रेट-मॅनेजमेंट शिस्त पाळत नाहीत, तोपर्यंत या सुविधेसोबत एक छुपा धोका येतो—उघड झालेले credentials जे संपूर्ण सिस्टमला धोक्यात आणू शकतात. प्रत्येक snippet ला एक मसुदा समजा, त्यातील सर्व प्रत्यक्ष secrets काढून टाका आणि commit करण्यापूर्वी ते environment variables किंवा समर्पित vault द्वारे समाविष्ट करा.