GitHub Actions مجهز به هوش مصنوعی را میتوان تنها با یک کامنت ربود، که منجر به نشت کلیدهای API، توکنهای ابری و سایر اسرار (secrets) میشود. یک پژوهشگر امنیتی ۲۲ مخزن متنباز را شناسایی کرده است که در آنها یک محرک عمومی، یک ابزار هوش مصنوعی که با پرچم "skip prompts" اجرا میشود و اسرارِ در معرض افشا، یک مسیر مستقیم برای استخراج دادهها ایجاد میکنند.
نحوه عملکرد این نقص امنیتی
پروژهها اکنون عاملهای هوش مصنوعی (AI agents) — مانند Claude Code، GitHub Copilot CLI و ابزارهای مشابه — را مستقیماً در خطلولههای CI جاسازی میکنند. یک مرحله (step) از گردش کار (workflow)، یک دستور شل (shell command) را اجرا میکند و اغلب پرچمی را اضافه میکند که به ابزار میگوید درخواستهای اجازه تعاملی را نادیده بگیرد. هنگامی که گردش کار با هر ورودی عمومی — مانند یک issue، یک کامنت یا عنوان یک pull-request — شروع میشود، مهاجم تنها کافی است یک خط متن ارسال کند که هوش مصنوعی آن را به عنوان یک دستور در نظر بگیرد.
هوش مصنوعی که به دلیل پرچم "skip prompts" از قبل دسترسی نامحدود به شل (shell) را دریافت کرده است، هر متغیر محیطی (environment variable) یا فایلی را که گردش کار در معرض قرار میدهد، میخواند. اگر آن job همچنین اسراری مانند کلیدهای API، توکنهای سرویس ابری یا اعتبارنامههای کامل حساب سرویس (service-account credentials) را بارگذاری کند، هوش مصنوعی آن مقادیر را به سروری که تحت کنترل مهاجم است ارسال (pipe) میکند. بدون تغییر در کد، بدون وابستگی جدید، فقط یک کامنت که ظاهراً بیخطر به نظر میرسد.
نمونههای واقعی
پژوهشگر سه مخزن آسیبپذیر را تأیید کرد که قبلاً وصله (patch) شدهاند:
- pymc-labs/pymc-marketing – یک issue عمومی میتوانست از طریق تزریق دستور (prompt injection) برای دسترسی به یک کلید Anthropic API استفاده شود.
- MadAppGang/dingo – گردش کار به Claude Code دسترسی کامل Bash میداد و دو secret را در همان job در معرض افشا قرار میداد.
- MadAppGang/claudish – از همان قالب آسیبپذیر پروژه dingo استفاده کرده بود.
یکی از یافتهها شامل یک کلید فعال حساب سرویس ابری بود که پژوهشگر آن را مستقیماً به تیم امنیتی یک ارائهدهنده بزرگ هوش مصنوعی گزارش داد. دوازده گزارش دیگر در انتظار بررسی توسط نگهدارندگان (maintainers) است؛ نام آنها تا زمان اعمال اصلاحات منتشر نخواهد شد.
آنچه در خطر است
وقتی یک مهاجم یک secret را استخراج میکند، خسارت میتواند فوری و پرهزینه باشد. یک کلید حساب سرویس ابری، دسترسی نامحدود به منابع محاسباتی، باکتهای ذخیرهسازی (storage buckets) و سایر سرویسهای پولی را فراهم میکند. یک کلید API برای یک ارائهدهنده مدلهای زبانی بزرگ (LLM) میتواند پرسوجوهای نامحدودی انجام دهد و پتانسیل ایجاد هزینههای هزاران دلاری را دارد. از آنجایی که این اکسپلویت درون محیط CI اجرا میشود، نفوذ میتواند به پاییندست گسترش یابد: هر آرتیفکتی (artifact) که روی runner آلوده ساخته شود، ممکن است حاوی کد مخرب باشد و یک مخزن واحد را به یک بردار حمله در زنجیره تأمین (supply-chain vector) تبدیل کند.
برای تیمهایی که به CI مبتنی بر هوش مصنوعی متکی هستند، این موازنه بسیار دشوار است. راحتیِ کد تولیدشده خودکار، linting یا مستندسازی باید در مقابل این خطر که یک کامنت عمومی به یک درِ پشتی (backdoor) مخفی تبدیل شود، سنجیده شود.
چرا تشخیص این آسیبپذیری آسان است
پژوهشگر در ابتدا شش گزارش ثبت کرد که بعداً پس گرفته شدند. دلیل این پس گرفتن، فرضیاتی درباره بررسیهای مجوز GitHub Actions بود، نه بررسی خطبهخط کد منبع Action. مستندات و شهود میتوانند گمراهکننده باشند؛ تنها راه قابل اعتماد برای تأیید وضعیت امنیتی یک مرحله مجهز به هوش مصنوعی، بازرسی کدی است که ابزار را اجرا میکند و فایل YAML گردش کار که آنها را به هم متصل میکند.
چکلیست اقدامات اصلاحی
اگر یک AI CLI یا ابزار مشابه را در یک گردش کار GitHub Actions اجرا میکنید، قبل از ادغام (merge)، به این دو سوال پاسخ دهید:
چه کسی میتواند گردش کار را اجرا کند؟ محرکها را به رویدادهای قابل اعتماد (مانند push به شاخههای محافظتشده یا protected branches) محدود کنید یا برای اجراهایی که توسط مشارکتکنندگان خارجی شروع میشوند، تأیید صریح بخواهید. از
on: issue_commentیاon: issuesبدون کنترلهای اضافی خودداری کنید.چه اسراری در همان job بارگذاری میشوند؟ هرگز کلیدهای API، توکنهای ابری یا اعتبارنامههای حساب سرویس را در jobی که همزمان یک عامل هوش مصنوعی با دسترسی نامحدود به شل را اجرا میکند، در معرض قرار ندهید. مراحل حساس به secret را به jobها یا runnerهای ایزوله منتقل کنید که ابزارهای هوش مصنوعی را فراخوانی نمیکنند.
مراحل اضافی برای مقاومسازی (hardening):
- پرچمی را که درخواستهای اجازه را نادیده میگیرد حذف کنید تا ابزار هوش مصنوعی مجبور شود قبل از اجرای دستورات شل، تأیید صریح بخواهد.
- مرحلهای اضافه کنید که هر متغیر محیطی را که ابزار هوش مصنوعی میتواند بخواند، پاکسازی (sanitize) یا پنهان (redact) کند.
- از runnerهای خودمیزبان (self-hosted) با کنترلهای خروجی شبکه (network egress controls) استفاده کنید تا از استخراج دادهها به نقاط پایانی (endpoints) دلخواه جلوگیری شود.
دیدگاه مقابل: کاربرد هوش مصنوعی در CI
طرفداران استدلال میکنند که افزایش بهرهوری بر ریسک آن میچربد. پیشنهادهای خودکار کد، زمان بررسی (review) را کاهش میدهند و تستهای مبتنی بر هوش مصنوعی، باگها را زودتر آشکار میکنند. با این حال، همین راحتی، سطح حمله (attack surface) را گسترش میدهد. کلید کار این نیست که هوش مصنوعی را رها کنیم، بلکه این است که با هر ابزاری که دارای امتیازات سطح شل (shell-level privileges) است، به عنوان یک بردار حمله بالقوه برخورد کنیم.
آنچه باید در آینده زیر نظر داشت
یافتهها پیش از این بحثهایی را در انجمنهای امنیتی GitHub دربارهی محدود کردن بیشتر مجوزهای پیشفرض برای Actions مجهز به هوش مصنوعی برانگیخته است. بهروزرسانیهای آتی پلتفرم ممکن است شامل موارد زیر باشد:
- پرچمی که ابزارهای هوش مصنوعی را مجبور میکند در یک محیط ایزوله (sandboxed) و بدون دسترسی مستقیم به shell اجرا شوند.
- تشخیص داخلی الگوهای prompt-injection در بدنه issueها یا کامنتها.
- هشدارهای خودکار زمانی که یک workflow، محرکهای عمومی را با jobهای حاوی secrets ترکیب میکند.
در حال حاضر، مسئولیت همچنان بر عهدهی نگهدارندگان مخزن (repository maintainers) است. ۲۲ مخزن شناساییشده نشان میدهند که این مسئله موردی منزوی نیست؛ هر پروژهای که از همان الگوی workflow پیروی کند، آسیبپذیر است. یک بررسی سریع در پیکربندیهای CI میتواند پیش از آنکه مهاجم متوجه شود، مشکل را آشکار کند.
خلاصه کلام: تنها یک خط متن در یک issue عمومی در GitHub میتواند به یک AI agent کنترل کامل بر محیط CI شما بدهد و secrets ذخیره شده در آنجا را سرقت کند. تأیید کنید چه کسی میتواند workflowهای شما را اجرا کند، secrets را از مراحل مبتنی بر هوش مصنوعی دور نگه دارید و هر پرچمی را که مجوزهای بدون کنترل اعطا میکند، به دقت بررسی کنید. هزینه یک رخنه امنیتی بسیار فراتر از تلاش لازم برای یک بررسی منظم و دقیق است.