اتخذت GitHub خطوة جديدة لتعزيز حماية بيئة التطوير لديها، بعدما أصبحت هجمات pwn request واحدة من أبرز التهديدات التي تستهدف مستودعات البرمجيات وسلاسل التوريد البرمجية. وبدأت الشركة تطبيق إعدادات أكثر صرامة على أداة actions/checkout لمنع استغلال بعض تدفقات العمل في GitHub Actions بطريقة تسمح بتنفيذ كود غير موثوق بصلاحيات كاملة.
التغيير الجديد يتركز على حالات استخدام pull_request_target وworkflow_run عندما يحاول سير العمل جلب شيفرة من طلب سحب لم تتم مراجعتها بعد، خصوصاً إذا كان الطلب قادماً من نسخة fork خارجية. في هذه الحالات، أصبحت الأداة توقف التنفيذ تلقائياً وتفشل المهمة بدلاً من السماح بتمرير المحتوى إلى بيئة العمل دون ضوابط كافية.
وتعني هذه الخطوة أن GitHub تحاول الانتقال من نموذج يعتمد على وعي المطور وخبرته إلى نموذج أكثر تشدداً يقوم على الأمان الافتراضي. فبدلاً من ترك القرار للمستخدمين في كل مشروع على حدة، أصبحت المنصة تفرض حماية مبدئية ضد أحد أكثر أنماط الاستغلال شيوعاً في أنظمة التكامل والنشر المستمر.
ما الذي تغيّر في actions/checkout
بحسب التحديثات الأخيرة، فإن الإصدار v7 من الأداة يمنع تلقائياً سيناريوهات محددة قد تؤدي إلى تشغيل شيفرة يسيطر عليها المهاجم داخل بيئة العمل. ويظهر هذا المنع عند محاولة استخدام الأداة داخل تدفقات pull_request_target أو workflow_run بطريقة تؤدي إلى سحب كود غير موثوق من fork قبل مراجعته.
ولم تعد GitHub تكتفي بالتحذير أو الاعتماد على التوصيات العامة، بل جعلت السلوك الجديد هو الوضع الافتراضي. وإذا أراد فريق تطوير الاستمرار في هذا النمط رغم المخاطر، فعليه تفعيل استثناء صريح عبر الوسم allow-unsafe-pr-checkout، وهو ما يضمن أن قرار تجاوز الحماية سيكون متعمداً وواضحاً وليس نتيجة إعداد خاطئ.
كما أعلنت الشركة أن هذه الإعدادات ستُعاد مواءمتها مع جميع الإصدارات الرئيسية المدعومة بدءاً من 16 يوليو، ما يعني أن مستودعات كثيرة ستستفيد من التحديث تلقائياً إذا كانت تعتمد على وسم رئيسي متحرك مثل actions/checkout@v4. أما المشاريع المثبتة على SHA محدد أو إصدار فرعي أو تصحيح دقيق، فلن يصلها التغيير تلقائياً، وستحتاج إلى التحديث عبر أدوات الاعتماد على التبعيات مثل Dependabot أو عبر آلية الترقية المعتادة.
لماذا تعتبر هذه الهجمات خطيرة
تكمن خطورة هجمات pwn request في أنها تستغل تداخلاً بين أمرين مشروعين: الحاجة إلى الوصول إلى صلاحيات كافية لإنجاز بعض الأتمتة، والرغبة في التعامل مع مساهمات قادمة من أطراف خارجية. فـpull_request يوفر مستوى حماية جيداً لأنه يتجنب تمرير الأسرار مثل مفاتيح API ورموز الخدمة، لكنه في المقابل يقيّد بعض الوظائف. ولهذا يلجأ بعض المطورين إلى pull_request_target لأنه يمنح الصلاحيات اللازمة، لكن سوء استخدامه يفتح الباب أمام تنفيذ تعليمات من مصدر غير موثوق.
المشكلة ليست في آلية pull_request_target نفسها، بل في استخدامها مع إعدادات تسمح بسحب الشيفرة من fork غير خاضع للمراجعة داخل خطوة تمتلك صلاحيات واسعة. في هذه الحالة، قد يتمكن المهاجم من تشغيل أوامر داخل بيئة البناء والوصول إلى أسرار حساسة أو العبث بمخرجات النشر أو حتى حقن برمجيات خبيثة في سلسلة التوريد.
وقد برز هذا النوع من الهجمات في حوادث حديثة أثرت في مستودعات مفتوحة المصدر، بينها استهداف واسع النطاق من مجموعة TeamPCP، إضافة إلى حادثة تسببت في اختراق 170 حزمة npm، بما فيها أجزاء مرتبطة بمنظومة TanStack Router، مستفيدة من استغلال من هذا النوع. كما واجهت GitHub نفسها خرقاً منفصلاً لم يعتمد على pwn request، وأسفر عن تسرب شيفرة مصدرية من نحو 3800 مستودع داخلي.
دلالات التحول نحو الأمان الافتراضي
التغيير الذي أدخلته GitHub لا يقتصر على سد ثغرة محددة، بل يعكس اتجاهاً أوسع في منصات التطوير السحابية نحو فرض ضوابط أمنية أكثر صرامة على نحو تلقائي. هذا التوجه مهم لأن كثيراً من الحوادث لا تحدث بسبب تعقيد التقنيات نفسها، بل بسبب الإعدادات الافتراضية الضعيفة أو سوء الفهم لكيفية عمل تدفقات الأتمتة.
كما أن اعتماد قواعد أمان افتراضية يقلل الفجوة بين فرق التطوير الكبيرة والفرق الصغيرة. فالشركات الكبرى غالباً ما تمتلك خبرات أمنية داخلية وأدوات تدقيق متقدمة، بينما تعتمد فرق أصغر على الإعدادات الجاهزة. لذلك، عندما تصبح المنصة نفسها أكثر صرامة، تنخفض احتمالات الوقوع في أخطاء مكلفة حتى لدى الفرق الأقل نضجاً أمنياً.
وفي الوقت نفسه، لا يعني هذا أن الخطر انتهى. فGitHub نفسها أشارت إلى أن هجمات pwn request يمكن أن تظهر في أشكال أخرى، وأن مزيداً من التشديد قد يُبحث في الإصدارات المقبلة. هذا يعكس واقعاً معروفاً في أمن البرمجيات: كلما أُغلِق مسار استغلال شائع، يبحث المهاجمون عن مسار بديل في النظام نفسه.
ما الذي ينبغي على المطورين فعله الآن
بالنسبة للفرق التي تستخدم GitHub Actions، فإن الرسالة الأساسية واضحة: مراجعة تدفقات العمل التي تعتمد على pull_request_target أو أي آلية تمنح صلاحيات مرتفعة لمحتوى قادم من خارج المشروع. كما ينبغي التحقق من طريقة استخدام actions/checkout، خصوصاً إذا كان سير العمل يجلب شيفرة من طلبات سحب غير موثوقة أو من fork لم تخضع للمراجعة الكاملة.
كذلك، من المهم فحص ما إذا كانت المستودعات مربوطة بإصدار رئيسي متحرك أو مثبتة على نسخة دقيقة. فالمشاريع التي تعتمد على وسم رئيسي مثل @v4 ستتلقى التحديثات الأمنية الجديدة تلقائياً، بينما تحتاج المستودعات المثبتة على إصدارات أدق إلى تدخل مباشر. وفي كل الأحوال، يظل التحقق المستمر من صلاحيات التدفقات وسرعة تحديث الحزم جزءاً أساسياً من أي استراتيجية أمان حديثة.
وبينما تتسارع الهجمات على بيئات التطوير، يبدو أن GitHub تسعى إلى تقليص مساحة الخطأ البشري قبل أن تتحول إلى خرق واسع. الخطوة الجديدة ليست نهاية للتهديد، لكنها تمثل تحولاً مهماً في طريقة تعامل المنصة مع أمن أدواتها الأكثر استخداماً، وتضع معياراً أعلى للحماية داخل أنظمة البناء والنشر المستمر.