تتجه GitHub إلى تغيير مهم في طريقة عمل مدير الحزم npm، بعد أن أعلنت أن الإعداد الافتراضي سيتحول في يوليو إلى تعطيل تشغيل سكربتات التثبيت تلقائياً. ويعني ذلك أن أوامر مثل preinstall وinstall وpostinstall لن تعمل من تلقاء نفسها داخل الحزم التابعة، ما لم يفعّلها المطورون بشكل صريح ضمن المشروع.
الخطوة تمثل تحولاً واضحاً في فلسفة الأمان داخل واحدة من أكبر منصات البرمجيات مفتوحة المصدر. فبدلاً من السماح للتنفيذ التلقائي أثناء التثبيت، ستصبح القاعدة الجديدة قائمة على الموافقة المسبقة، وهو ما يضيف طبقة تحكم مهمة أمام واحدة من أكثر قنوات الهجوم استخداماً في استهداف سلاسل التوريد البرمجية.
ما الذي سيتغير في npm
بحسب التحديث المرتقب، سيصبح allowScripts مضبوطاً على الوضع المعطل افتراضياً. وعملياً، هذا يعني أن npm install لن يشغّل سكربتات التثبيت الخاصة بالحزم التابعة إلا إذا منحها المشروع تصريحاً واضحاً. وينطبق ذلك أيضاً على بعض السيناريوهات الأخرى مثل الحزم القادمة من git أو file أو link، إضافة إلى حالات البناء الأصلية التي تعتمد على node-gyp.
حتى عندما لا يحتوي المشروع على سكربت تثبيت صريح، قد يظل التنفيذ محظوراً إذا كان npm سيجري rebuild تلقائياً عبر node-gyp. هذا التفصيل مهم لأن عدداً كبيراً من المشاريع يعتمد على خطوات بناء غير مباشرة، ما يجعل التغيير أوسع من مجرد إغلاق باب أمام أوامر برمجية خبيثة.
ورغم أن GitHub لم تلغِ هذه الوظيفة بالكامل، فإنها تنقلها من السلوك الافتراضي إلى خيار يتطلب تفعيلًا مقصوداً. بهذه الطريقة، يبقى بالإمكان استخدام الميزة عند الضرورة، لكن ضمن نطاق مراقب ومعلوم داخل المشروع.
لماذا يعتبر هذا المسار خطيراً أمنياً
تنفيذ السكربتات أثناء التثبيت ظل لسنوات نقطة حساسة في بيئة npm، لأنه يمنح الشيفرة الوصول إلى لحظة بالغة الأهمية داخل دورة تطوير البرمجيات: لحظة تثبيت الاعتمادات. وفي هذه المرحلة قد تكون الأنظمة في بيئات تملك وصولاً إلى رموز المصادقة، والمخازن الداخلية، وملفات البناء، وأحياناً مسارات النشر نفسها.
هذا النوع من التنفيذ التلقائي استُخدم مراراً في هجمات سلسلة التوريد، لأن المخترق لا يحتاج دائماً إلى اختراق التطبيق النهائي مباشرة. أحياناً يكفي زرع شيفرة داخل حزمة طرف ثالث حتى تنتقل العدوى بسرعة إلى عدد كبير من المشاريع التي تعتمد عليها.
ويرى خبراء أمنيون أن تعطيل هذا المسار افتراضياً لا يلغي الخطر بالكامل، لكنه يزيل أحد أكثر الأبواب سهولة أمام المهاجمين. كما أن الهجمات الأكثر تعقيداً ستتجه غالباً إلى بدائل أخرى مثل الحسابات المخترقة للمحافظين، أو التباس الاعتماديات، أو التلاعب بسير عمل GitHub Actions، أو استغلال الحزم العابرة في الشجرة البرمجية.
هل يأتي التغيير متأخراً
الآراء في قطاع التطوير والأمن تميل إلى الترحيب بالخطوة، لكن كثيرين يرون أنها جاءت بعد تأخير واضح. فمنافسون مثل Yarn وpnpm وBun سبق أن اتخذوا خطوات مشابهة لجعل تنفيذ السكربتات الخارجية غير مسموح به افتراضياً أو أكثر تقييداً.
من هذا المنظور، لا تبدو GitHub وكأنها تقدم نموذجاً جديداً بقدر ما تلحق بركب اتجه إليه القطاع بالفعل. ومع ذلك، تظل أهمية الخطوة كبيرة لأن npm ما يزال أحد أكثر مديري الحزم استخداماً على مستوى العالم، وأي تغيير في سلوكه الافتراضي ينعكس على ملايين البيئات التطويرية.
ويرتبط التأخر أيضاً بعامل التوافقية. فالكثير من الحزم المشروعة يستخدم سكربتات التثبيت لتجميع وحدات أصلية، أو تنزيل ملفات ثنائية مخصصة لمنصات مختلفة، أو إتمام خطوات إعداد لا يمكن تنفيذها بطريقة أخرى بسهولة. لذلك كان تغيير السلوك الافتراضي يعني دائماً الدخول في منطقة حساسة بين الأمان والاستقرار التشغيلي.
الأمان الافتراضي يصبح القاعدة
أحد أبرز ملامح هذا القرار هو أنه يعكس انتقالاً أوسع في الصناعة من الثقة الضمنية إلى الثقة الصريحة. لم يعد مقبولاً أن تعمل الشيفرة أثناء التثبيت لمجرد أنها جزء من الحزمة. الآن، على الفرق أن تقرر مسبقاً ما الذي يُسمح له بالتنفيذ، وأن تسجل ذلك داخل المستودع ليكون قابلاً للمراجعة.
هذا التحول مهم لأنه يضيف أثراً توثيقياً أيضاً. فبدلاً من أن يمر التنفيذ بصمت في الخلفية، يصبح جزءاً من سجل المشروع ومراجعاته، ما يساعد فرق الأمن والامتثال على معرفة سبب السماح به، ومن وافق عليه، وما إذا كان ضرورياً فعلاً.
لكن هذا لا يعني أن الموافقة ستكون مجرد خانة اختيار شكلية. فالتوجه الجديد يفرض على الفرق أن تراقب ما إذا كانت الحزمة مباشرة أو متداولة عبر تبعيات أخرى، وما إذا كان السكربت مطلوباً لإنجاز البناء، أم أنه يضيف مخاطرة لا داعي لها. وهذا بالضبط ما يجعل التغيير ذا أثر عملي يتجاوز مجرد إعداد تقني.
ماذا تعني الخطوة لمستقبل الحزم البرمجية
الرسالة الأوسع هنا أن مديري الحزم لم يعودوا مجرد أدوات لتحميل الاعتماديات، بل أصبحوا نقاط حوكمة أمنية داخل سلسلة التطوير. فكلما زادت الهجمات التي تستغل الثقة التلقائية، زادت الحاجة إلى جعل السلوك الأكثر أماناً هو السلوك الافتراضي، لا الاستثناء.
وفي حالة npm، قد لا يوقف هذا القرار كل أشكال الهجمات، لكنه يرفع كلفة الاستغلال ويقلل من مساحة الحركة أمام المهاجمين الأقل تعقيداً. كما أنه يدفع المؤسسات إلى مراجعة كيفية إدارة الاعتماديات لديها، والتمييز بين ما هو ضروري فعلاً وما هو مجرد عادة قديمة في بيئة التطوير.
من هنا، تبدو الخطوة أكثر من مجرد تعديل في الإعدادات. إنها إعادة تعريف لطريقة التعامل مع الثقة داخل منظومة برمجية ضخمة، ومحاولة لجعل الأمان جزءاً من السلوك الطبيعي بدلاً من أن يكون طبقة إضافية يجري تفعيلها لاحقاً.