یک عامل هوش مصنوعی مستقل ثابت کرد که اصلاحات کد تولیدشده توسط AI می‌توانند به اندازهٔ همان باگ‌هایی که قصد رفعشان را دارند، خطرناک باشند. Wiz Research فاش کرد که عامل Red Agent متعلق به این شرکت، پس از آنکه قابلیت Autofix در GitHub Copilot یک آسیب‌پذیری امنیتی بحرانی ایجاد کرد، توانست به پورتال داخلی جیرا (Jira) در شرکت Snowflake نفوذ کند.
این حادثه در حالی رخ می‌دهد که سازمان‌ها برای تسریع چرخه‌های توسعه، به‌شدت در حال ادغام دستیارهای کدنویسی AI هستند. در حالی که این ابزارها وعده بهره‌وری می‌دهند، اما اغلب بر اساس الگوهای احتمالی عمل می‌کنند، نه درک عمیق از بسترهای امنیتی. در این مورد خاص، هوش مصنوعی نه‌تنها نتوانست باگ را پیدا کند، بلکه فعالانه یک حفاظ امنیتی را حذف کرد.
زمینه و جزئیات آسیب‌پذیری
این نقص امنیتی در جریان پژوهش‌های امنیتی مستمر که از طریق برنامه افشای آسیب‌پذیری HackerOne در شرکت Snowflake انجام می‌شد، شناسایی شد. هدف این حمله، مخزن snowflakedb/snowflake-connector-net بود.
به نقل از گزارش Wiz، این آسیب‌پذیری در ۱۸ ژوئن ۲۰۲۶ ظاهر شد. نقص مذکور از طریق PR #1218 (کامیت 4a1b8ce) وارد شد که توسط Copilot Autofix نوشته شده بود. این دستیار AI یک الگوی ورودی امن را که از متغیرهای env: و تجزیه (parsing) با jq استفاده می‌کرد، حذف کرد و آن را با گسترش مستقیم رشته‌ها (string expansion) در یک اسکریپت شل جایگزین نمود.
این تغییر باعث ایجاد یک بردار تزریق اسکریپت در گردش‌کار jira_issue.yml شد. از آنجا که این گردش‌کار با هر بار باز شدن یک Issue در گیت‌هاب فعال می‌شد، هر کاربر غیرمجازی می‌توانست با طراحی یک عنوان خاص برای Issue، دستورات دلخواه خود را اجرا کند.
شکست در دروازه امنیتی
این گردش‌کار حاوی یک شرط if: بود که به نظر می‌رسید به عنوان یک دروازه حفاظی عمل می‌کند. با این حال، Wiz متوجه یک نقص منطقی شد: در رویدادهای issues (ایشوها)، شیء github.event.pull_request همیشه مقدار null دارد.
در نتیجه، شرط به (null != 'whitesource-for-github-com[bot]') تبدیل می‌شد. از آنجا که این عبارت همیشه درست (True) است، هر کاربر گیت‌هاب از این دروازه عبور می‌کرد و Runner در معرض حملات هر کاربری که یک Issue باز می‌کرد، قرار می‌گرفت.
فرآیند نفوذ و استخراج داده
عامل Red Agent شرکت Wiz پس از شناسایی نقص، برای استخراج اعتبارنامه‌ها (credentials) اقدام کرد. این فرآیند توانایی استدلال مستقل این عامل را به رخ کشید:
- شکست اولیه: عامل ابتدا سعی کرد از کاراکتر کامنت (#) برای پوشاندن بقیه خط استفاده کند. این کار باعث خطای سینتکس Bash شد چون کاراکتر کامنت، پرانتز بسته در
TITLE=$(...)را مصرف کرد و باعث ناقص شدن دستور شد. - تعدیل خودکار: عامل به‌جای توقف، خطای اجرای سینتکس را تحلیل کرد و Payload را به
; echo 'تغییر داد تا بلوک شل را به‌درستی ببندد و دستور خود را اجرا کند. - نفوذ موفق: در عرض چند ثانیه، عامل یک بازگشت (callback) از Runner گیت‌هاب (IP Azure 20.106.182.197) دریافت کرد که حاوی اعتبارنامه‌های کدگذاری‌شده با base64 بود.
توکن استخراج‌شده متعلق به [email protected] بود. این توکن به عامل اجازه داد تا به snowflakecomputing.atlassian.net دسترسی پیدا کند و دسترسی خواندن (read access) به پروژه‌های مهندسی، انطباق امنیتی و ردیابی باگ‌های Snowflake را به دست آورد.
بازسازی و خط زمانی
طبق گزارش HackerOne (گزارش #3819931)، شرکت Snowflake پس از اطلاع در ۲۳ ژوئن ۲۰۲۶ به‌سرعت واکنش نشان داد. شرکت در همان روز گردش‌کار را اصلاح کرد (کامیت 1dc7766، PR #1402) و الگوی امن متغیرهای env: و jq --arg را بازگرداند.
- ۱۸ ژوئن ۲۰۲۶: ایجاد الگوی آسیب‌پذیر توسط Copilot Autofix.
- ۲۳ ژوئن ۲۰۲۶: شناسایی و گزارش نقص توسط Wiz و اصلاح آن توسط Snowflake.
- ۲۴ ژوئن ۲۰۲۶: تغییر (Rotate) توکن لو رفته در جیرا.
- ۲۵ ژوئیه ۲۰۲۶: ضرب‌الاجل افشای عمومی طبق سیاست Snowflake.
تحلیل لاگ‌های فارنزیک تأیید کرد که Wiz تنها بازیگری بود که از این پنجره ۵ روزه استفاده کرد. تمام پرس‌وجوهای غیرعادی با IPهای تست Wiz مطابقت داشت و Wiz تأیید کرد تمام داده‌های دسترسی‌یافته را به‌صورت امن حذف کرده است.
این رخنه، مفروضات بنیادی مدل امنیتی CI/CD را تغییر می‌دهد. این اتفاق نشان می‌دهد که «پنجره کشف» — فاصله بین ایجاد یک آسیب‌پذیری و بهره‌برداری از آن — در حال بسته شدن است. وقتی عامل‌های خودکاری مثل Red Agent مخازن عمومی را اسکن می‌کنند، یک نقص می‌تواند در عرض چند ساعت، و نه چند هفته، به سلاح تبدیل شود. این توانایی عامل‌های هوشمند در عبور از لایه‌های حفاظتی، یادآور ریسک‌های جدیدی است که در ارزیابی‌های امنیتی اخیر برای عامل‌های پیشرفته شناسایی شده و نشان‌دهنده عصر جدیدی از تهدیدات خودکار است.
علاوه بر این، یک شکاف بحرانی در نظارت بر AI آشکار شد: فقدان زمینه تاریخی. دستیار AI الگویی را جایگزین کرد که صراحتاً برای جلوگیری از تزریق شل پیاده شده بود، چون احتمالاً درونیابی رشته‌ها (string interpolation) را الگویی «تمیزتر» یا رایج‌تر می‌دید.
برای تیم‌های امنیتی، این بدان معناست که PRهای تولیدشده توسط AI را نمی‌توان صرفاً بر اساس برچسب «autofix» پذیرفت. این کدها به همان اندازه، یا حتی بیشتر از کدهای دستی، به تحلیل استاتیک و نظارت انسانی نیاز دارند. باید حفاظ‌هایی (guardrails) پیاده شود تا عامل‌های AI نتوانند تجزیه‌کننده‌های داده‌های ساختاریافته را با درونیابی مستقیم رشته‌ها جایگزین کنند.
منتظر ظهور ابزارهای تحلیل استاتیک «آگاه به AI» (AI-aware) باشید که بتوانند به‌طور خاص مواردی را علامت‌گذاری کنند که در آن یک دستیار AI، یک الگوی امنیتی شناخته‌شده را به نفع یک الگوی احتمالی حذف کرده است.
گام بعدی شما
- تمام PRهای تولیدشده توسط AI را که شامل تغییر در اسکریپت‌های شل یا دستورات سیستمی هستند، به‌صورت دستی بازبینی کنید.
- ابزارهای تحلیل استاتیک کد (SAST) خود را به‌روز کنید تا الگوهای جایگزینی متغیرهای امن با رشته‌های مستقیم را شناسایی کنند.
- دسترسی‌های توکن‌های CI/CD را به حداقل سطح مورد نیاز (Least Privilege) محدود کنید تا در صورت نفوذ، دسترسی به کل سازمان فراهم نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو