BrassCoders در دو مورد از پانزده اسکریپت پایتون تولیدشده توسط هوش مصنوعی که بررسی کرده بودند، اسرار جاسازی‌شده در کد (hard-coded secrets) را کشف کرد؛ موضوعی که ریسک ملموسی را برای توسعه‌دهندگانی که کدها را مستقیماً از خروجی مدل‌های زبانی بزرگ کپی و پیست می‌کنند، به همراه دارد. این یافته‌ها نشان می‌دهند که تنها یک کلید یا رمز عبور اشتباه در جای خود، می‌تواند یک قطعه کد مفید را به یک نشت اعتبارنامه (credential leak) در محیط‌های کنترل نسخه و عملیاتی تبدیل کند.

آنچه این آزمایش فاش کرد

اسکریپت اول، token_check.py، از طریق پرامپتی تولید شده بود که از مدل خواسته بود تابعی برای امضای توکن‌های نشست (session tokens) و گنجاندن یک «مثال قابل استفاده» ارائه دهد. مدل برای اینکه کد قابل اجرا باشد، یک کلید امضای HMAC واقعی را مستقیماً در فایل منبع قرار داده بود.

  • مشکل: کلید مخفی در بدنه کد قرار دارد.
  • ریسک: هر کسی که دسترسی خواندن به مخزن (repository) داشته باشد، می‌تواند کلید را ببیند و هر استقرار (deployment) که این فایل را فراخوانی کند، آن راز را نیز با خود حمل می‌کند.
  • پیامد: مهاجمی که کلید را به دست آورد، می‌تواند توکن‌های نشست معتبر را جعل کرده و بررسی‌های احراز هویت را دور بزند.

اسکریپت دوم، email_sender.py، در پاسخ به درخواستی برای تابعی که ایمیل را از طریق SMTP ارسال می‌کند، ساخته شده بود. مدل بار دیگر یک رمز عبور واقعی را ارائه داد تا مثال به‌صورت آماده و بدون تنظیمات اضافی کار کند.

  • مشکل: رمز عبور به صورت یک رشته متنی ساده (plain-text) در فراخوانی تابع ظاهر می‌شود.
  • ریسک: تغییر (چرخش) رمز عبور مستلزم تغییر کد و استقرار مجدد است، و این اعتبارنامه در هر محیطی که از این فایل استفاده می‌کند، پخش می‌شود.
  • پیامد: رمز عبور می‌تواند از کنترل نسخه، لاگ‌ها یا بسته‌های کامپایل‌شده استخراج شود و به مهاجم اجازه دسترسی غیرمجاز به سرور ایمیل را بدهد.

چرا هوش مصنوعی اسرار را تولید می‌کند

مدل‌های زبانی بزرگ با تکمیل کردن پرامپت، متن تولید می‌کنند. وقتی کاربر درخواست یک «مثال قابل استفاده» را می‌کند، مدل آن را به معنای «کدی که بدون تنظیمات اضافی اجرا شود» تفسیر می‌کند. بنابراین، مقادیر مفقود — مانند کلیدهای API، رمزهای عبور و توکن‌ها — را با جایگزین‌های (placeholders) باورپذیر پر می‌کند. مدل هیچ آگاهی از بهترین شیوه‌های مدیریت اسرار (secret-management) ندارد، مگر اینکه در پرامپت صراحتاً به آن‌ها اشاره شود.

یک تحلیل اخیر Veracode از کدهای تولیدشده توسط هوش مصنوعی نشان داد که ۴۵٪ از قطعه‌کدها حداقل شامل یک آسیب‌پذیری موجود در لیست OWASP Top 10 هستند که نشت اعتبارنامه‌ها بخش قابل توجهی از آن را تشکیل می‌دهد. این آمار تأکید می‌کند که این مشکل محدود به چند مورد استثنایی نیست؛ بلکه یک محصول جانبی سیستماتیک از نحوه آموزش و پرامپت‌نویسی این مدل‌ها است.

اقدامات اصلاحی که توسعه‌دهندگان می‌توانند اکنون انجام دهند

