نشت اطلاعات محرمانه همیشه مربوط به کد بد یا کتابخانههای آسیبپذیر نیست. گاهی اوقات، به نحوه مدیریت اطلاعات محرمانه در طول اجرای CI برمیگردد و CVE‑2025‑30066 نمونهای از چگونگی انحراف این روند است. GitHub Action tj‑actions/changed‑files، که به طور گسترده برای تشخیص فایلهای تغییر یافته در ... استفاده میشود. pull requests، به یک کانال خاموش برای نشت اطلاعات محرمانه تبدیل شد. در اینجا آنچه اتفاق افتاده و نحوه قفل کردن اطلاعات شما آمده است. CI/CD اسرار pipeline.
چه اتفاقی در CVE‑2025‑30066 افتاد؟
در اواسط مارس ۲۰۲۵، فایل tj-actions/changed-files مورد نفوذ قرار گرفت. مهاجم برچسبهای نسخه موجود (تا نسخه ۴۵.۰.۷) را بازنویسی کرد تا به یک فایل مخرب اشاره کند. commitاین کار رفتار اکشن را بدون اینکه توسعهدهندگان متوجه شوند تغییر داد؛ هیچ نسخه جدیدی منتشر نشد، فقط دستکاری نامرئی تگها.
این بار داده سرراست اما خطرناک بود: یک اسکریپت پایتون با کدگذاری Base64 از راه دور را اجرا میکرد که حافظهی اجراکننده را برای یافتن اعتبارنامهها اسکن میکرد، آنها را در لاگها ذخیره میکرد یا از سیستم خارج میکرد. این یک نقص کد منطقی در tj-actions/changed-files نبود؛ بلکه سوءاستفادهای از چگونگی رخ دادن نشت اطلاعات محرمانه در گردشهای کاری CI با استفاده از آن Action قابل استفادهی مجدد بود. CVE-2025-30066 مربوط به سرریز بافر نبود؛ بلکه مربوط به یک نقص در طراحی CI بود که امکان نشت اطلاعات محرمانه را فراهم میکرد.
تأثیر: هرگونه مخزنی که از نسخههای آسیبدیدهی tj-actions/changed-files استفاده میکند، در معرض خطر افشای اطلاعات محرمانه قرار دارد، بهخصوص اگر توکنها یا فایلهای حساس در الگوهای فایل یا خروجیهای CI بهصورت ناامن مدیریت شوند.
چرا این موضوع بر گردشهای کاری متکی بر اکشنهای قابل استفاده مجدد تأثیر میگذارد؟
گردشهای کاری DevSecOps به شدت به فایلهای tj-actions/changed-files برای موارد زیر متکی هستند:
- اتوماتیک pull request چک ها
- شناسایی فایلهای تغییر یافته در مسیرهای خاص
- از مشاغل اضافی در حوزه CI اجتناب کنید
اما این گردشهای کاری اغلب یک چیز را نادیده میگیرند: اینکه چگونه الگوهای glob ممکن است شامل دادههای حساس باشند. توسعهدهندگان فرض میکنند که tj-actions/changed-files به طور پیشفرض ایمن رفتار میکنند. با این حال، اگر شما glob پیکربندیها/** و اسرار در آن ذخیره میشوند فایل configs/secrets.env، شما همین الان یک فایل مخفی به خروجیها یا لاگهای CI اضافه کردید. این یک اشکال در Action نیست؛ بلکه یک ... است. CI/CD نقص طراحی که منجر به نشت مخفیانه میشود. CVE‑2025‑30066 نمونه بارزی از این مورد است.
چگونه نشت اطلاعات محرمانه رخ داد (تفکیک آسیبپذیری)
بیایید نقص اصلی پشت CVE‑2025‑30066 را بررسی کنیم:
- الگوهای گلوبینگ مانند **/*.env فایلهای مخفی را ناخواسته تطبیق داد
- tj‑actions/changed‑files با آن فایلهای مخفی به عنوان فایلهای تغییر یافته رفتار کرد.
- رازها در خروجیهای مرحلهای، لاگها یا کارهای پاییندستی قرار میگرفتند
این اتفاق افتاد زیرا اطلاعات محرمانه در مسیرهای کنترلشدهی نسخه ذخیره میشدند (ایدهی بدی بود) و پیکربندی CI صراحتاً آنها را از globbing مستثنی نمیکرد (که آن هم بد بود). بنابراین این یک اشکال کد نیست، بلکه یک طراحی ضعیف CI است که باعث نشت اطلاعات محرمانه با خروجیهای tj‑actions/changed‑files میشود.
مسیر عملی اکسپلویت: از شغل CI تا افشای اعتبارنامه
مثالی از تنظیمات CI که باعث نشت اطلاعات محرمانه از طریق tj-actions/changed-files شد:
If فایل configs/secrets.env تغییر کرد:
- توسط tj‑actions/changed‑files علامتگذاری شد
- شامل آن شد مراحل.تغییر.خروجیها.تمام_فایلهای_تغییر_یافته
- مراحل بعدی آن را ثبت میکرد یا به اسکریپتها ارسال میکرد و اسرار را فاش میکرد
این نشت اطلاعات به این دلیل رخ داد که منطق CI با فایلهای محرمانه مانند فایلهای معمولی رفتار میکرد. اینجاست که نشت اطلاعات محرمانه آغاز میشود، نه به دلیل سرریز بافر، بلکه به دلیل سوءاستفاده از فایلهای tj-actions/changed-files در یک طراحی CI ناقص.
انتشار با خروجیهایی مانند موارد زیر اتفاق میافتد:
If اسرار.env در آن لیست باشد، نام فایل و احتمالاً محتوای آن ممکن است در گزارشهای ساخت ظاهر شود. حتی منطق شرطی مانند:
میتواند آثار باستانی حساس را در معرض دید قرار دهد. این یک CI/CD نقص طراحی که امکان نشت اطلاعات محرمانه را فراهم میکند، نه نقصی در کد اکشن.
نحوه استفاده ایمن از گردشهای کاری قابل استفاده مجدد و جلوگیری از نشت اطلاعات
لازم نیست اقدامات/فایلهای تغییر یافته را رها کنید. باید از اقدامات قابل استفاده مجدد با ذهنیت اولویت اسرار استفاده کنید:
اسرار - بهترین شیوههای مدیریت
- هرگز کنترل نسخه را مخفی نکنید
- از الگوهای glob که با مسیرهای حساس مطابقت دارند، اجتناب کنید
- استفاده از اسرار مبتنی بر محیط (GITHUB_ENV، vaults، اسرار GitHub)
CI/CD پیکر بندی Guardrails
- همیشه اقدامات را به SHA های تغییرناپذیر پین کنید، نه به برچسبها (هرگز از @v45)
- خروجی tj-actions/changed-files را به عنوان آلوده در نظر بگیرید، آن را پاکسازی یا فیلتر کنید
- خروجیها را فقط در صورت پاکسازی تنظیم کنید
⚠️ مثال ناامن:
موارد فوق دقیقاً سوءاستفادهای است که پشت افشای اطلاعات محرمانه و آسیبپذیری CVE‑2025‑30066 وجود دارد.
جایگزین ایمن:
با انجام این کار، از CI/CD نقص طراحی که منجر به نشت مخفیانه از طریق اقدامات tj/فایلهای تغییر یافته میشود.
علاوه بر این:
- غیرفعال کردن یا محدود کردن ثبت وقایع در جایی که ممکن است اطلاعات محرمانه ظاهر شوند
- از ویژگیهای مخفی پنهانسازی گیتهاب استفاده کنید
- محدود کردن دسترسی به لاگهای ساخت و مصنوعات
چک لیست استفاده ایمن از CI - اسرار سریع
| بهترین تمرین |
|---|
| اطلاعات محرمانه را در فایلهای کنترلشدهی نسخه ذخیره نکنید |
| برای اعتبارنامهها از vaults یا GitHub Secrets استفاده کنید |
| همیشه فایلهای tj-actions/changed-files را به SHAهای تغییرناپذیر سنجاق کنید |
| فیلتر کردن یا پاکسازی خروجیها از فایلهای tj-actions/changed-files |
| هرگز مسیرهای مخفی را در الگوهای glob قرار ندهید |
| گزارشهایی را که ممکن است دادههای حساس را افشا کنند، پنهان یا محدود کنید |
| پیکربندیهای CI موروثی را اغلب بررسی کنید |
نقش زیگنی: اجرای اسرار CI در مقیاس بزرگ
شیگنی تضمین امنیت CI/CD pipelineبا تمرکز بر چگونه اسرار در دنیای واقعی مدیریت، استفاده و افشا میشوند گردشهای کاری DevOps. این فقط مربوط به اسکن کد نیست؛ بلکه مربوط به اجرای بهترین شیوههای مدیریت مخفی از طریق اجرای زنده است. pipeline تجزیه و تحلیل.
تشخیص استفاده از خروجی ناامن
- اسکن اقدامات گیتهاب برای استفادههای echo، اجرا، و خروجی میدهد که در آن ${{ steps.*.outputs.* }} ممکن است شامل مقادیر حساس باشد
- مشخص میکند چه زمانی به اسرار مستقیماً، عمداً یا به اشتباه ارجاع داده شده یا چاپ شدهاند.
نظارت بر اسرار فاش شده
- مقادیر با آنتروپی بالا (کلیدهای API، توکنها) را در داخل لاگها و خروجیهای مرحلهای تشخیص میدهد.
- هنگام ظاهر شدن اسرار در pipeline سیاهههای مربوط، حتی اگر در پایین دست پوشانده شده باشند
نحوهی استفاده از اکشن با پیکربندی نادرست
- تمام اقدامات GitHub را در سراسر سایت ردیابی میکند pipelineبرای تشخیص استفاده از نسخههای آسیبپذیر (مثلاً tj-actions/changed-files@v45)
- الگوهای تطبیق فایل را که شامل اسرار بالقوه مانند موارد زیر هستند، بررسی میکند. **/*.env، *.key، یا .env.*
CI مبتنی بر سیاست Guardrails
- پینگذاری SHA را برای اقدامات شخص ثالث اجباری میکند
- استفاده از فایلهای glob ناامن را که میتوانند اطلاعات محرمانه را در لاگها جا به جا کنند، مسدود میکند.
- جلوگیری می کند pipelineاز انتشار مقادیر حساس به عنوان بخشی از خروجیهای گردش کار جلوگیری میکند.
با در نظر گرفتن گردشهای کاری به عنوان بخشی از سطح تهدید شما، Xygeni تضمین میکند که بهداشت مخفی نه تنها یک روش عالی، بلکه یک دفاع داخلی است.
نتیجهگیری: نشت اطلاعات محرمانه میتواند با یک سوءاستفاده ساده آغاز شود
CVE‑2025‑30066 یک اشکال کتابخانهای نبود؛ CI/CD شکست طراحی ناشی از استفاده نادرست از tj-actions/changed-files. آنچه تیمهای DevSecOps باید از آن اجتناب کنند:
- هر ارجاع به فایل/glob در CI را به عنوان یک نقطه نشت بالقوه در نظر بگیرید.
- گردشهای کاری را مرتباً برای جلوگیری از درج تصادفی اطلاعات محرمانه، بررسی کنید.
- از خزانههای امن یا اسرار محیطی استفاده کنید، هرگز اسرار را در کنترل نسخه بررسی نکنید.
- پاکسازی یا فیلتر کردن تمام خروجیهای گردش کار
- ثبت فعالیتهای حساس گردش کار برای حفظ قابلیت حسابرسی
CI کد است. گردشهای کاری کد هستند. گزارشها و خروجیها کد هستند. در هر مرحله از اسرار خود محافظت کنید، وگرنه ریسک یک سناریوی افشای اطلاعات محرمانه را به جان میخرید که نیازی به هکر ندارد، فقط یک نشت اطلاعات بد است. CI/CD انتخاب طراحی.
