اگر امروز از هوش مصنوعی برای نوشتن کد استفاده می‌کنید، احتمالاً با کدی مواجه شده‌اید که در نگاه اول بی‌نقص است اما در محیط عملیاتی (Production) با رفتاری غیرمنتظره شکست می‌خورد. این فاصلهٔ خطرناک میان «صحت ظاهری» و «عملکرد واقعی»، بزرگ‌ترین چالش امنیتی سال ۲۰۲۶ است. در واقع، کدهایی که توسط AI تولید می‌شوند، اغلب از نظر سینتکس (ساختاری) کاملاً درست به نظر می‌رسند، اما در زمان اجرا رفتاری نادرست دارند. این پدیده در واقع بازتابی از شکاف میان صحتِ پیاده‌سازی و صحتِ سیستمی در عامل‌های کدنویس است که باعث می‌شود کد در سطح تک‌فایل درست، اما در سطح کل سیستم شکست بخورد.
طبق گزارش ۲۰۲۶ شرکت New Relic درباره وضعیت کدنویسی با هوش مصنوعی، ۸۲٪ از مدیران فناوری در ۶ ماه گذشته دست‌کم یک شکست جدی در محیط عملیاتی را تجربه کرده‌اند که ریشه در کدهای تولیدشده توسط هوش مصنوعی داشته است. نکته تکان‌دهنده این است که ۹۴٪ از همین مدیران، کیفیت کدهای AI را در زمان بازبینی (Review) بالاتر ارزیابی کرده بودند. این تضاد نشان‌دهنده یک شکاف امنیتی عمیق است که ابزارهای سنتی قادر به پر کردن آن نیستند. این وضعیت ما را با چالش منطق‌های متقاعدکننده اما غلط مواجه می‌کند؛ جایی که کد به دلیل ظاهر حرفه‌ای، بازبین انسانی را فریب می‌دهد.
زمینه و بستر تغییرات
این تضاد به دلیل ماهیت ابزارهای تست امنیتی استاتیک اپلیکیشن (SAST) سنتی است. این ابزارها بر پایه «تطبیق الگو» (Pattern Matching) کار می‌کنند؛ یعنی شبیه به یک پلیس راهنمایی هستند که فقط دنبال تخلفات مشخص (مثل نبود کمربند ایمنی) می‌گردد. SAST سنتی برای شناسایی «اشکال شناخته‌شده» اسکن می‌کند؛ مواردی مانند کلیدهای API که به‌صورت سخت‌افزاری (Hardcoded) در کد قرار گرفته‌اند، کوئری‌های SQL که از طریق چسباندن رشته‌ها (String Concatenation) ساخته شده‌اند، یا توابع رمزنگاری قدیمی و منسوخ.
اگر قانونی برای یک آسیب‌پذیری وجود داشته باشد، SAST کلاسیک آن را سریع و با قطعیت پیدا می‌کند: یعنی اگر کد یکسانی وارد شود، همیشه نتیجه یکسانی خارج می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، ابزارهای قاعده‌مند به عنوان یک گیت در CI/CD که الگوهای آشکارا ریسکی را پیش از بررسی انسانی در Pull Request مسدود می‌کنند، همچنان ابزاری حیاتی هستند. این ابزارها سریع‌اند، اجرای آن‌ها روی کدبیس‌های بزرگ ارزان است و در شناسایی حملات تزریق (Injection)، افشای اسرار (Secrets) و CWEهای شناخته‌شده بسیار مؤثرند. اما مشکل اینجاست: اگر قانونی برای یک باگ نوشته نشده باشد، آن باگ برای این ابزارها نامرئی است. محدودیت این سیستم‌ها ذاتی است؛ یک موتور قاعده‌مند فقط چیزی را پیدا می‌کند که پیش‌تر کسی برایش قانون نوشته باشد.
تصور کنید توسعه‌دهنده‌ای یک خط لوله داده پیچیده را با AI می‌سازد. کد از نظر سینتکس درست است، توسط Linter تأیید شده و بازبین انسانی هم آن را تمیز و درست می‌بیند. اما یک باگ رفتاری ظریف در آن نهفته است؛ مثلاً یک خطای «یکی-بیشتر/یکی-کمتر» (Off-by-one) در یک شرط مرزی، یک بررسی مقدار تهی (Null check) روی متغیر اشتباه، یا دو تابعی که در مورد این‌که آیا یک لیست قبلاً تکراری‌زدایی شده است یا خیر، با هم اختلاف نظر دارند. چون ساختار کد معتبر است، موتورهای قاعده‌مند هیچ مشکلی نمی‌بینند. برای شناسایی این موارد، ابزار باید بفهمد کد «قرار است چه کند» و آن را با «آنچه واقعاً می‌کند» مقایسه کند. این نوع باگ‌های پنهان در درازمدت منجر به ایجاد بدهی فنی نامرئی می‌شوند که شناسایی و اصلاح آن‌ها در آینده بسیار دشوارتر از کدهای سنتی است.
به همین دلیل دسته‌بندی جدیدی به نام AI SAST ظهور کرده است. این برچسب امسال در همه جا، از صفحات آموزشی Checkmarx گرفته تا بازاریابی فروشندگان، دیده می‌شود. بر اساس راهنمای سال ۲۰۲۶ شرکت Augment Code، این ابزارها به دو گروه تقسیم می‌شوند:
- AI-assisted (کمک‌گیر AI): در این مدل، موتور قاعده‌مند همچنان شناسایی را انجام می‌دهد و مدل هوش مصنوعی فقط در مراحل تریاژ (Triage)، اولویت‌بندی و پیشنهاد اصلاحات کمک می‌کند.
- AI-native (بومی AI): در اینجا خودِ مدل نقش شناسایی را بر عهده دارد. مدل کد را می‌خواند و درباره آن استدلال می‌کند؛ رفتاری که بیشتر شبیه به یک بازبین انسانی است تا یک لینتر سخت‌گیر.
جزئیات فنی و سبک‌سنگین کردن‌ها
ابزارهای بومی AI قابلیت‌هایی دارند که قوانین سنتی هرگز به آن‌ها نمی‌رسند:
- استدلال میان‌فایلی (Cross-File Reasoning): مدل‌ها می‌توانند مسیر داده را در چندین تابع و فایل مختلف دنبال کنند تا بفهمند یک تغییر در یک نقطه، چگونه بر فرآیندهای پایین‌دستی در نقاط دیگر اثر می‌گذارد.
- تحلیل قصد (Intent Analysis): آن‌ها می‌توانند قضاوت کنند که آیا یک مورد در بستر (Context) خاص برنامه واقعاً یک مشکل است یا خیر؛ این یعنی توانایی شکار باگ‌های منطقی و نقص‌های مربوط به احراز هویت و دسترسی.
- ردیابی چندمرحله‌ای (Multi-step Tracing): شناسایی مشکلاتی که تنها در صورت ردیابی کل مسیر اجرا و زنجیره اتفاقات نمایان می‌شوند، اکنون در دسترس است.
اما این قدرت، بهای سنگینی دارد: عدم قطعیت. برخلاف SAST کلاسیک، تحلیل‌های بومی AI قطعی (Deterministic) نیستند. یعنی ممکن است یک کد را دو بار بررسی کنید و دو نتیجه متفاوت بگیرید، که این موضوع موانع بزرگی برای ممیزی‌های امنیتی (Security Audits) ایجاد می‌کند.
هزینه و سرعت نیز فاکتورهای تعیین‌کننده هستند. فراخوانی یک مدل برای هر فایل یا هر Pull Request بسیار کندتر و گران‌تر از یک اسکن سریع قاعده‌مند است. علاوه بر این، حکم یک مدل واحد می‌تواند اشتباه باشد و «مثبت‌های کاذب» (False Positives) تولید کند که ماهیت آن‌ها با خطاهای موتورهای قاعده‌مند متفاوت است.
توسعه‌دهندگان همین حالا این شکاف اعتماد را حس می‌کنند. نظرسنجی شرکت Sonar در ژانویه ۲۰۲۶ نشان داد ۹۶٪ توسعه‌دهندگان کاملاً مطمئن نیستند که کدهای تولیدشده توسط AI از نظر عملکردی درست باشند. همچنین ۳۸٪ معتقدند بازبینی کد AI تلاش و انرژی بیشتری نسبت به بازبینی کد یک همکار انسانی می‌طلبد. اگر توسعه‌دهندگان به کدی که یک مدل می‌نویسد اعتماد ندارند، منطقی است که بپرسیم چرا باید به حکم یک مدل واحد درباره وجود یا عدم وجود یک آسیب‌پذیری اعتماد کنند؟
برای کاهش این ریسک، شرکت‌هایی مثل Dromeas از رویکرد «شورای مدل‌ها» (Council of Models) استفاده می‌کنند. آن‌ها به‌جای تکیه بر یک نظر، ترکیبی از مدل‌های Anthropic، GPT-5 از OpenAI، Gemini 2.5 Pro گوگل و DeepSeek V4 Pro را به کار می‌گیرند تا یافته‌ها را پیش از نمایش به کاربر، با یکدیگر تطبیق داده و تأیید کنند.
این مدل‌ها به‌جای بررسی صرفِ تغییرات (Diff)، روی یک نقشه کامل از کد — شامل فایل‌ها، نمادها (Symbols) و گراف‌های فراخوانی (Call Graphs) — استدلال می‌کنند. این امر تضمین می‌کند که AI بستر گسترده‌تر مخزن کد و این‌که یک تغییر دقیقاً چه بخش‌هایی را لمس می‌کند، درک کند.
برای تیم‌های مهندسی، نتیجه روشن است: AI SAST لایه‌ای قدرتمند برای شکار باگ‌های رفتاری است، اما نمی‌تواند جایگزین سرعت و قطعیت گیت‌های قاعده‌مند شود. امن‌ترین خط لوله، ترکیبی است که از SAST کلاسیک برای مسدود کردن ریسک‌های بدیهی (مثل OWASP Top 10 و مسائل زنجیره تأمین) و از استدلال بومی AI (مثل Bug Tracing در Dromeas) برای شکار نقص‌های منطقی عمیق استفاده کند.
گام بعدی شما
هنگام ارزیابی فروشندگان ابزارهای امنیتی، باید این سؤالات مشخص را بپرسید:
- آیا مدل است که شناسایی را انجام می‌دهد، یا فقط نتایجی را که قوانین پیدا کرده‌اند تریاژ و دسته‌بندی می‌کند؟
- اگر ابزار را دو بار روی یک PR یکسان اجرا کنید، چه اتفاقی می‌افتد؟ (آیا نتایج یکسان است؟)
- آیا پیش از رسیدن یک یافته به کاربر، بیش از یک مدل آن را بررسی و تأیید می‌کند؟
- آیا ابزار اثر تغییرات را در کل کدبیس ردیابی می‌کند یا فقط به Diff (تغییرات لحظه‌ای) نگاه می‌کند؟
اما داستان سخت‌افزاری این تحول و هزینه استنتاج در مقیاس بزرگ حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو