الوسم الذي راجعته ليس الكود الذي يعمل: ملفات القفل في ⁨GitHub Actions⁩

المشكلة ليست في الكود الذي تراجعه، بل في المسافة بين يوم المراجعة ويوم التشغيل. حين تكتب في سير العمل uses: some-org/deploy-action@v4 فأنت لا تشير إلى كود ثابت، بل إلى وسم يستطيع صاحب المستودع الآخر نقله متى شاء. توافق على الطلب اليوم، وبعد شهر يعمل السير نفسه على كود لم يقرأه أحد في فريقك، ومستودعك لم يتغيّر فيه حرف. لهذا أطلقت ⁨GitHub⁩ ملفات القفل لسير العمل كمعاينة عامة في 14 أكتوبر 2026، وهي متاحة لخطط ⁨Free⁩ و⁨Team⁩ إلى جانب ⁨Enterprise Cloud⁩.

لماذا لا تكفي مراجعة ملف السير

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

ما الذي يثبّته ملف القفل

بحسب ⁨GitHub⁩، تبقى المراجع المقروءة مثل ⁨@v4⁩ في ملف السير كما هي، بينما ينفّذ ⁨Actions⁩ الالتزامات المقفلة بعينها. تولّد الملف بإضافة gh actions-lock لأداة ⁨GitHub CLI⁩، فتكتب .github/workflows/actions.lock وفيه التزامات قابلة للمراجعة للإجراءات نفسها، ولاعتمادياتها غير المباشرة، ولاعتماديات سير العمل القابل لإعادة الاستخدام الذي تستدعيه. وإن تحرّك الوسم لاحقًا، فالتشغيل يبقى على الالتزام المسجّل.

الفرق عن تثبيت المعرّف يدويًا

الحل اليدوي المعروف منذ سنوات، كممارسة عامة، هو كتابة معرّف الالتزام الكامل المكوّن من 40 حرفًا في سطر ⁨uses⁩. ينجح، لكنه صعب القراءة، وسهل النسيان عند التحديث، ولا يثبّت إلا الإجراء الذي سمّيته. فإن كان إجراءً مركّبًا يستدعي إجراءات أخرى بوسوم، تبقى تلك المراجع الداخلية حرة الحركة. ملف القفل يغطي هذه الطبقة غير المباشرة. وتقول ⁨GitHub⁩ إن ⁨Dependabot⁩ حين يفتح تحديث إصدار لإجراء في سير عمل مُفعَّل فيه القفل، يعيد توليد السطر المقابل في ملف القفل داخل الطلب نفسه، فتراجع الترقية والتثبيت معًا.

البدء تدريجيًا

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

خطوة عملية تبدأ بها: اختر سير العمل الذي يحمل أخطر سر في مستودعك، وغالبًا هو سير النشر، وشغّل عليه gh actions-lock، واقرأ الالتزامات التي سجّلها، ثم أضف فحص القفل القديم إلى التكامل المستمر. بعدها انتقل إلى السير التالي. المصدر: سجل تغييرات ⁨GitHub⁩ عن ملفات القفل لسير العمل.