GitLab بستهٔ پرخطر را پیش از Build می‌بندد؛ Firewall هنوز دسترسی زودهنگام است

GitLab در ۶ اکتبر ۲۰۲۶ و در رویداد Transcend، Dependency Firewall را در دسترسی زودهنگام معرفی کرد. این قابلیت بستهٔ درخواستی را پیش از ورود به Build با سیاست سازمان می‌سنجد و می‌تواند بستهٔ ناسازگار را مسدود کند. زمان مداخله پیش از نصب وابستگی است؛ نتیجهٔ هر درخواست به قواعدی بستگی دارد که تیم برای پروژه تعریف کرده است.

گزارش ADTmag نیز معرفی ۶ اکتبر ۲۰۲۶ را در چارچوب «کارخانهٔ نرم‌افزار تحت حاکمیت» GitLab قرار می‌دهد و وضعیت دسترسی زودهنگام Firewall را برای مشتریان Premium و Ultimate ثبت می‌کند. برای تیم DevSecOps، پیامد اصلی این جابه‌جاییِ نقطهٔ تصمیم است: بسته می‌تواند پیش از نصب رد شود، در حالی که اسکن ترکیب نرم‌افزار معمولاً وابستگی دریافت‌شده را بررسی می‌کند. دسترسی زودهنگام به معنای فعال بودن قابلیت برای همهٔ دارندگان این اشتراک‌ها نیست.

کنترل در لحظهٔ دریافت بسته چه چیزی را می‌سنجد؟

Dependency Firewall برای تصمیم‌گیری دربارهٔ ورود یک بسته به Build به سیاست سازمان رجوع می‌کند. قواعد معرفی‌شده شامل شناسایی بستهٔ مخرب، شدت آسیب‌پذیری و تعداد یافته‌های مجاز، نوع مجوز نرم‌افزاری و حداقل سن نسخهٔ بسته است. برای نمونه، تیم می‌تواند ورود نسخه‌ای را که تازه منتشر شده تا رسیدن به سن تعیین‌شده متوقف کند؛ این یک قاعدهٔ قابل تنظیم است، نه حکمی که به‌طور یکسان بر همهٔ بسته‌ها اعمال شود.

سیاست می‌تواند از گروه بالادستی به پروژه‌ها برسد و در صورت هم‌پوشانی قواعد، قاعدهٔ سخت‌گیرانه‌تر اعمال شود. بنابراین یک بسته ممکن است در دو پروژهٔ یک سازمان نتیجهٔ متفاوتی بگیرد، بسته به اینکه چه سیاست‌هایی بر هر پروژه حاکم است. ثبت قواعد در پروژهٔ سیاست امنیتی و تغییر آن‌ها از مسیر درخواست ادغام، تصمیم دربارهٔ وابستگی را به همان فرایند بازبینی تنظیمات توسعه وصل می‌کند.

تفاوت با تحلیل ترکیب نرم‌افزار یا SCA در ترتیب رخدادهاست. SCA وابستگی‌های واردشده به پروژه را برای یافتن آسیب‌پذیری یا مشکل مجوز بررسی می‌کند؛ اگر کد یک بستهٔ مخرب هنگام نصب اجرا شود، کشف پس از دریافت بسته آن اجرای اولیه را خنثی نمی‌کند. کنترل پیش از نصب این فاصله را هدف می‌گیرد، اما بررسی وابستگی‌های موجود و پیگیری یافته‌های بعدی همچنان به ابزارهای اسکن نیاز دارد.

از درخواست بسته تا هشدار، مسدودسازی یا قرنطینه

مسیر اعلام‌شده از درخواست یک نسخهٔ مشخص آغاز می‌شود: توسعه‌دهنده، عامل کدنویسی یا خط لوله بسته را می‌خواهد و Firewall آن را با سیاست مؤثر بر پروژه می‌سنجد. اگر درخواست با قاعده‌ای ناسازگار باشد، حالت هشدار اجازه می‌دهد Build ادامه پیدا کند و هم‌زمان نتیجه را ثبت می‌کند. در حالت مسدودسازی، تطابق با قاعده خط لوله را متوقف می‌کند و دلیل تصمیم باقی می‌ماند.

1. درخواست بسته و نسخهٔ آن از مسیر دریافت وابستگی به نقطهٔ بررسی می‌رسد.
2. قواعد مربوط به بدافزار، آسیب‌پذیری، مجوز و سن بسته با درخواست سنجیده می‌شوند.
3. حالت هشدار نتیجه را ثبت می‌کند و به Build اجازهٔ ادامه می‌دهد؛ حالت مسدودسازی مانع ادامهٔ خط لوله می‌شود.
4. رویداد ممیزی، بسته، قاعده و سیاست دخیل در تصمیم را برای پیگیری نشان می‌دهد.

