BrassCoders তাদের পরীক্ষা করা পনেরটি AI-জেনারেটেড পাইথন স্ক্রিপ্টের মধ্যে দুটিতে হার্ড-কোডেড সিক্রেট (hard-coded secrets) খুঁজে পেয়েছে, যা সরাসরি লার্জ ল্যাঙ্গুয়েজ মডেলের আউটপুট থেকে কোড কপি-পেস্ট করা ডেভেলপারদের জন্য একটি বাস্তব ঝুঁকি প্রকাশ করে। এই ফলাফলগুলো দেখায় যে একটি মাত্র ভুল স্থানে রাখা কী (key) বা পাসওয়ার্ড একটি সহায়ক স্নিপেটকে ভার্সন কন্ট্রোল এবং প্রোডাকশন এনভায়রনমেন্ট জুড়ে ক্রেডেনশিয়াল লিকের (credential leak) কারণ করে তুলতে পারে।

পরীক্ষাটি যা প্রকাশ করেছে

প্রথম স্ক্রিপ্টটি, token_check.py, একটি প্রম্পট থেকে তৈরি করা হয়েছিল যেখানে একটি সেশন টোকেন সাইন করার এবং একটি “ব্যবহারযোগ্য উদাহরণ” (usable example) অন্তর্ভুক্ত করার ফাংশন চাওয়া হয়েছিল। কোডটি চালানোর উপযোগী করার জন্য, মডেলটি সরাসরি সোর্স ফাইলে একটি লিটারেল HMAC সাইনিং কী (HMAC signing key) বসিয়ে দেয়।

  • সমস্যা: সিক্রেট কী-টি কোডবেসের মধ্যেই রয়েছে।
  • ঝুঁকি: রিপোজিটরিতে রিড অ্যাক্সেস (read access) আছে এমন যে কেউ কী-টি দেখতে পারে, এবং যে কোনো ডিপ্লয়মেন্ট যা ফাইলটি ব্যবহার করে তা এই সিক্রেটটি উত্তরাধিকারসূত্রে পেয়ে যায়।
  • পরিণতি: একজন আক্রমণকারী যদি কী-টি পেয়ে যায়, তবে সে বৈধ সেশন টোকেন তৈরি (forge) করতে পারে, যা অথেন্টিকেশন চেক বাইপাস করে দেয়।

দ্বিতীয় স্ক্রিপ্টটি, email_sender.py, SMTP-এর মাধ্যমে ইমেল পাঠানোর একটি ফাংশনের অনুরোধের উত্তর দিয়েছিল। মডেলটি আবারও একটি লিটারেল পাসওয়ার্ড সরবরাহ করেছে যাতে উদাহরণটি সরাসরি কাজ করে।

  • সমস্যা: ফাংশন কলের মধ্যে পাসওয়ার্ডটি একটি প্লেইন-টেক্সট স্ট্রিং হিসেবে দেখা যায়।
  • ঝুঁকি: পাসওয়ার্ড পরিবর্তন (rotate) করতে কোড পরিবর্তন এবং নতুন ডিপ্লয়মেন্টের প্রয়োজন হয়, এবং এই ক্রেডেনশিয়ালটি ফাইলটি ব্যবহার করে এমন প্রতিটি এনভায়রনমেন্টে ছড়িয়ে পড়ে।
  • পরিণতি: সোর্স কন্ট্রোল, লগ বা কম্পাইল করা প্যাকেজ থেকে পাসওয়ার্ডটি সংগ্রহ করা যেতে পারে, যা একজন আক্রমণকারীকে মেইল সার্ভারে অননুমোদিত অ্যাক্সেস প্রদান করে।

কেন AI সিক্রেট প্রকাশ করে দেয়

লার্জ ল্যাঙ্গুয়েজ মডেলগুলো প্রম্পট সম্পন্ন করার মাধ্যমে টেক্সট তৈরি করে। যখন কোনো ব্যবহারকারী একটি “ব্যবহারযোগ্য উদাহরণ” চান, মডেলটি সেটিকে “অতিরিক্ত সেটআপ ছাড়াই চলে এমন কোড” হিসেবে ব্যাখ্যা করে। তাই এটি অনুপস্থিত মানগুলো—যেমন API কী, পাসওয়ার্ড, টোকেন—সম্ভাব্য প্লেসহোল্ডার (placeholders) দিয়ে পূরণ করে দেয়। প্রম্পটে যদি স্পষ্টভাবে উল্লেখ না থাকে, তবে সিক্রেট-ম্যানেজমেন্টের সেরা অনুশীলনগুলো সম্পর্কে মডেলের কোনো ধারণা থাকে না।

