BrassCoders தாங்கள் ஆய்வு செய்த பதினைந்து AI-ஆல் உருவாக்கப்பட்ட Python ஸ்கிரிப்ட்களில் இரண்டில், குறியீட்டிற்குள்ளேயே எழுதப்பட்ட ரகசியத் தகவல்களைக் (hard-coded secrets) கண்டறிந்துள்ளனர். இது பெரிய மொழி மாதிரிகளின் (large language model) வெளியீடுகளை அப்படியே நகலெடுத்துப் பயன்படுத்தும் டெவலப்பர்களுக்கு ஒரு நேரடி ஆபத்தை வெளிப்படுத்துகிறது. ஒரு தவறான சாவி (key) அல்லது கடவுச்சொல் (password), ஒரு பயனுள்ள குறியீட்டுத் துண்டை (code snippet), பதிப்புக்கட்டுப்பாட்டு (version control) மற்றும் உற்பத்திச் சூழல்களில் (production environments) ரகசியத் தகவல் கசிவு ஏற்படும் இடமாக மாற்றிவிடும் என்பதை இந்த கண்டுபிடிப்புகள் காட்டுகின்றன.

சோதனை எதை வெளிப்படுத்தியது

முதல் ஸ்கிரிப்ட், token_check.py, ஒரு அமர்வு டோக்கன்களை (session tokens) கையொப்பமிடவும் மற்றும் ஒரு “பயன்படுத்தக்கூடிய உதாரணத்தை” (usable example) சேர்க்கவும் கோரும் ஒரு ப்ராம்ப்ட்டிலிருந்து உருவாக்கப்பட்டது. குறியீட்டை இயக்கக்கூடியதாக மாற்ற, அந்த மாதிரி (model) ஒரு நேரடி HMAC கையொப்பச் சாவியை (signing key) நேரடியாக மூலக் கோப்பிலேயே (source file) சேர்த்தது.

  • சிக்கல்: ரகசியச் சாவி குறியீட்டுத் தளத்திலேயே (code base) உள்ளது.
  • அபாயம்: களஞ்சியத்தைப் (repository) படிக்கும் உரிமை கொண்ட எவரும் அந்தச் சாவியைப் பார்க்க முடியும், மேலும் அந்தப் கோப்பைப் பயன்படுத்தும் எந்தவொரு பயன்பாடும் (deployment) அந்த ரகசியத்தைப் பெற்றுக்கொள்ளும்.
  • விளைவு: அந்தச் சாவியைப் பெறும் ஒரு தாக்குதல் நடத்துபவர் (attacker), செல்லுபடியாகும் அமர்வு டோக்கன்களைப் போலியாக உருவாக்கி, அங்கீகாரச் சோதனைகளைத் (authentication checks) தவிர்க்க முடியும்.

இரண்டாவது ஸ்கிரிப்ட், email_sender.py, SMTP மூலம் மின்னஞ்சல் அனுப்பும் ஒரு செயல்பாட்டிற்கான (function) கோரிக்கைக்குப் பதிலளித்தது. அந்த உதாரணம் உடனடியாகச் செயல்படுவதற்காக, அந்த மாதிரி மீண்டும் ஒரு நேரடி கடவுச்சொல்லை வழங்கியது.

  • சிக்கல்: கடவுச்சொல் அந்தச் செயல்பாட்டின் அழைப்பில் (function call) ஒரு சாதாரண உரைச் சரமாக (plain-text string) தோன்றுகிறது.
  • அபாயம்: கடவுச்சொல்லை மாற்ற வேண்டுமானால், குறியீட்டில் மாற்றம் செய்து புதிய பயன்பாட்டை (deployment) உருவாக்க வேண்டும்; மேலும் அந்தத் தகவல் அந்தப் கோப்பைப் பயன்படுத்தும் ஒவ்வொரு சூழலுக்கும் பரவுகிறது.
  • விளைவு: மூலக் கட்டுப்பாடு (source control), பதிவுகள் (logs) அல்லது தொகுக்கப்பட்ட தொகுப்புகள் (compiled packages) ஆகியவற்றிலிருந்து கடவுச்சொல்லைத் திருட முடியும், இது ஒரு எதிரிக்கு மின்னஞ்சல் சேவையகத்திற்கு (mail server) அங்கீகரிக்கப்படாத அணுகலை வழங்கும்.

