أمّن GitHub Actions: وسم الإصدار لا يثبت الشيفرة التي ستعمل

لحماية مسارات GitHub Actions، افصل شيفرة طلبات الدمج غير الموثوقة عن الأسرار وصلاحيات الكتابة، وثبّت الإجراءات التي يستدعيها المسار بمرجع ثابت. يوضح مرجع GitHub للاستخدام الآمن أن وسم الإصدار قد يُنقل أو يُحذف، وأن تشغيل شيفرة طلب دمج غير موثوقة في مسار ذي امتيازات قد يعرّض المستودع للاختراق.

ابدأ بحدّ الثقة، ثم راجع مراجع الإجراءات وصلاحيات كل مهمة وطريقة النشر. الموافقة على تشغيل طلب دمج لا تجعل شيفرته موثوقة، وتثبيت إجراء خارجي لا يعالج صلاحيات زائدة في المهمة التي تستدعيه. يحتاج كل ضبط إلى موضع واضح في ملف المسار أو إعدادات المستودع، حتى يمكن مراجعته عند تغيّر المسار.

افصل اختبار طلب الدمج عن المهمة ذات الامتيازات

راجع ملفات ‎.github/workflows/‎، وحدد لكل مهمة الحدث الذي يشغّلها، والشيفرة التي تجلبها، والأسرار والرموز المتاحة لها. أعطِ الأولوية للمهمة التي تنشر إصداراً أو تستطيع تعديل المستودع؛ ففيها يصبح تنفيذ مدخل غير موثوق قادراً على إحداث ضرر أكبر من مهمة اختبار بلا أسرار. افحص أوامر البناء والتثبيت أيضاً، لأنها قد تنفّذ تعليمات من الملفات التي أرسلها صاحب طلب الدمج.

عندما يكون المطلوب اختبار تغيير قادم من فرع خارجي ولا تحتاج المهمة إلى أسرار، استخدم ‎pull_request‎ بصلاحيات محدودة. أما ‎pull_request_target‎ فقد يلائم إجراءً إدارياً، مثل تصنيف الطلب، ما دام ينفّذ شيفرة الفرع الأساسي ولا يجلب رأس طلب الدمج ليبنيه أو يشغّله. مجرد جلب الملفات ليس هو التنفيذ؛ ينشأ الخطر حين تعالجها خطوة لاحقة بوصفها شيفرة، بما في ذلك أوامر تثبيت الاعتمادات والاختبارات.

ينطبق الحذر نفسه على ‎workflow_run‎ عندما يبدأ مسار ذو امتيازات بعد مسار أقل ثقة. تعامل مع الملفات الناتجة من المسار الأول بوصفها بيانات غير موثوقة، ولا تجعل خطوة النشر تنفّذ محتواها. وإذا كان التشغيل يعتمد على تعليق مثل ‎/ok-to-test‎ أو على تصنيف، فتحقق من هوية من منح الإذن واربط مراجعة الشيفرة بمعرّف الالتزام المحدد؛ فقد يتغير الفرع بعد الموافقة.

ثبّت الإجراء إلى الشيفرة التي راجعتها

افحص كل قيمة ‎uses:‎، بما فيها مراجع مسارات العمل المعاد استخدامها. الوسم مثل ‎@v6‎ يسهّل تلقّي التحديثات، لكنه لا يحدد التزاماً برمجياً واحداً على الدوام. إذا كان المستودع يستخدم ملف قفل لاعتمادات المسار، فتحقق من أنه يسجل الالتزامات الفعلية للإجراءات، بما فيها الاعتمادات المتعدية، ويتحقق من هوية مستودعاتها عند التشغيل.

في مستودع لا يستخدم ملف القفل، ثبّت الإجراء الخارجي بمعرّف الالتزام الكامل بدلاً من الوسم، وتأكد أن الالتزام ينتمي إلى مستودع الإجراء المقصود لا إلى نسخة متفرعة منه. لا تنسخ معرّفاً شكلياً من مثال توضيحي؛ استخرج معرّف الإصدار الذي راجعت شيفرته فعلاً. طبّق القرار نفسه على مسارات العمل الخارجية المعاد استخدامها، لأنها جزء من الشيفرة التي سيشغّلها المسار.

المرجع الثابت يحدد ما سيُجلب، لكنه لا يحكم على سلامة المحتوى. راجع ما يفعله الإجراء بالملفات والأسرار والرموز، ثم حدّث المرجع الثابت بمراجعة واضحة عند الحاجة إلى إصلاح أو إصدار أحدث. وإذا كانت سياسة المستودع تسمح بالوسوم، فاعلم أن الثقة بناشر الإجراء لا تمنع نقل الوسم بعد اختراق مستودعه.

مرّر عنوان طلب الدمج كبيانات، لا كنص أمر

عنوان طلب الدمج ووصفه واسم فرعه مدخلات يستطيع مقدّم الطلب التأثير فيها. في مثال شرطي غير آمن، يضع المسار ‎run: 'echo "${{ github.event.pull_request.title }}"'‎؛ إذ تُدرج قيمة العنوان في نص الأمر قبل تفسيره بواسطة الصدفة. قد يحوّل عنوان صيغ عمداً هذا الموضع إلى حقن أوامر، حتى إذا بدا ‎echo‎ نفسه بسيطاً.

