برمجيات خبيثة تعمل وقت التثبيت، وما الذي يفحصه جدار الحزم من ⁨GitHub⁩

اعتدنا أن نتخيل الاعتمادية الخبيثة ككود يؤذي حين يشغّله التطبيق. لكن ⁨GitHub⁩ تقول في إعلانها يوم 20 أكتوبر 2026 إن عددًا متزايدًا من الهجمات لا ينتظر ذلك: الضرر يقع أثناء تثبيت الحزمة نفسه، فتُجمَع بيانات الدخول من خادم التكامل المستمر أو من جهاز المطوّر، دون أن ينفّذ تطبيقك سطرًا واحدًا من كود الحزمة. حين يبدأ أول اختبار، يكون الرمز قد خرج بالفعل. ردّ ⁨GitHub⁩ هو جدار حماية للحزم في معاينة عامة، ومن المفيد أن تعرف ما يفعله، وكم هو ضيق نطاقه حتى الآن.

ما الذي يفحصه الجدار

بحسب وصف ⁨GitHub⁩، يقف الجدار بين نقاط الطرف، أي خوادم ⁨Actions⁩ ووكلاء البرمجة، وبين سجل الحزم الأصلي، ويفحص طلبات البيانات الوصفية والتنزيلات معًا. السياسات المتاحة اليوم: فترة انتظار قابلة للضبط، وفحص الحزم مقابل ⁨GitHub Advisory Database⁩ بحثًا عن تحذيرات برمجيات خبيثة أو ثغرات، وفحوص لسلسلة التوريد مثل تراجع مستوى الشهادة. ويجب ضبط كل نقطة طرف لتستخدم الجدار بدل السجل مباشرة، وإن حُجبت حزمة بالخطأ يمكنك طلب استثناء.

ما الذي لا يغطيه

كن دقيقًا في النطاق قبل أن تبني عليه خطة. تقول ⁨GitHub⁩ إن المعاينة لعملاء ⁨Enterprise Cloud⁩، بما فيه خيار إقامة البيانات، وإنها تدعم حزم ⁨npm⁩ فقط حاليًا. أي أن من يعمل على خطة ⁨Free⁩ أو ⁨Team⁩ لا يملكه، وفي مشروع ⁨PHP⁩ لا يمر شيء من تثبيت ⁨Composer⁩ عبره. وهو مجاني خلال المعاينة، وتقول ⁨GitHub⁩ إنه سيُحتسب لاحقًا بطريقة مشابهة لفوترة ⁨Actions⁩.

جهة النشر تشدّدت في الشهر نفسه

تغييران من ⁨npm⁩ في 2 أكتوبر يضغطان من الطرف الآخر. صار npm stage publish قادرًا على إنشاء حزمة جديدة تمامًا: يدخل إصدارها الأول طابورًا مرحليًا، ولا يصبح قابلًا للتثبيت حتى يرقّيه أحد المشرفين. والإعدادات غير المؤكَّدة للنشر الموثوق تنتهي الآن بعد 48 ساعة من إنشائها، وهذا يقلّل خطر الثقة في اسم مستودع أو مشروع ينتقل لاحقًا إلى مالك آخر، ويتأكد الإعداد بأول نشر ناجح. كما ترفض ⁨npm⁩ الآن رموز النشر الموثوق القادمة من أحداث issue_comment، إلى جانب القيد القائم على pull_request_target، وتوجّهك إلى أحداث ⁨push⁩ أو ⁨release⁩ أو ⁨workflow_dispatch⁩ بدلًا منها.

ما تستطيع فعله على أي خطة

ما يلي إرشاد عام، لا ادعاء عن الجدار. احفظ ملفات القفل في المستودع وثبّت منها: npm ci في الجافاسكربت، وcomposer install مقابل composer.lock في ⁨PHP⁩. شغّل فحص التحذيرات في التكامل المستمر. الخيار --ignore-scripts يتخطى سكربتات دورة حياة ⁨npm⁩، لكنه ليس دفاعًا كاملًا، لأن هجمات وقت التثبيت ليست كلها سكربتات، وبعض الحزم تحتاجها فعلًا. وفترة الانتظار اليدوية تعني ألا ترقّي إلى إصدار نُشر في الأيام القليلة الماضية، لأن أغلب الإصدارات الخبيثة تُكتشف بسرعة. أما الطبقة الأهم: لا تشغّل التثبيت على جهاز يحمل بيانات دخول طويلة العمر.

npm ci
composer install --no-interaction
composer audit

هذا الموقع مبني على ⁨Laravel⁩ مع قليل من أدوات الجافاسكربت، أي أن الجدار لن يغطي منه إلا النصف الأصغر. وفي جانب ⁨PHP⁩ البديل بسيط: ثبّت من composer.lock المحفوظ في المستودع، وشغّل composer audit في التكامل المستمر، ولا تدع تحديثًا يدخل دون أن يقرأه أحد. وإن كنت على ⁨Enterprise Cloud⁩، فوجّه خادمًا واحدًا إلى الجدار، وراقب ما يحجبه أسبوعًا، ثم وسّع. المصدر: سجل تغييرات ⁨GitHub⁩ عن جدار حماية الحزم.