در اطلاعیهٔ رسمی GitLab، قرنطینه نیز در کنار هشدار و مسدودسازی به‌عنوان پیامد ممکن نام برده شده است. شرح عملیاتی منتشرشده برای دسترسی زودهنگام، حالت‌های هشدار و مسدودسازی را توضیح می‌دهد، اما گردش کار قرنطینه را با همان جزئیات روشن نمی‌کند. از این رو نام بردن از قرنطینه به‌تنهایی برای فرض آماده بودن آن در محیط یک مشتری کافی نیست.

برای حالت هشدار، رویداد ممیزی، نمای فعالیت و خلاصهٔ CI نشان می‌دهند کدام درخواست با سیاست برخورد کرده است. برای حالت مسدودسازی نیز دلیل توقف ثبت می‌شود. مسیر عبور استثنایی برای کاربر یا توکن مجاز پیش‌بینی شده و این عبور در سوابق می‌ماند؛ مجوز عبور، ارزیابی امنیتی بسته را به نتیجهٔ «بی‌خطر» تبدیل نمی‌کند.

npm، PyPI و Maven در کدام مسیر بررسی می‌شوند؟

در توضیح محصول از npm، pip، Poetry، Maven، Gradle و Bundler برای بررسی بسته از طریق GitLab CLI نام برده شده است. سازگاری با GitLab Artifact Central و رجیستری‌های خارجی Sonatype Nexus Repository و JFrog Artifactory نیز اعلام شده است. با این حال، نام یک مدیر بسته یا رجیستری تضمین نمی‌کند هر درخواست در پیکربندی خاص یک سازمان از نقطهٔ کنترل عبور کند؛ پوشش به مسیر واقعی دریافت بسته و قرار گرفتن بررسی در آن مسیر وابسته است.

برای سنجش پوشش، تیم باید مسیر بسته‌های مستقیم و وابستگی‌های غیرمستقیم را در خط لولهٔ خود ببیند. چک‌لیست زیر پرسش‌های ارزیابی برای محیط واقعی است، نه ادعای پوشش خودکار همهٔ حالت‌ها:

• npm: آیا نصب از رجیستری عمومی، رجیستری خصوصی و آینهٔ مورد استفادهٔ پروژه از مسیری می‌گذرد که سیاست بر آن اعمال می‌شود؟ نتیجهٔ بستهٔ مستقیم و وابستگی غیرمستقیم چگونه در CI دیده می‌شود؟
• PyPI: آیا pip و Poetry با تنظیمات واقعی فهرست بسته و آینهٔ سازمان همان تصمیم را دریافت می‌کنند؟ اگر نصب چند وابستگی تازه بخواهد، دلیل هشدار یا توقف برای هر درخواست روشن است؟
• Maven: آیا دریافت از مخزن اصلی و مخزن واسط در مسیر بررسی قرار دارد؟ اگر پروژه از Gradle نیز استفاده می‌کند، نتیجهٔ توقف یک وابستگی در خروجی Build چگونه مشخص می‌شود؟

این تفاوت مسیرها هزینهٔ مهاجرت خط لوله را تعیین می‌کند. پروژه‌ای که چند رجیستری، آینه یا شیوهٔ نصب دارد، باید برای هر مسیر روشن کند بررسی در کجا اجرا می‌شود و توقف تازه چه اثری بر کارهای CI می‌گذارد. GitLab CLI امکان سنجش یک بسته را پیش از افزودن آن نیز می‌دهد، اما نتیجهٔ آن بررسی جای مشاهدهٔ درخواست‌های واقعی خط لوله و وابستگی‌هایی را که هنگام نصب دریافت می‌شوند نمی‌گیرد.

چه کسانی اکنون می‌توانند دسترسی بخواهند؟

دسترسی زودهنگام Dependency Firewall برای مشتریان GitLab.com و GitLab Self-Managed در سطح Premium یا Ultimate اعلام شده و درخواست آن امکان‌پذیر است. این وضعیت با عرضهٔ عمومی تفاوت دارد: داشتن اشتراک واجد شرایط، به‌تنهایی فعال بودن کنترل در یک محیط مشخص را نشان نمی‌دهد. هنگام ارزیابی نیز باید روشن شود کدام خط لوله‌ها و رجیستری‌ها واقعاً زیر سیاست قرار گرفته‌اند.

در نتیجه، اثر عملی اعلام امروز به دو تصمیم وابسته است: تیم چه بسته‌ای را با چه قاعده‌ای رد می‌کند و آیا درخواست آن بسته واقعاً از مسیر بررسی می‌گذرد. تا روشن شدن پوشش محیط و جزئیات قرنطینه در دسترسی زودهنگام، حالت هشدار می‌تواند اثر قواعد را بدون توقف Build آشکار کند؛ مسدودسازی زمانی جلوی ورود بسته را می‌گیرد که همان مسیر تحت کنترل و قاعدهٔ مربوط فعال باشد.

بیشتر بخوانید:

• عامل تازهٔ AWS هر هفته معماری را می‌سنجد؛ دسترسی از Business+ شروع می‌شود
• آمریکا و چین کانال بحران AI می‌سازند؛ هنوز تعریف «حادثه» روشن نیست
• نمونه‌کار AI بسازید؛ سه پروژهٔ روشن از ده مخزن مبهم بهتر است