البديل في خطوة تستخدم Bash هو وضع ‎PR_TITLE: "${{ github.event.pull_request.title }}"‎ تحت ‎env:‎، ثم تشغيل ‎printf '%s\n' "$PR_TITLE"‎. بهذا تصبح قيمة العنوان متغير بيئة يقرؤه الأمر، بدلاً من أن تشارك في إنشاء نص الأمر. أبقِ المتغير بين علامتي اقتباس عند استعماله في أوامر أخرى، ولا تمرّره لاحقاً إلى أداة تفسّر قيمته على أنها شيفرة أو خيارات تنفيذ.

إذا احتاج المسار إلى نشر نتيجة اختبار على طلب الدمج، فلتنتج المهمة محدودة الصلاحيات البيانات اللازمة، ولتنشرها مهمة منفصلة بامتيازات محددة. راجع صيغة البيانات التي تنتقل بينهما، خصوصاً أسماء الملفات والقطع الناتجة عن البناء. انتقال البيانات إلى مهمة موثوقة لا يغيّر مصدرها؛ الخطوة الحاسمة هي ألا تتحول إلى أمر قابل للتنفيذ داخل تلك المهمة.

ابدأ بصلاحيات فارغة واستخدم OIDC للنشر

ضع ‎permissions: {}‎ على مستوى ملف المسار، ثم امنح كل مهمة ما يلزمها صراحة؛ قد تحتاج مهمة قراءة المستودع إلى ‎contents: read‎، بينما تقتصر صلاحية ‎contents: write‎ على مهمة تحتاج فعلاً إلى تعديل محتواه. توصي قائمة OWASP الأمنية بهذا الضبط، وباشتراط الموافقة لجميع المساهمين الخارجيين بدلاً من الاكتفاء بالموافقة للمرة الأولى. اضبط أيضاً صلاحيات ‎GITHUB_TOKEN‎ الافتراضية في إعدادات المستودع على القراءة، ولا تفترض أن إخفاء الرمز من نص المسار يمنع الإجراء من الوصول إليه.

إذا كان مزود السحابة يدعم OIDC، أنشئ لديه علاقة ثقة مقيدة بالمستودع والفرع أو بيئة النشر المسموح بها. امنح مهمة النشر وحدها ‎id-token: write‎ إلى جانب صلاحيات GitHub التي تحتاجها، واستخدم إجراء المصادقة المناسب لتبادل رمز الهوية برمز وصول قصير العمر. تشرح تعليمات GitHub لتهيئة OIDC أن هذا المسار يغني عن تخزين بيانات اعتماد سحابية طويلة العمر في أسرار المستودع. صلاحية ‎id-token: write‎ تسمح بطلب رمز الهوية؛ أما الوصول إلى موارد السحابة فتحكمه شروط الثقة والصلاحيات لدى المزود.

اجعل لمهمة النشر بيئة محمية إذا كان النشر يتطلب موافقة أو يجب حصره في فروع معينة. هذه طبقة مستقلة عن موافقة تشغيل طلبات الدمج الخارجية: الأولى تضبط الوصول إلى وجهة النشر، والثانية تضبط متى تعمل شيفرة أرسلها مساهم خارجي. راجع كذلك الأسرار الثابتة المتبقية؛ لا ينبغي أن تبقى في المسار بعد نقل المصادقة السحابية التي كانت تحتاجها إلى OIDC.

احمِ تعديل ملف المسار نفسه

أضف قاعدة لملفات ‎.github/workflows/‎ في ‎CODEOWNERS‎، ثم اشترط موافقة مالكي الشيفرة في حماية الفرع أو قواعد المستودع. إدراج اسم المالك وحده لا يفرض الموافقة. ينبغي أن تصل مراجعة تغيير المشغّل أو ‎permissions‎ أو ‎uses:‎ إلى شخص يستطيع تقدير أثره قبل الدمج، لأن تعديلاً صغيراً في ملف المسار قد يغيّر حدود الثقة كلها.

فعّل فحص CodeQL لمسارات GitHub Actions، وتحقق من ظهور ‎GitHub Actions‎ ضمن اللغات المفحوصة؛ وإذا أعددت مسار فحص مخصصاً، فأدرج ‎language: actions‎. اربط نتيجة الفحص بحاجز الدمج عندما تسمح إعدادات المستودع بذلك. يفيد الفحص في اكتشاف أنماط معرضة للخطر، بينما تظل مراجعة الصلاحيات والشيفرة الخارجية والبيانات المنتقلة بين المهام عملاً مستقلاً.

احتفظ بقائمة تحقق قصيرة مع مراجعة أي تغيير في المسار:

• هل تعمل شيفرة طلب الدمج في مهمة تخلو من أسرار النشر وصلاحيات الكتابة؟
• هل ترتبط الإجراءات ومسارات العمل الخارجية بملف قفل موثوق أو بالتزامات كاملة تمت مراجعتها؟
• هل يبدأ الملف بـ‎permissions: {}‎، وتمنح كل مهمة الصلاحيات اللازمة لها فقط؟
• هل تمر مدخلات طلب الدمج عبر متغيرات أو وسائط بيانات بدلاً من إدراجها في ‎run:‎؟
• هل تطلب مهمة النشر وحدها هوية OIDC، وتخضع تغييرات المسار لموافقة ‎CODEOWNERS‎ وفحص CodeQL؟

اقرأ أيضًا:

• YouTube قد يضع وسم الإعلان تلقائيًا: الإفصاح لم يعد اختيارًا كاملًا
• npm يسمح بعشرة ناشرين موثوقين ويؤخر الإصدار حتى فحص البرمجيات الخبيثة
• فعّل مفتاح مرور GitHub من دون أن تجعل استرداد الحساب نقطة ضعف