روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ با اینکه فواید دستیارهای هوش مصنوعی در محیط‌های کاری هنوز جای بحث دارد، اما در توسعهٔ نرم‌افزار، این ابزارها با اطمینان بیشتری به کار گرفته می‌شوند. در این حوزه، مدل‌های زبانی بزرگ (LLM) نقش‌های متنوعی ایفا می‌کنند — از بازنویسی و مستندسازی کد گرفته تا ساخت کامل یک اپلیکیشن. با این حال، مشکلات سنتیِ امنیت اطلاعات در فرایند توسعه، حالا با آسیب‌پذیری‌های منحصربه‌فرد مدل‌های هوش مصنوعی ترکیب شده‌اند. در این نقطه تلاقی، تقریباً هر هفته، باگ‌ها و مسائل امنیتیِ جدیدی ظاهر می‌شوند.
کدهای آسیب‌پذیر تولیدشده توسط هوش مصنوعی
وقتی یک مدل زبانی بزرگ کدی تولید می‌کند، ممکن است باگ‌ها یا ضعف‌های امنیتی در آن وجود داشته باشد؛ چرا که این مدل‌ها با داده‌های عمومی موجود در اینترنت آموزش دیده‌اند، از جمله هزاران نمونه کد بی‌کیفیت. در مطالعه اخیر از سوی Veracode مشخص شد که مدل‌های پیشرفته امروزی اکنون در ۹۰ درصد موارد کدی تولید می‌کنند که بدون خطا کامپایل می‌شود؛ در حالی که این رقم تا کمتر از دو سال پیش زیر ۲۰ درصد بود. اما نکته نگران‌کننده این است که امنیت این کدها بهبودی نداشته است و همچنان ۴۵ درصد از کدها دارای آسیب‌پذیری‌هایی از فهرست شناخته‌شده OWASP Top 10 هستند و در این زمینه تغییر محسوسی دیده نمی‌شود.
این تحقیق بیش از ۱۰۰ مدل زبانی محبوب را بررسی کرده و خروجی آنها را در قالب تکه‌کدهایی به زبان‌های Java، Python، C# و JavaScript تحلیل کرده است. بنابراین، چه این مدل‌ها برای تکمیل کد در ابزارهایی مانند Windsurf استفاده شوند و چه برای «وایب‌کدینگ[1]» یا «کدنویسی حسی» در پلت‌فرم‌هایی مانند Loveable، خروجی نهایی باید حتماً تحت آزمون‌های دقیق امنیتی قرار گیرد. با این حال، در عمل این اتفاق به‌ندرت رخ می‌دهد؛ طبق مطالعه‌ای از شرکت Wiz، حدود ۲۰ درصد از اپلیکیشن‌های وایب‌کدشده دارای آسیب‌پذیری‌های جدی یا خطاهای پیکربندی هستند.
نمونه‌هایی از این آسیب‌پذیری‌ها
مثال مشهور این ضعف‌ها، اپلیکیشن دوست‌یابی مخصوص خانم‌ها به نام Tea است که به‌دلیل دو نشت اطلاعات بزرگ بدنام شد. هرچند این برنامه قبل از رواج وایب کدینگ ساخته شده بود و اینکه آیا هوش مصنوعی در این رخداد نقش داشته یا نه، در دادگاه مشخص خواهد شد.
اما در مورد استارتاپ Enrichlead، نقش هوش مصنوعی قطعی است. بنیان‌گذار این پروژه در شبکه‌های اجتماعی با افتخار اعلام کرد که ۱۰۰٪کد پلتفرم خود را با ابزار Cursor AI نوشته و حتی یک خط کد دستی هم در کار نبوده است. تنها چند روز پس از راه‌اندازی، مشخص شد که این پلتفرم پر از حفره‌های امنیتی ابتدایی است — به‌گونه‌ای که هر کاربری می‌توانست به امکانات پولی دسترسی پیدا کند یا داده‌ها را تغییر دهد. پروژه پس از ناتوانی بنیان‌گذار در رفع این باگ‌ها تعطیل شد، هرچند او ناامید نشده و پروژه‌های مبتنی بر حسجدیدی را شروع کرده است.
آسیب‌پذیری‌های رایج در کدهای تولیدشده توسط هوش مصنوعی
با اینکه برنامه‌نویسی با کمک هوش مصنوعی تنها یکی‌دو سال عمر دارد، اما داده‌های کافی برای شناسایی خطاهای رایج آن فراهم شده‌اند. معمول‌ترین اشتباهات عبارت‌اند از:
- نبود اعتبارسنجی ورودی‌ها، فقدان پاک‌سازی ورودی کاربران از کاراکترهای مخرب، و دیگر خطاهای پایه که منجر به آسیب‌پذیری‌های کلاسیکی مثل XSS وSQL injection می‌شوند.
- سخت‌کدنویسی کلیدهای API و اطلاعات محرمانه در صفحات وب، به‌طوری که کاربران بتوانند آنها را در کد مشاهده کنند.
- پیاده‌سازی کامل منطق احراز هویت سمت کاربر، به‌شکلی که در مرورگر اجرا می‌شود و به‌راحتی قابل دور زدن است.
- خطاهای لاگ‌نویسی — از فیلتر ناکافی داده‌ها در لاگ‌ها گرفته تا نبود کامل گزارش‌گیری.
- استفاده از توابع خطرناک و بیشازحد قدرتمند — مدل‌های زبانی برای کوتاه‌ترین راه‌حل بهینه‌سازی شده‌اند، اما این «راه کوتاه» اغلب ناامن است. مثال کلاسیک آن استفاده از تابع eval برای انجام عملیات ریاضی روی ورودی‌های کاربر است که می‌تواند به اجرای کد دلخواه منجر شود.
- استفاده از کتابخانه‌های قدیمی یا غیرواقعی — کدهای تولیدشده توسط AI اغلب به نسخه‌های قدیمی کتابخانه‌ها ارجاع می‌دهند، از APIهای ناامن استفاده می‌کنند، یا حتی سعی می‌کنند کتابخانه‌هایی را وارد کنند که اصلاً وجود ندارند. این مورد به‌ویژه خطرناک است، چرا که مهاجمان می‌توانند یک کتابخانه جعلی با نام مشابه ایجاد کرده و آن را به پروژه وارد کنند.
در یک مطالعه نظام‌مند، کدهای تولیدشده توسط AI با استفاده از فهرست MITRE CWE Top 25 بررسی شدند. رایج‌ترین آسیب‌پذیری‌ها عبارت بودند از:
- CWE-94:تزریق کد
- CWE-78: تزریق فرمان سیستم‌عامل
- CWE-190: سرریز عدد صحیح (integer overflow)
- CWE-306: نبود احراز هویت
- CWE-434: آپلود بدون محدودیت فایل
یک نمونه بارز ازCWE-94، نقض امنیت پلتفرم Nx بود که پیش‌تر به آن پرداختیم. مهاجمان موفق شدند یک ابزار توسعه محبوب را با تروجان آلوده کنند، چون توانستند توکنی را سرقت کنند که امکان انتشار نسخه‌های جدید محصول را می‌داد. این توکن از طریق آسیب‌پذیری ساده‌ای در یک تکه‌کد تولیدشده توسط AI لو رفته بود.
درخواست‌های خطرناک
ضرب‌المثل معروف میان برنامه‌نویسان که می‌گوید: «دقیقاً طبق مشخصات انجام شد»، در کار با دستیارهای هوش مصنوعی هم صدق می‌کند. اگر درخواست (پرامپت) برای تولید یک تابع یا برنامه، مبهم باشد و نکات امنیتی را ذکر نکند، احتمال تولید کدی آسیب‌پذیر به‌طور قابل‌توجهی افزایش می‌یابد.
در مطالعه اختصاصی مشخص شد حتی اشاره‌های عمومی مثل «مطمئن شو که کد از بهترین شیوه‌های امنیتی پیروی می‌کند»، می‌تواند نرخ آسیب‌پذیری‌ها را به نصف کاهش دهد.با این حال، موثرترین راهکار، استفاده از راهنمایی‌های امنیتی دقیق و زبان‌محور است که به فهرست خطاهایMITRE یا OWASP ارجاع می‌دهند. یک مجموعه بزرگ از این دستورالعمل‌ها توسط Wiz Research گردآوری شده و در GitHub در دسترس است. توصیه می‌شود این فایل‌ها به‌عنوان «دستورهای سیستمی» به دستیارهای هوش مصنوعی اضافه شوند، از جمله در فایل‌هایی مانند claude.md، .windsurfrules یا فایل‌های مشابه.
افت امنیت در بازبینی‌های متوالی
وقتی کد تولیدشده توسط هوش مصنوعی بارها و بارها از طریق پرامپت‌های اصلاحی بازنویسی می‌شود، سطح امنیتی آن کاهش می‌یابد. در یک مطالعه جدید، مدل GPT-4o تا ۴۰بار یک قطعه کد را بازنویسی کرد، و پژوهشگران پس از هر مرحله، کد را از نظر آسیب‌پذیری بررسی کردند.
فقط پس از پنج تکرار، کد دارای ۳۷٪ آسیب‌پذیری بحرانی بیشتر نسبت به نسخه اولیه شد.
در این تحقیق، چهار استراتژی مختلف برای پرامپت‌گذاری آزمایش شدند:
- تمرکز بر کارایی
- تمرکز بر امنیت،
- تمرکز بر افزودن قابلیت جدید،
- و یک نمونه با پرامپت‌های نامشخص و مبهم.
وقتی تمرکز روی اضافه‌کردن ویژگی‌های جدید بود، ۱۵۸آسیب‌پذیری جدید ظاهر شد — که ۲۹مورد آن بحرانی بودند.
در حالتی که تاکید بر «کدنویسی امن» بود، تعداد آسیب‌پذیری‌ها به‌طور چشمگیری کاهش یافت، اما همچنان ۳۸آسیب‌پذیری جدید (۷ مورد بحرانی) شناسایی شد.
جالب اینکه، پرامپت‌هایی با تمرکز امنیتی بالاترین درصد خطاها را در توابع مربوط به رمزنگاری ایجاد کردند.
نادیده گرفتن الزامات صنعت
در حوزه‌هایی مانند مالی، سلامت، و لجستیک، الزامات فنی، سازمانی و قانونی خاصی وجود دارد که باید در توسعه اپلیکیشن در نظر گرفته شود. دستیارهای هوش مصنوعی معمولاً از این محدودیت‌ها بی‌خبر هستند. این مسئله که به آن «فقدان عمق»نیز گفته می‌شود، باعث می‌شود روش‌های ذخیره‌سازی و پردازش داده‌های حساس (مثلاً داده‌های پزشکی یا مالی) که طبق مقررات محلی یا صنعتی باید رعایت شوند، در کدهای تولیدشده توسط AI لحاظ نشوند.
به‌عنوان مثال:
ممکن است دستیار هوش مصنوعی تابعی ریاضی برای محاسبه سود سپرده تولید کند، اما قوانین مربوط به گرد کردن اعداد که توسط نهادهای نظارتی تعریف شده، رعایت نشود.یا در مورد داده‌های سلامت، معمولاً نیاز به ثبت دقیق تمام دسترسی‌ها وجود دارد — کاری که هوش مصنوعی به‌طور پیش‌فرض انجام نمی‌دهد.
پیکربندی نادرست اپلیکیشن‌ها
آسیب‌پذیری‌ها فقط به خودوایب کدمحدود نمی‌شوند. اپلیکیشن‌هایی که از طریق کدنویسی حسیساخته می‌شوند، اغلب توسط کاربران غیرمتخصص ایجاد می‌شوند؛ افرادی که یا اصلاً محیط اجرایی را پیکربندی نمی‌کنند، یا آن را بر اساس راهنمایی‌های همان هوش مصنوعی تنظیم می‌کنند. نتیجه، پیکربندی‌های خطرناک است، مانند:
- پایگاه‌های داده موردنیاز اپلیکیشن با دسترسی بیشازحد به بیرون ایجاد می‌شوند.
این مسئله باعث نشت اطلاعاتی می‌شود مانند آنچه در Teaیا Sapphos رخ داد، که در آنها مهاجم حتی نیازی به استفاده از اپلیکیشن نداشت تا تمام دیتابیس را دانلود یا حذف کند.
- اپلیکیشن‌های داخلی شرکت‌ها بدون احراز هویت در دسترس عموم قرار می‌گیرند.
- اپلیکیشن‌ها دسترسی سطح بالا به پایگاه‌های حساس داده دارند.
وقتی این موضوع با کدهای آسیب‌پذیر ترکیب شود، راه را برای حملاتی مثل SQL Injection هموار می‌کند.
آسیب‌پذیری‌های پلتفرم
بیشتر پلت‌فرم‌های وایب‌کدینگ اپلیکیشن‌های تولیدشده از طریق پرامپت‌ها را مستقیماً روی سرورهای خود اجرا می‌کنند. این یعنی توسعه‌دهندگان هم به پلتفرم وابسته می‌شوند — هم از نظر عملکردی، هم از نظر امنیتی. اگر پلتفرم آسیب‌پذیر باشد، اپلیکیشن‌های ساخته‌شده روی آن نیز آسیب‌پذیر خواهند بود. برای مثال، در جولای ۲۰۲۵، یک آسیب‌پذیری در پلتفرم Base44 کشف شد که به مهاجمان بدون نیاز به احراز هویت اجازه می‌داد به هر اپلیکیشن خصوصی روی پلتفرم دسترسی پیدا کنند.
تهدیدهای مرحله توسعه
فقط حضور یک دستیار هوش مصنوعی با دسترسی وسیع روی رایانه توسعه‌دهنده، به‌تنهایی می‌تواند ریسک‌های جدی ایجاد کند. در ادامه، نمونه‌هایی از این تهدیدها آمده است:
- آسیب‌پذیری CurXecute با کد CVE-2025-54135 به مهاجمان اجازه می‌داد تا ابزار محبوب Cursor را وادار به اجرای فرمان‌های دلخواه روی دستگاه توسعه‌دهنده کنند. تنها چیزی که لازم بود، وجود یک سرور فعال[2]MCP متصل به Cursor بود — که اغلب به AI اجازه می‌دهد به پیام‌های Slack، تسک‌های Jira و دیگر منابع دسترسی داشته باشد. تزریق پرامپتمی‌توانست از هرکدام از این کانال‌ها انجام شود.
- آسیب‌پذیری EscapeRoute با کد CVE-2025-53109 امکان خواندن و نوشتن فایل‌های دلخواه روی دیسک رایانه توسعه‌دهنده را فراهم می‌کرد. این آسیب‌پذیری در سرور MCP ساخت شرکت Anthropic وجود داشت و سیستم محدودسازی دسترسی آن عملاً کار نمی‌کرد.
- یک سرور MCP مخرب که اجازه ارسال و دریافت ایمیل توسط AI از طریق سرویس Postmark را می‌داد، تمام مکاتبات را به‌طور پنهانی به آدرسی دیگر فوروارد می‌کرد. پیش‌تر در سپتامبر پیش‌بینی کرده بودیم که چنین سرورهایی پدید خواهند آمد.
- آسیب‌پذیری در ابزار خط فرمان Gemini امکان اجرای دستورات دلخواه را فراهم می‌کرد؛ تنها کافی بود توسعه‌دهنده از دستیار AI بخواهد کد یک پروژه جدید را تحلیل کند. کد مخرب از فایل readme.md فعال می‌شد.
- در افزونه Amazon Q Developer برای Visual Studio Code، دستوراتی برای حذف کامل داده‌های رایانه وجود داشت. مهاجمی با سوءاستفاده از خطای برنامه‌نویسان آمازون، این پرامپت مخرب را به کد عمومی افزونه تزریق کرد — بدون نیاز به دسترسی خاص. خوشبختانه، یک اشتباه کدنویسی ساده مانع اجرای دستور شد.
- آسیب‌پذیری در عامل Claude Code با کد CVE-2025-55284 اجازه می‌داد تا داده‌ها از رایانه توسعه‌دهنده از طریق درخواست‌های DNS خارج شوند. این تزریق پرامپت از طریق ابزارهایی انجام می‌شد که بدون تأیید کاربر اجرا می‌شوند، و می‌توانست در هر قطعه کدی که عامل بررسی می‌کند پنهان باشد.
- عامل خودگردان Replit، پایگاه داده اصلی یک پروژه را حذف کرد، چون تصور کرده بود که نیاز به پاک‌سازی دارد — با وجود اینکه دستور مشخصی برای جلوگیری از هرگونه تغییر داده شده بود. دلیل این رفتار غیرمنتظره، فقدان تفکیک بین محیط تست و تولید در آن زمان بود.
- تزریق پرامپت در یک کامنت داخل سورس‌کد باعث شد محیط توسعه Windsurf، دستورالعمل‌های مخرب را در حافظه بلندمدت خود ذخیره کند — و در نتیجه در طول ماه‌ها به سرقت اطلاعات از سیستم اقدام کند.
- در رخداد نفوذ به پلتفرم Nx، ابزارهای خط فرمان Claude، Gemini و Q برای جست‌وجوی گذرواژه‌ها و کلیدهای رمزنگاری‌شده در سیستم آلوده استفاده شدند.
چگونه از کد تولیدشده توسط AI به‌صورت ایمن استفاده کنیم؟
سطح خطر در کدنویسی با کمک هوش مصنوعی را می‌توان تا حد زیادی — هرچند نه کاملاً — با ترکیبی از راهکارهای فنی و سازمانی کاهش داد:
- استفاده از ابزارهای تحلیل ایستا (SAST) که به‌طور خودکار و در لحظه، کدهای تولیدشده را بررسی کنند.
- درج الزامات امنیتی در پرامپت‌های سیستمی همه‌ی محیط‌های مبتنی بر هوش مصنوعی.
- انجام بازبینی دستی توسط متخصصان انسانی باتجربه، با پشتیبانی از ابزارهای امنیتی هوشمند.
آموزش توسعه‌دهندگان برای نوشتن پرامپت‌های امن و به‌طور کلی، ارتقای دانش امنیت در کار با هوش مصنوعی.
[1]Vibe coding ، یعنی برنامه‌نویسی با کمک هوش مصنوعی که در آن برنامه‌نویس فقط ایده یا خواسته کلی را می‌دهد و هوش مصنوعی بیشتر کد را می‌نویسد. این روش تمرکز روی احساس و حال‌وهوای پروژه دارد تا نوشتن دقیق خط به خط کد.
[2] Model Context Protocol
کسپرسکی آنلاین (ایدکو)
کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.