ساده‌ترین راه دفاعی این است که هرگونه راز را از خودِ فایل کد دور نگه دارید. متغیرهای محیطی (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 مقدار را از محیط زمان اجرا (runtime environment) فراخوانی می‌کند، آن را از کنترل نسخه دور نگه می‌دارد و امکان تغییر رمز عبور را بدون دست زدن به فایل‌های منبع فراهم می‌کند. همین الگو در مورد فایل‌های پیکربندی که از کامیت‌ها مستثنی شده‌اند، سرویس‌های مدیریت اسرار، یا اسرار مدیریت‌شده توسط ارکستراتورهای کانتینر نیز کاربرد دارد.

اقدامات حفاظتی تکمیلی

  • بازبینی کد (Code reviews): که رشته‌های متنی مطابق با الگوهای رایج اسرار (مثلاً توالی‌های طولانی الفبایی-عددی) را علامت‌گذاری کنند.
  • ابزارهای تحلیل ایستا (Static analysis tools): تنظیم‌شده برای شناسایی اعتبارنامه‌های جاسازی‌شده در فایل‌های جدید اضافه شده.
  • مهندسی پرامپت (Prompt engineering): صراحتاً از مدل بخواهید که «از متغیرهای محیطی برای تمام اسرار استفاده کند» یا «اعتبارنامه‌های واقعی را حذف کند».
  • لینتینگ پس از تولید (Post-generation linting): اجرای یک اسکریپت سریع که قبل از کپی کردن کد در پروژه، به دنبال رشته‌های مشکوک بگردد.

دیدگاه مقابل: آیا این بدان معناست که کد هوش مصنوعی ناامن است؟

وجود اسرار جاسازی‌شده در کد به این معنا نیست که کدهای تولیدشده توسط هوش مصنوعی به‌طور کلی ناامن هستند. در بسیاری از موارد، مدل منطقی تمیز و با ساختار خوبی تولید می‌کند که می‌تواند سرعت توسعه را افزایش دهد. ریسک زمانی بروز می‌کند که توسعه‌دهندگان خروجی را بدون ممیزی امنیتی (security audit)، آماده استفاده در محیط عملیاتی (production-ready) تلقی کنند. با هوش مصنوعی مانند یک دستیار پیش‌نویس‌نویس رفتار کنید، نه جایگزینی برای شیوه‌های امنیتی تثبیت‌شده.

آنچه باید در آینده زیر نظر داشت

  • به‌روزرسانی ابزارها: پلتفرم‌های هوش مصنوعی در حال اضافه کردن فیلترهای ایمنی هستند که اسرار را با جایگزین‌ها (placeholders) عوض می‌کنند. نظارت بر این تغییرات می‌تواند میزان قرارگیری در معرض خطر را کاهش دهد.
  • تغییرات در سیاست‌ها: سازمان‌ها ممکن است دستورالعمل‌هایی را برای کدنویسی با کمک هوش مصنوعی رسمی کنند و بررسی‌های مدیریت اسرار را به عنوان بخشی از خط لوله CI الزامی کنند.
  • الگوهای جامعه: با اشتراک‌گذاری بیشتر «پرامپت‌های امن» توسط توسعه‌دهندگان، قالب‌های مبتنی بر بهترین شیوه‌ها می‌تواند به خروجی پیش‌فرض برای وظایف رایجی مانند امضای توکن یا ارسال ایمیل تبدیل شود.

نکته کلیدی: هوش مصنوعی می‌تواند در عرض چند ثانیه کدهای کاربردی تولید کند، اما اگر توسعه‌دهندگان انضباط لازم در مدیریت اسرار را رعایت نکنند، این راحتی با هزینه‌ای پنهان همراه خواهد بود: افشای اعتبارنامه‌هایی که می‌تواند کل سیستم را به مخاطره بیندازد. با هر قطعه کد مانند یک پیش‌نویس برخورد کنید، هرگونه اطلاعات حساس مستقیم را حذف نمایید و پیش از ثبت (commit)، آن‌ها را از طریق متغیرهای محیطی یا یک مخزن اختصاصی (vault) تزریق کنید.