AI-জেনারেটেড কোডের একটি সাম্প্রতিক Veracode বিশ্লেষণ থেকে দেখা গেছে যে, ৪৫% স্নিপেটে OWASP Top 10-এ তালিকাভুক্ত অন্তত একটি দুর্বলতা রয়েছে, যেখানে ক্রেডেনশিয়াল এক্সপোজার (credential exposure) একটি বড় অংশ দখল করে আছে। এই পরিসংখ্যানটি জোর দিয়ে বলে যে, সমস্যাটি কেবল কিছু বিচ্ছিন্ন ঘটনার মধ্যে সীমাবদ্ধ নয়; এটি এই মডেলগুলো কীভাবে প্রশিক্ষিত এবং প্রম্পট করা হয় তার একটি পদ্ধতিগত উপজাত (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 ব্যবহার করলে এটি রানটাইম এনভায়রনমেন্ট থেকে মানটি সংগ্রহ করে, যা এটিকে ভার্সন কন্ট্রোলের বাইরে রাখে এবং সোর্স ফাইল স্পর্শ না করেই পাসওয়ার্ড পরিবর্তন করার সুযোগ দেয়। একই প্যাটার্ন কনফিগারেশন ফাইল (যা কমিট থেকে বাদ দেওয়া হয়েছে), সিক্রেট-ম্যানেজমেন্ট সার্ভিস বা কন্টেইনার-অরকেস্ট্রেটেড সিক্রেটের ক্ষেত্রেও কাজ করে।

অতিরিক্ত সুরক্ষা ব্যবস্থা

  • কোড রিভিউ (Code reviews) যা সাধারণ সিক্রেট প্যাটার্নের সাথে মিলে যায় এমন লিটারেল স্ট্রিংগুলোকে (যেমন: দীর্ঘ আলফানিউমেরিক সিকোয়েন্স) চিহ্নিত করে।
  • স্ট্যাটিক অ্যানালাইসিস টুলস (Static analysis tools) যা নতুন যুক্ত করা ফাইলগুলোতে হার্ড-কোডেড ক্রেডেনশিয়াল শনাক্ত করার জন্য টিউন করা হয়েছে।
  • প্রম্পট ইঞ্জিনিয়ারিং (Prompt engineering): মডেলকে স্পষ্টভাবে বলুন “সব সিক্রেটের জন্য এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করো” অথবা “আসল ক্রেডেনশিয়াল বাদ দাও।”
  • পোস্ট-জেনারেশন লিন্টিং (Post-generation linting): প্রজেক্টে কোড কপি করার আগে সন্দেহজনক লিটারেল খোঁজার জন্য একটি দ্রুত স্ক্রিপ্ট চালান।

পাল্টা যুক্তি: এর মানে কি AI কোড অনিরাপদ?

হার্ড-কোডেড সিক্রেটের উপস্থিতি মানে এই নয় যে AI-জেনারেটেড কোড সর্বজনীনভাবে অনিরাপদ। অনেক ক্ষেত্রে, মডেলটি পরিষ্কার এবং সুগঠিত লজিক তৈরি করে যা ডেভেলপমেন্টের গতি বাড়াতে পারে। ঝুঁকি তখনই তৈরি হয় যখন ডেভেলপাররা কোনো সিকিউরিটি অডিট ছাড়াই আউটপুটটিকে প্রোডাকশন-রেডি হিসেবে বিবেচনা করেন। AI-কে একটি ড্রাফটিং অ্যাসিস্ট্যান্ট হিসেবে বিবেচনা করুন, প্রতিষ্ঠিত সিকিউরিটি প্র্যাকটিসের বিকল্প হিসেবে নয়।

পরবর্তীতে যা খেয়াল রাখতে হবে

  • টুলিং আপডেট (Tooling updates): AI প্ল্যাটফর্মগুলো সিক্রেটগুলোকে প্লেসহোল্ডার দিয়ে প্রতিস্থাপন করার জন্য সেফটি ফিল্টার অন্তর্ভুক্ত করতে শুরু করেছে। এই পরিবর্তনগুলো পর্যবেক্ষণ করলে ঝুঁকি কমানো সম্ভব।
  • পলিসি পরিবর্তন (Policy shifts): সংস্থাগুলো AI-সহায়তা প্রাপ্ত কোডিংয়ের জন্য নির্দেশিকা আনুষ্ঠানিক করতে পারে, যেখানে CI পাইপলাইনের অংশ হিসেবে সিক্রেট-ম্যানেজমেন্ট চেক বাধ্যতামূলক করা হবে।
  • কমিউনিটি প্যাটার্ন (Community patterns): ডেভেলপাররা যখন আরও বেশি “সিকিউর প্রম্পট” শেয়ার করবেন, তখন টোকেন সাইনিং বা ইমেল ডেলিভারির মতো সাধারণ কাজের জন্য বেস্ট-প্র্যাকটিস টেমপ্লেটগুলো ডিফল্ট আউটপুট হয়ে উঠতে পারে।

সারকথা: AI কয়েক সেকেন্ডের মধ্যেই কার্যকরী কোড তৈরি করতে পারে, কিন্তু ডেভেলপাররা যদি সিক্রেট-ম্যানেজমেন্টের শৃঙ্খলা বজায় না রাখেন, তবে এই সুবিধার একটি লুকানো মূল্য রয়েছে—প্রকাশিত ক্রেডেনশিয়াল যা একটি পুরো সিস্টেমকে ঝুঁকির মুখে ফেলতে পারে। প্রতিটি স্নিপেটকে একটি খসড়া হিসেবে বিবেচনা করুন, সরাসরি ব্যবহৃত কোনো সিক্রেট সরিয়ে ফেলুন এবং কমিট করার আগে এনভায়রনমেন্ট ভেরিয়েবল বা একটি ডেডিকেটেড ভল্টের মাধ্যমে সেগুলো ইনজেক্ট করুন।