پژوهشی تازه نشان میدهد صدها پروژه متنباز در GitHub به دلیل پیکربندی ناامن GitHub Actions در معرض حمله قرار دارند؛ موضوعی که بار دیگر ثابت میکند عبور موفق از اسکنهای امنیتی، لزوماً به معنای ایمن بودن زنجیره توسعه نرمافزار نیست.
به گزارش افتانا، سبز بودن وضعیت یک پایپلاین CI/CD معمولاً نشانه موفقیت فرایندهای ساخت و آزمایش تلقی میشود، اما این وضعیت الزاماً تضمینکننده امنیت نیست. با گسترش استفاده از ابزارهای تولید کد مبتنی بر هوش مصنوعی، شکاف میان «موفقیت در اسکنهای امنیتی» و «امنیت واقعی زنجیره تأمین نرمافزار» بیش از گذشته نمایان شده است؛ شکافی که بسیاری از ابزارهای رایج امنیتی هنوز توانایی شناسایی آن را ندارند.
پژوهشگران شرکت Novee Security در ژوئن ۲۰۲۶ از الگوی حمله جدیدی با نام Cordyceps رونمایی کردند. آنها حدود ۳۰ هزار مخزن متنباز محبوب در اکوسیستمهای npm، PyPI، crates.io و Go را مورد بررسی قرار دادند و دریافتند ۶۵۴ پروژه در معرض این تهدید قرار دارند. بررسیها همچنین نشان داد بیش از ۳۰۰ پروژه بهصورت عملی قابل سوءاستفاده بودهاند.
در میان پروژههای آسیبپذیر، نام سازمانهای شناختهشدهای مانند مایکروسافت، گوگل، بنیاد آپاچی، کلادفلر و بنیاد نرمافزار پایتون نیز دیده میشود. نکته قابل توجه این است که مهاجم برای بهرهبرداری از این ضعف امنیتی تنها به یک حساب کاربری رایگان GitHub نیاز دارد و نیازی به دسترسی ویژه یا عضویت در سازمان هدف ندارد.
با وجود این، اغلب این پروژهها از دید ابزارهای امنیتی هیچ مشکلی نداشتند. اسکنها بدون هشدار به پایان میرسید، آزمونها با موفقیت اجرا میشد و داشبوردهای امنیتی وضعیت کاملاً سبز را نمایش میدادند. علت این مسئله آن است که مشکل در یک فایل یا قطعه کد مشخص قرار ندارد، بلکه از نحوه تعامل چند Workflow با یکدیگر ایجاد میشود.
در GitHub Actions معمولاً Workflowهایی که با رویداد pull_request اجرا میشوند، در محیطی محدود و بدون دسترسی به اسرار مخزن یا توکنهای سطح بالا فعالیت میکنند. اما اگر از رویدادهایی مانند pull_request_target یا workflow_run استفاده شود، همان Workflow در محیط مخزن اصلی اجرا شده و به اعتبارنامهها و توکنهای قدرتمند دسترسی پیدا میکند.
همین تفاوت، مرز اعتماد را تغییر میدهد. در چنین شرایطی، مهاجم میتواند تنها با ارسال یک Pull Request یا حتی ثبت یک دیدگاه، دادهای کنترلشده را وارد Workflowهای دارای دسترسی بالا کند و آنها را به اجرای کد دلخواه خود وادار سازد؛ روشی که GitHub Security Lab از آن با عنوان Pwn Request یاد میکند.
بررسی پژوهشگران نشان میدهد این حمله معمولاً بر پایه سه تکنیک انجام میشود. نخست، تزریق فرمان (Command Injection) که در آن دادههایی مانند نام شاخه، عنوان Pull Request یا متن دیدگاه بدون ایمنسازی وارد دستورات شِل شده و امکان اجرای فرمانهای مهاجم را فراهم میکند. دوم، تزریق کد از طریق اکشن actions/github-script که ورودی کاربر را بهعنوان کد JavaScript اجرا میکند. سوم نیز افزایش سطح دسترسی میان چند Workflow است؛ به این صورت که یک Workflow کمدسترسی دادهای مخرب را بهعنوان Artifact یا خروجی ذخیره کرده و Workflow دیگری با دسترسی بیشتر همان داده را با اعتبارنامههای مخزن اجرا میکند.
نکته مهم اینجاست که هیچیک از این Workflowها بهتنهایی آسیبپذیر نیستند. مشکل زمانی شکل میگیرد که چند مؤلفه سالم در کنار یکدیگر قرار گرفته و زنجیرهای قابل سوءاستفاده ایجاد میکنند.
به همین دلیل، ابزارهای تحلیل ایستا (SAST) و تحلیل پویا (DAST) نیز معمولاً قادر به شناسایی چنین الگوهایی نیستند. این ابزارها هر فایل را بهصورت مستقل بررسی میکنند و چون هر بخش بهتنهایی از نظر ساختاری صحیح است، هشداری صادر نمیشود. در واقع آسیبپذیری نه در کد، بلکه در ارتباط میان اجزای مختلف نهفته است.
«شین واردن»، معمار ارشد ActiveState، در اینباره میگوید اسکنر تنها یک Workflow را مشاهده میکند، در حالی که مهاجم زنجیرهای چندمرحلهای را میبیند که در نهایت میتواند به سرقت اعتبارنامههای دائمی منجر شود.
نمونههای عملی نیز این موضوع را تأیید میکنند. پژوهشگران نشان دادند در مخزن Azure Sentinel مایکروسافت تنها با ثبت یک دیدگاه روی Pull Request میتوان کد دلخواه را در محیط CI این شرکت اجرا و کلید دائمی GitHub App را سرقت کرد؛ مسئلهای که مرکز پاسخگویی امنیتی مایکروسافت نیز آن را تأیید کرده است.
در نمونهای دیگر، مخزن AI Agent Development Kit گوگل نیز در برابر حملهای مشابه آسیبپذیر بود و پژوهشگران توانستند از طریق یک Pull Request به سطح دسترسی Owner در پروژه Google Cloud دست پیدا کنند. همچنین پروژه Apache Doris نیز مسیر مشابهی برای سرقت اعتبارنامهها داشت که پس از گزارش محققان اصلاح شد.
وجه اشتراک تمام این موارد آن بود که هیچ خطای آشکاری در کد وجود نداشت. آنچه مسیر حمله را ایجاد کرده بود، ترکیب چند تصمیم فنی بود که هر یک بهتنهایی منطقی به نظر میرسیدند، اما در کنار هم یک زنجیره خطرناک تشکیل داده بودند.
به باور پژوهشگران، با فراگیر شدن ابزارهای هوش مصنوعی مولد کد، اهمیت این موضوع دوچندان میشود. این ابزارها میتوانند در مدت کوتاهی فایلهای CI/CD تولید کنند، اما در عین حال همان الگوهای ناامن را نیز در هزاران یا حتی میلیونها پروژه تکرار کنند؛ بدون آنکه منشأ یا اعتبار این تصمیمهای امنیتی مشخص باشد.
از سوی دیگر، سامانههای رایج مدیریت آسیبپذیری نیز برای مقابله با چنین تهدیدهایی طراحی نشدهاند. Cordyceps یک آسیبپذیری مستقل با شناسه CVE نیست، بلکه یک الگوی حمله محسوب میشود و به همین دلیل در چرخه سنتی شناسایی و مدیریت آسیبپذیریها جایگاه مشخصی ندارد. همزمان، مؤسسه NIST نیز اعلام کرده است که به دلیل افزایش چشمگیر تعداد گزارشهای CVE، دیگر امکان بررسی و غنیسازی همه آنها را ندارد.
پژوهشگران تأکید میکنند تاکنون شواهدی از سوءاستفاده گسترده از این الگو مشاهده نشده و بیشتر پروژههای شناساییشده نیز اصلاحات لازم را اعمال کردهاند. با این حال، Cordyceps یک مشکل محدود یا موردی نیست، بلکه الگویی است که همچنان میتواند در پروژههای متعدد تکرار شود.
کارشناسان برای کاهش این خطر توصیه میکنند در مشارکتهای ناشناس تا حد امکان از pull_request بهجای pull_request_target استفاده شود، اجرای کد Pull Request در Workflowهای دارای دسترسی بالا ممنوع باشد، دادههای ورودی از طریق متغیرهای محیطی و بهشکل ایمن منتقل شوند، سطح دسترسی توکنها بهصورت پیشفرض روی حالت فقطخواندنی تنظیم شود، اکشنهای شخص ثالث به شناسه ثابت Commit متصل شوند و اجرای Workflowهای حساس برای مشارکتکنندگان جدید تنها پس از تأیید دستی انجام گیرد.
با این حال، این اقدامات تنها تهدیدهای شناختهشده امروز را پوشش میدهند. پژوهشگران معتقدند حملات آینده نیز احتمالاً از کنار هم قرار گرفتن چند مؤلفه ظاهراً بیخطر شکل خواهند گرفت و ممکن است بدون ایجاد هیچ هشدار امنیتی از سد اسکنرهای متداول عبور کنند.
در نتیجه، امنیت زنجیره تأمین نرمافزار دیگر تنها به اسکن کد محدود نمیشود. آنچه اهمیت بیشتری پیدا کرده، مدیریت مرزهای اعتماد، اعتبارسنجی مؤلفهها و نظارت دقیق بر نحوه تعامل Workflowها و وابستگیها در فرایند ساخت نرمافزار است.
در واقع، Cordyceps ابزارهای امنیتی را دور نزده است؛ بلکه از نقطهای عبور کرده که این ابزارها اساساً برای مشاهده آن طراحی نشدهاند. همهچیز از نگاه اسکنرها صحیح به نظر میرسید، اما همان معیارهایی که قرار بود امنیت را تضمین کنند، دیگر پاسخگوی تهدیدهای جدید نیستند. این واقعیتی است که امروز بسیاری از تیمهای توسعه باید آن را بپذیرند؛ ممکن است پایپلاین CI/CD سبز باشد، اما اعتماد به امنیت آن دیگر به همان اندازه سبز نباشد.
