تشخیص کد مخرب با هوش مصنوعی برای برنامه‌نویسان یعنی استفاده از مدل‌های زبانی و ابزارهای تحلیل خودکار برای پیدا کردن رفتارهایی که می‌توانند به سرقت داده، اجرای فرمان ناخواسته یا آسیب به سیستم منجر شوند. هوش مصنوعی در این کار یک فیلتر و دستیار تحلیلی است، نه داوری که بتواند با اطمینان صددرصد دربارهٔ بی‌خطر بودن کد تصمیم بگیرد.

روش قابل اعتماد این است که تحلیل هوش مصنوعی را کنار بررسی وابستگی‌ها، ابزارهای تحلیل ایستا، آزمایش در محیط جداگانه و بازبینی انسانی قرار دهید. کدی که از یک مخزن عمومی، پیام ناشناس یا بستهٔ به‌ظاهر کاربردی دریافت شده، حتی اگر کوتاه و خوانا باشد، باید پیش از ورود به پروژه بررسی شود.

تشخیص کد مخرب با هوش مصنوعی دقیقاً چه چیزهایی را پیدا می‌کند؟

مدل هوش مصنوعی می‌تواند کد را از نظر الگوهای خطرناک، مسیر ورود داده و دسترسی‌هایی که برای انجام وظیفهٔ اصلی لازم نیستند بررسی کند. ارزش این تحلیل بیشتر در توضیح چرایی خطر است؛ یعنی فقط یک خط مشکوک را علامت نمی‌زند، بلکه می‌کوشد نشان دهد داده از کجا وارد می‌شود و در نهایت به کجا می‌رسد.

برای نمونه، این موارد معمولاً ارزش بررسی بیشتری دارند:

  • اجرای مستقیم یا غیرمستقیم ورودی کاربر با قابلیت‌هایی مانند eval، اجرای فرمان سیستم یا بارگذاری پویای کد.
  • ارسال داده به دامنه یا نشانی ناشناخته، به‌خصوص زمانی که این ارتباط در مستندات پروژه توضیح داده نشده است.
  • خواندن فایل‌های حساس، متغیرهای محیطی، کلیدهای API یا اطلاعات ورود بدون دلیل روشن.
  • رشته‌های طولانی و رمزگذاری‌شده، کد مبهم‌سازی‌شده یا ساختن نام تابع‌ها و فرمان‌ها در زمان اجرا.
  • تغییر تنظیمات امنیتی، ساخت حساب کاربری، ایجاد وظیفهٔ زمان‌بندی‌شده یا ماندگار کردن برنامه روی سیستم.
  • تغییر غیرمنتظره در فایل‌های نصب، اسکریپت‌های ساخت پروژه یا وابستگی‌هایی که پس از نصب اجرا می‌شوند.

وجود یکی از این نشانه‌ها به‌تنهایی مدرک مخرب بودن نیست. بعضی برنامه‌های پشتیبان‌گیری، ابزارهای توسعه یا نرم‌افزارهای مدیریتی واقعاً به فایل‌خوانی یا اجرای فرمان نیاز دارند؛ مسئله، تناسب این دسترسی با هدف برنامه و شفاف بودن آن است.

چطور از هوش مصنوعی برای تحلیل امن کد استفاده کنیم؟

به‌جای پرسیدن سؤال کلی مانند «آیا این کد امن است؟»، درخواست را به چند بررسی مشخص تقسیم کنید. مدل در این حالت احتمال بیشتری دارد مسیرهای داده، دسترسی‌ها و نقاط تصمیم‌گیری را توضیح دهد.

  1. زمینه را محدود و دقیق کنید: زبان برنامه‌نویسی، نسخهٔ محیط اجرا، هدف فایل و منبع دریافت کد را توضیح دهید؛ اما اطلاعات محرمانه را وارد نکنید.
  2. جریان داده را بخواهید: بپرسید ورودی کاربر، فایل یا شبکه در کدام تابع‌ها پردازش می‌شود و آیا بدون اعتبارسنجی به عملیات حساس می‌رسد.
  3. دسترسی‌ها را فهرست کنید: از مدل بخواهید دسترسی کد به شبکه، فایل، فرایندهای سیستم، حافظهٔ حساس و متغیرهای محیطی را جداگانه مشخص کند.
  4. یافته‌ها را اولویت‌بندی کنید: هر مورد را بر اساس شدت، احتمال سوءاستفاده و دلیل وجود آن در برنامه دسته‌بندی کنید.
  5. نتیجه را با ابزار دیگری بسنجید: تحلیل ایستا، بررسی وابستگی‌ها و بازبینی دستی باید یافته‌های مدل را تأیید یا رد کنند.

یک درخواست خوب از هوش مصنوعی باید دنبال شواهد قابل مشاهده باشد؛ مثلاً نام تابع، مسیر اجرای داده و مجوز لازم را مطالبه کند. پاسخ‌هایی که فقط از عبارت‌هایی مانند «به نظر خطرناک می‌آید» استفاده می‌کنند، برای تصمیم امنیتی کافی نیستند.