AI ஏன் ரகசியத் தகவல்களை வெளியிடுகிறது

பெரிய மொழி மாதிரிகள் ப்ராம்ப்ட்டை நிறைவு செய்வதன் மூலம் உரையை உருவாக்குகின்றன. ஒரு பயனர் “பயன்படுத்தக்கூடிய உதாரணம்” என்று கேட்கும்போது, அந்த மாதிரி அதை “கூடுதல் அமைப்புகள் இன்றி இயங்கக்கூடிய குறியீடு” என்று புரிந்துகொள்கிறது. எனவே, அது விடுபட்ட மதிப்புகளை—API சாவிகள், கடவுச்சொற்கள், டோக்கன்கள்—நம்பகமான இடப்பொறிகளாக (placeholders) நிரப்புகிறது. ப்ராம்ப்ட்டில் ரகசிய மேலாண்மை சிறந்த நடைமுறைகள் (secret-management best practices) பற்றித் தெளிவாகக் குறிப்பிடாதவரை, அந்த மாதிரிக்கு அது குறித்த விழிப்புணர்வு இருக்காது.

AI-ஆல் உருவாக்கப்பட்ட குறியீட்டைப் பற்றிய சமீபத்திய Veracode பகுப்பாய்வு, 45% குறியீட்டுத் துண்டுகளும் OWASP Top 10-இல் பட்டியலிடப்பட்ட குறைந்தது ஒரு பாதிப்பைக் கொண்டுள்ளன என்பதைக் கண்டறிந்துள்ளது, இதில் ரகசியத் தகவல் வெளிப்படுவது ஒரு குறிப்பிடத்தக்கப் பங்காகும். இந்த புள்ளிவிவரம், இந்தப் பிரச்சனை ஒரு சில நிகழ்வுகளில் மட்டும் நடப்பதல்ல; இது இந்த மாதிரிகள் எவ்வாறு பயிற்சியளிக்கப்பட்டன மற்றும் ப்ராம்ப்ட் செய்யப்பட்டன என்பதன் ஒரு முறையான துணைவிளைவு (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-ஐப் பயன்படுத்துவதன் மூலம், மதிப்பை இயங்கும் சூழலில் (runtime environment) இருந்து எடுக்க முடியும், இது அதை பதிப்புக்கட்டுப்பாட்டிற்கு வெளியே வைத்திருப்பதோடு, மூலக் கோப்புகளைத் தொடாமலேயே ரகசியங்களை மாற்றிக்கொள்ளவும் (rotation) அனுமதிக்கிறது. இதே முறையை கமிட்களில் (commits) சேர்க்கப்படாத உள்ளமைவு கோப்புகள் (configuration files), ரகசிய மேலாண்மை சேவைகள் அல்லது கண்டெய்னர்-ஒர்கஸ்ட்ரேட்டட் ரகசியங்களுடன் (container-orchestrated secrets) பயன்படுத்தலாம்.

கூடுதல் பாதுகாப்பு நடவடிக்கைகள்

  • பொதுவான ரகசிய வடிவங்களுடன் (உதாரணமாக, நீண்ட அன்-அல்ஃபாநியூமெரிக் தொடர்கள்) பொருந்தக்கூடிய உரைச் சரங்களைக் கண்டறியும் குறியீடு ஆய்வுகள் (Code reviews).
  • புதிதாகச் சேர்க்கப்பட்ட கோப்புகளில் குறியீட்டிற்குள்ளேயே எழுதப்பட்ட சான்றுகளைக் கண்டறிய வடிவமைக்கப்பட்ட நிலையான பகுப்பாய்வுக் கருவிகள் (Static analysis tools).
  • ப்ராம்ப்ட் இன்ஜினியரிங் (Prompt engineering): “அனைத்து ரகசியங்களுக்கும் சூழல் மாறிகளைப் பயன்படுத்து” அல்லது “உண்மையான சான்றுகளைத் தவிர்க்கவும்” என்று மாதிரியிடம் தெளிவாகக் கேட்கவும்.
  • உருவாக்கப்பட்ட பின் செய்யப்படும் லின்டிங் (Post-generation linting): குறியீட்டை ஒரு திட்டத்திற்குள் நகலெடுப்பதற்கு முன், சந்தேகத்திற்கிடமான தரவுகளைத் தேடும் ஒரு விரைவான ஸ்கிரிப்டை இயக்கவும்.

எதிர்முனை: இதன் பொருள் AI குறியீடு பாதுகாப்பற்றது என்பதா?

குறியீட்டிற்குள்ளேயே எழுதப்பட்ட ரகசியங்கள் இருப்பது, AI-ஆல் உருவாக்கப்பட்ட குறியீடு உலகளாவிய ரீதியில் பாதுகாப்பற்றது என்பதைக் குறிக்காது. பல சந்தர்ப்பங்களில், அந்த மாதிரி விரைவான மேம்பாட்டிற்கு உதவும் வகையில் சுத்தமான, நன்கு கட்டமைக்கப்பட்ட தர்க்கத்தை (logic) உருவாக்குகிறது. டெவலப்பர்கள் பாதுகாப்பு தணிக்கை (security audit) செய்யாமல், வெளியீட்டைத் தயாரிப்பு நிலைக்குத் தயாரானது (production-ready) என்று கருதும் போதுதான் ஆபத்து உருவாகிறது. AI-ஐ ஒரு வரைவு உதவியாளராகக் கருதுங்கள், நிறுவப்பட்ட பாதுகாப்பு நடைமுறைகளுக்கு மாற்றாகக் கருத வேண்டாம்.

அடுத்து கவனிக்க வேண்டியவை

  • கருவிகளின் மேம்பாடுகள் (Tooling updates): AI தளங்கள் ரகசியங்களுக்குப் பதிலாக இடப்பொறிகளைப் பயன்படுத்தும் பாதுகாப்பு வடிகட்டிகளை (safety filters) இணைக்கத் தொடங்கியுள்ளன. அந்த மாற்றங்களைக் கண்காணிப்பது பாதிப்பைக் குறைக்க உதவும்.
  • கொள்கை மாற்றங்கள் (Policy shifts): நிறுவனங்கள் AI-உதவி பெற்ற குறியீட்டு முறைக்கான வழிகாட்டுதல்களை முறைப்படுத்தலாம், மேலும் CI பைப்லைனின் ஒரு பகுதியாக ரகசிய மேலாண்மை சோதனைகளைக் கட்டாயமாக்கலாம்.
  • சமூக முறைகள் (Community patterns): டெவலப்பர்கள் அதிகப்படியான “பாதுகாப்பான ப்ராம்ப்ட்களை” (secure prompts) பகிர்ந்து கொள்ளும்போது, டோக்கன் கையொப்பம் அல்லது மின்னஞ்சல் விநியோகம் போன்ற பொதுவான பணிகளுக்கான சிறந்த நடைமுறை டெம்ப்ளேட்டுகள் இயல்பான வெளியீடாக மாறக்கூடும்.

முக்கியக் கருத்து: AI சில நொடிகளில் செயல்படக்கூடிய குறியீட்டை (code) உருவாக்க முடியும், ஆனால் டெவலப்பர்கள் ரகசிய மேலாண்மை (secret-management) ஒழுக்கத்தை நடைமுறைப்படுத்தாவிட்டால், இந்த வசதி ஒரு மறைமுகமான விலையுடன் வரும்—அதாவது, முழு அமைப்பையும் (system) பாதிக்கும் வகையில் வெளிப்படும் சான்றுகள் (credentials). ஒவ்வொரு குறியீட்டுத் துண்டையும் (snippet) ஒரு வரைவாகவே கருதுங்கள், அதில் உள்ள நேரடி ரகசியங்களை நீக்கிவிட்டு, அவற்றை commit செய்வதற்கு முன் environment variables அல்லது ஒரு பிரத்யேக vault மூலம் உள்ளிடுங்கள்.