محدودیت‌های تحلیل هوش مصنوعی را جدی بگیرید

مدل‌های زبانی ممکن است کد بی‌خطر را به‌اشتباه مشکوک اعلام کنند یا یک رفتار خطرناک را نادیده بگیرند. این خطا زمانی بیشتر می‌شود که کد ناقص باشد، نام‌گذاری ضعیفی داشته باشد، بخشی از منطق در وابستگی خارجی قرار گرفته باشد یا رفتار واقعی برنامه فقط هنگام اجرا مشخص شود.

هوش مصنوعی همچنین ممکن است دربارهٔ یک تابع، کتابخانه یا نسخهٔ خاص اطلاعات نادرست ارائه کند. بنابراین خروجی آن را مانند گزارش اولیه بخوانید، نه گواهی امنیتی. اجرای کد ناشناخته در همان رایانه‌ای که روی آن فایل‌های شخصی، حساب‌های کاری یا کلیدهای دسترسی قرار دارد، ریسک غیرضروری ایجاد می‌کند.

کد ناشناس را کجا آزمایش کنیم؟

برای بررسی رفتاری، از ماشین مجازی، کانتینر محدود یا محیط آزمایشی جدا از سیستم اصلی استفاده کنید. دسترسی شبکه را تا حد امکان قطع یا محدود کنید، پوشهٔ اشتراکی و اعتبارنامه‌های واقعی را در اختیار برنامه نگذارید و پس از آزمایش محیط را از نو بسازید.

محیط ایزوله خطر را صفر نمی‌کند، اما دامنهٔ آسیب احتمالی را کم می‌کند. اگر برنامه برای تحلیل به شبکه نیاز دارد، ارتباط‌های مجاز، مقصدها و حجم داده را ثبت کنید و هر اتصال غیرمنتظره را جداگانه بررسی کنید.

درخواست از ابزار هوش مصنوعی را چگونه بنویسیم؟

برای تحلیل دفاعی می‌توانید چنین چارچوبی داشته باشید: «این قطعه‌کد برای انجام وظیفهٔ مشخصی نوشته شده است. جریان داده، دسترسی‌های سیستم، ارتباط‌های شبکه‌ای، اجرای پویا و رفتارهای ماندگارکننده را شناسایی کن. برای هر مورد، خط یا تابع مرتبط، دلیل مشکوک بودن، سناریوی سوءاستفاده و راه اصلاح را توضیح بده. اگر شواهد کافی نیست، عدم قطعیت را صریح اعلام کن.»

این قالب، مدل را به توضیح قابل بررسی وادار می‌کند. بهتر است کد را در چند بخش مرتبط تحلیل کنید و سپس از مدل بخواهید یافته‌های جداگانه را با هم مقایسه کند؛ بررسی یک فایل کوتاه بدون دیدن تنظیمات پروژه، وابستگی‌ها و اسکریپت نصب می‌تواند تصویر ناقصی بسازد.

چک‌لیست برنامه‌نویس پس از دریافت گزارش

  • آیا رفتار علامت‌گذاری‌شده برای هدف واقعی برنامه ضروری است؟
  • آیا نام بسته، نسخه و منبع وابستگی با مستندات و فایل قفل پروژه مطابقت دارد؟
  • آیا کد به داده‌ای دسترسی دارد که کاربر یا برنامه واقعاً به آن نیاز ندارد؟
  • آیا ارتباط شبکه‌ای به مقصد مشخص و قابل توضیح انجام می‌شود؟
  • آیا می‌توان رفتار مشکوک را در محیط آزمایشی بازتولید و ثبت کرد؟
  • آیا یک برنامه‌نویس دیگر یا مسئول امنیت یافته را مستقل بررسی کرده است؟

برای پروژه‌های خانوادگی، مالی یا کاری، فقط خود کد مهم نیست؛ اطلاعاتی که هنگام تحلیل در اختیار ابزار هوش مصنوعی قرار می‌گیرد نیز بخشی از سطح خطر است. پیش از ارسال، کلیدها و داده‌های شخصی را حذف کنید، نام‌ها را ناشناس کنید و از قرار دادن فایل کامل پیکربندی در یک گفت‌وگوی عمومی خودداری کنید.

جمع‌بندی: تشخیص کد مخرب با هوش مصنوعی می‌تواند زمان بررسی را کم کند و رفتارهای پنهان را بهتر توضیح دهد، اما جایگزین تحلیل ایستا، بررسی وابستگی‌ها، محیط ایزوله و قضاوت برنامه‌نویس نیست. بهترین تصمیم زمانی گرفته می‌شود که هر هشدار با شواهد کد، هدف واقعی برنامه و نتیجهٔ آزمایش کنترل‌شده سنجیده شود.