كيف تحمي GitHub Actions تبعك إذا حدا غيّر tag لـ action بتستعملها؟

أمر gh actions-lock بيكتب ملف actions.lock يلي بيثبّت كل action وتبعياتها على commit محدد، فبتشغّل GitHub Actions الـ commit المقفول حتى لو تحرّك الـ tag.

نُشر في 21 أكتوبر 202612 دقيقة قراءة#GitHub Actions #أمن سلسلة التوريد #CI/CD

إذا عندك مشروع مفتوح أو فريق صغير على GitHub، غالباً كل workflow عندك فيها سطور متل uses: actions/checkout@v7.0.1، وكل سطر منها معتمد على إنو الـ tag لسا بيأشّر على نفس الكود يلي شفته. يوم 14 تشرين الأول 2026 فتحت GitHub معاينة عامة لملف قفل بيثبّت هالكود، وهو متاح عالخطة المجانية كمان. هون بتقفل الـ workflows عندك، وبتضيف فحص بيفشل على الـ pull request إذا لمس الـ workflows وملف القفل صار قديم.

ليش الـ tag ممكن يشغّل كود ما راجعته؟

الـ tag اسم بيأشّر على commit، وأي حدا عنده صلاحية على ريبو الـ action بيقدر يحرّكه لـ commit تاني. GitHub Actions بتحوّل الاسم لـ commit وقت التشغيل، فالتشغيلة الجاية بتنفّذ الكود الجديد بلا أي تغيير بريبوك.

الاستثناء هو الـ tag التابع لـ release مفعّل عليه immutable releases: حسب التوثيق، هالـ tag بيضل على نفس الـ commit، وما بيتغيّر ولا بينحذف طول ما الـ release موجود. بس هالإعداد بينفعّل على ريبو الـ action أو منظمته، فالقرار عند صاحبها مش عندك.

حسب تنبيه Aqua Security الأمني GHSA-69fq-xp46-6x23 (CVE-2026-33634) بقاعدة GitHub Advisory Database، يوم 19 آذار 2026 مهاجم استعمل بيانات دخول مسروقة وحرّك 76 من أصل 77 tag بريبو aquasecurity/trivy-action لـ commits فيها برنامج بيسرق الأسرار، وبدّل الـ 7 tags كلهن بريبو aquasecurity/setup-trivy. الكود الخبيث كان بيقرا ذاكرة الـ runner لحتى يطلّع الأسرار منها، وبيدوّر بالملفات على مفاتيح SSH وبيانات دخول السحابة. والتنبيه بيقول إنو الـ tag 0.35.0 تبع trivy-action ما تأثر بالهجوم، لأنو كان محمي بـ immutable releases.

حتى يلي كان مثبّت trivy-action على SHA قديم ما سلم دايماً. الـ SHA هو المعرّف الكامل للـ commit، والتثبيت عليه أعطى هالناس نسخة سليمة من trivy-action. بس إذا كان الـ commit أقدم من 9 نيسان 2025، trivy-action نفسها كانت بتنادي setup-trivy بلا تثبيت، فوصلهم الكود الخبيث من هالتبعية إذا اشتغلت الـ workflow بساعات الهجوم. يعني الـ SHA بملف الـ workflow بيحمي السطر يلي كتبته إنت، وما بيوصل للتبعيات غير المباشرة: الـ actions يلي بتناديها الـ action من جوّا.

شو هو ملف actions.lock وشو بيسجّل؟

ملف القفل actions.lock هو ملف بـ .github/workflows/ بيسجّل لكل action بتستعملها، ولكل تبعية إلها، الـ commit يلي كان الـ tag بيأشّر عليه وقت القفل. لما تكون الـ workflow مقفولة، GitHub Actions بتشغّل هالـ commit حتى لو الـ tag تحرّك.

بتضل كاتب الـ tag بالـ workflow متل العادة، والقفل بيحدد شو بيشتغل فعلاً. هاد مقطع من ملف القفل تبع ريبو gh-actions-lock نفسه، متل ما كان يوم 21 تشرين الأول 2026:

workflows:
    '.github/workflows/release.yml':
        - 'actions/checkout@v7.0.1'
        - 'cli/gh-extension-precompile@v2.2.0'
dependencies:
    'cli/gh-extension-precompile@v2.2.0':
        ref: 'v2.2.0'
        commit: 'sha1-76961aa3bd1123d0a6fd42d0a41aca0696937c39'
        owner_id: 59704711
        repo_id: 421583656
        uses:
            - 'actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32'
            - 'actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c'

الـ workflow بتنادي cli/gh-extension-precompile بس، والقفل سجّل كمان الـ actions يلي هي بتناديها من جوّا، كل وحدة على commit كامل. وهاد نفس الطريق يلي وصل منه الكود الخبيث بحادثة trivy. كل تبعية بالملف فيها:

ref: الـ tag أو الفرع يلي كاتبه بالـ workflow.
commit: الكود يلي رح يشتغل.
owner_id وrepo_id: رقمين لهوية الريبو، وGitHub Actions بتتأكد فيهن وقت التشغيل إنو الريبو ورا الاسم لسا نفسه يلي قفلته.

وحسب صفحة الإضافة، الـ runner بيفحص كمان أول ما يبلّش الـ job إنو الـ commit المقفول لسا موجود، ولسا بتاريخ الـ tag أو الفرع يلي انسجّل بالقفل. إذا فشل واحد من هالفحوص، الـ runner بيرفض الـ commit والتشغيل بيوقف.

القفل بيوصل للتبعيات غير المباشرة، إلا تبعيات الـ reusable workflows: هدول بيغطيهن ملف القفل بالريبو يلي فيه الـ reusable workflow نفسها. وما بيثبّت صور الـ Docker يلي بتسحبها الـ workflow، فأي صورة مش مثبّتة بـ @sha256: بتطلع تنبيه container-image بلا ما يوقّف التشغيل.

توثيق GitHub عن ملفات القفل بيقول إنو الريبو يلي عنده ملف قفل ما عاد بيحتاج تثبيت الـ SHA جوّا ملفات الـ workflow، لأن القفل بيغطي التبعيات غير المباشرة وبيسجّل هوية الريبو، والملفات بتضل أسهل للقراية.

الميزة معاينة عامة لخطط Free وTeam وEnterprise Cloud حسب الإعلان، وGitHub عدّلت قائمة الخطط فيه بنفس يوم النشر. بس صفحتي التوثيق عن قفل التبعيات وفرض القفل لسا كاتبين GitHub Enterprise Cloud لحاله بخانة «Who can use this feature?» يوم 21 تشرين الأول 2026، والإعلان هو الأحدث. والإضافة لسا قبل الإصدار 1.0، وصفحتها بتنبّه إنو شكل الملف والخيارات وطريقة الشغل ممكن يتغيروا بلا إنذار.

كيف تعمل أول ملف قفل لمشروعك؟

بتثبّت إضافة gh actions-lock لـ GitHub CLI، وبتشغّلها من جذر الريبو على workflow وحدة أو على الكل، وبتراجع الـ diff كله قبل الـ commit.

الخطوات بالترتيب، من صفحة قفل التبعيات بتوثيق GitHub:

راجع كل سطر uses: وتأكد إنو بيأشّر على نسخة مدعومة وحديثة من الـ action، لأن القفل رح يثبّت يلي موجود هلق. إذا ما عندك Dependabot للـ actions، فعّله قبل (تحت بقسم Dependabot).
ثبّت الإضافة، وبتصير عندك gh actions-lock:
```
 gh extension install github/gh-actions-lock
```
جرّب الأمر على workflow وحدة بالأول، الأحسن يلي بتعمل deploy أو بتوصل لأسرار. بيطلع معك ملف actions.lock فيه هالـ workflow بس:
```
 gh actions-lock .github/workflows/ci.yml
```
بعدها شغّل الأمر بلا مسار، فبيقفل كل الـ workflows بـ .github/workflows/. خلّص هالخطوة قبل ما تضيف فحص --verify (القسم الجاي)، لأنه بيفشل على أي workflow مش مقفولة:
```
 gh actions-lock
```
افتح الـ diff وراجعه كله. الإضافة بتعدّل ملفات الـ workflow كمان: بتحوّل octo-org/deploy-action@v3 لنسخة محددة متل @v3.1.0 بلا ما يتغيّر الـ commit، وبتحوّل uses: ./… لـ uses: $/…، وهالمرجع دايماً بينحل للـ commit يلي عم يشتغل هلق.
شوف قائمة الـ actions المسموحة إذا ريبوك أو منظمتك عندها وحدة. بعد القفل، القائمة بتنفحص على الـ SHA المقفول، فسطر متل actions/checkout@v6 ما عاد بيطابق، وبدّك wildcard أو الـ SHA الكامل.
اعمل commit لملف القفل ولتعديلات الـ workflow سوا.

وقبل ما تقفل، هاد تحذير GitHub بالإعلان حرفياً:

«Locking does not determine whether the dependency itself is safe, so review dependencies before locking them.»

يعني القفل بيثبّت يلي موجود وقت ما تشغّل الأمر، سليم أو لأ.

كيف تتأكد إنو ملف القفل مش قديم قبل الدمج؟

أمر gh actions-lock --verify بيفحص ملف القفل بلا ما يعدّل ولا ملف، وبيطلع بخطأ إذا كان قديم. لهيك بينحط بـ job بيشتغل على الـ pull requests.

من الإصدار v0.2.0 الفحص صار أشد. ملاحظات الإصدار بتقول إنو --verify بيفشل على أي workflow ما إلها سطر بالقفل، وعلى أي سطر بالقفل ما في workflow عم تستعمله، والحل إنك تشغّل gh actions-lock مرة وتعمل commit للنتيجة. فمكان هالـ job بعد ما تقفل كل الـ workflows، وإلا رح يفشل من أول pull request.

صفحة فرض القفل بالتوثيق بتوصف job اسمه verify بيشغّل هالأمر على الـ pull requests، وبيشتغل كل ما تغيّر شي بـ .github/workflows/** أو بأي action.yml. هيك ممكن يطلع ملفه:

name: actions-lock-verify

on:
  pull_request:
    paths:
      - ".github/workflows/**"
      - "**/action.yml"
      - "**/action.yaml"

permissions:
  contents: read

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7.0.1
      - run: |
          gh extension install github/gh-actions-lock --pin v0.2.0
          gh actions-lock --verify
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

الـ GitHub CLI موجود أصلاً على الـ runners تبع GitHub، بس كل خطوة بتستعمله بدها GH_TOKEN. و--pin v0.2.0 بيثبّت الإضافة نفسها على آخر إصدار إلها لحد 21 تشرين الأول 2026، لحتى ما يتغيّر الفحص تحتك. هالـ workflow نفسها فيها uses:، فشغّل gh actions-lock مرة تانية بعد ما تضيفها، وحط ملفها مع القفل بنفس الـ commit، وإلا الفحص رح يفشل عليها هي.

بهالشكل الـ job بيشتغل بس على الـ pull requests يلي بتلمس الـ workflows أو ملفات الـ action، وما بيمنع الدمج إلا إذا خليته فحص إجباري (required status check) بقواعد حماية الفرع. إذا بدك تخليه إجباري، شيل paths: لحتى يشتغل على كل pull request: حسب توثيق GitHub عن الفحوص الإجبارية، الفحص الإجباري يلي انتخطى بفلتر المسارات بيضل بحالة Pending وبيوقّف الدمج. وبالحالتين جرّبه على pull request تجريبي قبل.

إذا بدك تلقط المشكلة قبل ما يصير في commit، حط gh actions-lock --verify-local --no-fix بـ pre-commit hook. هالأمر بيشتغل بلا إنترنت وبلا تسجيل دخول، وبيتأكد إنو كل تبعية إلها سطر بالقفل، فهو كمان بيفشل على أي workflow مش مقفولة. بس ما بيعيد فحص الـ commits مع GitHub، فالفحص الكامل بيضل --verify بالـ CI.

شو بتعمل إذا الفحص قال إنو tag تحرّك؟

افتح تاريخ ريبو الـ action أول شي، وشوف مين حرّك الـ tag وليش. إذا التحريك طبيعي، gh actions-lock --relock بيرجع يحل كل المراجع ويكتب الـ commits الجديدة. وإذا الـ commit القديم ما عاد موجود بالريبو أبداً، --relock لحاله بيضل يعطي خطأ، وبتقبل الجديد بـ gh actions-lock --relock --accept-moved.

وأي pull request بيغيّر ملف القفل بتراجعه متل أي تحديث تبعية. commit تغيّر يعني الكود يلي رح يشتغل تغيّر. أما owner_id أو repo_id تغيّر فنادر، ومعناه إنو الريبو ورا الاسم مش هو يلي قفلته، فوقّف وافحص قبل الدمج. التوثيق بيقترح كمان تحط .github/workflows/actions.lock بملف CODEOWNERS، لحتى يوصل كل تغيير فيه لمين مسؤول عن أمان البناء.

إمتى تفرض القفل على كل الـ workflows؟

بعد ما يصير فحص --verify شغّال وما عم يوقّف شغل حدا بلا سبب. سياسة Require lockfile بتمنع أي workflow فيها uses: من إنها تشتغل إذا مش مقفولة. بتلاقيها من Settings، تحت Actions، بصفحة Policies، وأدمن الريبو بيقدر يفعّلها.

حسب صفحة سياسات التشغيل، هالسياسات متاحة لكل الريبوهات العامة، وللريبوهات الخاصة على Team أو Enterprise بس. ووضع Evaluate، يلي بيورجيك شو كان رح ينحجب بلا ما يحجبه، لـ Enterprise Cloud بس. يعني إذا ما عندك Enterprise Cloud، السياسة بتشتغل على Active من أول يوم، فخلي القفل محدّث قبلها، وإلا بتوقف كل workflow استهدفتها السياسة وهي مش مقفولة.

شو بيعمل Dependabot مع ملف القفل؟

لما Dependabot بيفتح تحديث لـ action بـ workflow مقفولة، بيولّد سطرها بملف القفل بنفس الـ pull request، فالـ workflow والقفل بيضلوا متطابقين. بس Dependabot ما بيقفل workflow جديدة عنك.

إذا حدّث تبعية بـ workflow ما إلها سطر بالقفل، بيكتفي بإنو يقلّك إنها بدها onboarding، فالـ workflow الجديدة بتقفلها إنت بـ gh actions-lock. هاد ملف .github/dependabot.yml فيه مثال توثيق Dependabot للـ actions: تحديثات أسبوعية للـ actions، ومعها حزم npm مع انتظار 7 أيام قبل أي نسخة جديدة:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

الـ cooldown هو عدد أيام بيستناهن Dependabot بعد نزول نسخة قبل ما يقترحها. حسب صفحة ضبط طلبات Dependabot، الرقم لازم يكون بين 1 و90، وDependabot بيستنى 3 أيام بالأساس حتى بلا cooldown. الانتظار بيشمل تحديثات النسخ بس، وتحديثات الأمان ما بتستنى هالأيام.

GitHub بتقترح كمان مهارة لـ Copilot بتقلّه يولّد ملف القفل من جديد كل ما عدّل workflow أو action محلية، وما يلمس الملف بإيده. وبتقول عنها إنها بتسهّل الشغل وما بتنحسب حماية، لأنها بتغطي بس التعديلات يلي بيعملها Copilot. نفس السطر بينحط بأي مهارة لوكيل برمجة متل Claude Code، والمهارات يلي عم حضّرها لهالوكلاء بقسم مهارات AI.

شو هو package firewall وهل بيلزم فريقك؟

الـ package firewall خدمة جديدة من GitHub بتقعد بين الـ runners ووكلاء البرمجة وبين سجل الحزم، وبتفحص كل طلب وكل تنزيل حسب سياسة بيحطها الأدمن. هي معاينة عامة من 20 تشرين الأول 2026 لعملاء Enterprise Cloud وحدهم، وبتدعم حزم npm بس.

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

الفحص	شو بيعمل	الافتراضي
البرمجيات الخبيثة المعروفة	بيحجب أي حزمة إلها تنبيه <span dir="ltr">malware</span> بـ <span dir="ltr">GitHub Advisory Database</span>	شغّال
تنبيهات الثغرات	بيحجب النسخة إذا إلها تنبيه ثغرة من الخطورة يلي بتختارها أو أعلى	<span dir="ltr">Critical</span> بس
تراجع الـ <span dir="ltr">attestation</span>	إذا النسخ القديمة كان إلها <span dir="ltr">SLSA attestations</span> والنسخة المطلوبة لأ، بيحجبها، لأن غيابها ممكن يعني إنو النشر نفسه انخرق	شغّال
سكربتات تثبيت جديدة	بيحجب الحزمة إذا ضافت من وقت قريب سكربت `preinstall` أو `postinstall`	شغّال
أقل عمر للنسخة	فترة <span dir="ltr">cooldown</span>: بيحجب أي نسخة عمرها أقل من عدد أيام بين 1 و365	يوم واحد

إذا انحجبت حزمة بالغلط، رسالة npm أو سجل الـ CI بيعطيك رابط لطلب استثناء، وأدمن المؤسسة بيراجع الطلب. الخدمة مجانية بفترة المعاينة، ولما توصل للإصدار العام رح تنحسب حسب الاستهلاك، متل فاتورة Actions.

على Free أو Team ما عندك هالطبقة. الـ cooldown بـ Dependabot بيقرّبك من فحص العمر، بس هو بيأخّر اقتراحات Dependabot وحدها، وما بيوقّف npm install يلي بتكتبه إنت. الباقي عندك هو ملف القفل للـ actions، ومراجعة أي pull request بيغيّر package-lock.json أو actions.lock متل ما بتراجع الكود.

من وين تبلّش هلق؟

جرّب gh actions-lock اليوم على الـ workflow يلي بتعمل deploy أو بتوصل لأسرار، وراجع الـ diff. بعدها اقفل الكل بنفس الأمر بلا مسار، وضيف job الـ --verify بنفس الـ pull request.

ملف القفل بيحمي خط البناء، بس ما بيفحص تطبيقك نفسه: مين بيوصل لبيانات مين، وتسجيل الدخول، والملفات المخزّنة. إذا بدك حدا يجرّب منصتك متل ما بيجرّبها مهاجم، هاد شغل مُحَصَّن.

وللكود نفسه قبل ما يوصل للـ CI، حزمة المهارات الأمنية (لسا قيد التحضير) بتراجع كود مشروعك وبتنبّهك لثغرات IDOR والصلاحيات قبل النشر.

شو أول workflow رح تقفلها بمشروعك؟

أسئلة شائعة

هل ملف actions.lock متاح على خطة GitHub المجانية؟

إي. حسب إعلان GitHub يوم 14 تشرين الأول 2026، المعاينة العامة متاحة لخطط Free وTeam وEnterprise Cloud، مع إنو صفحات التوثيق لسا كاتبة Enterprise Cloud بس. وسياسة Require lockfile بتشتغل على كل الريبوهات العامة، أما الخاصة فبدها Team أو Enterprise.

إذا كنت مثبّت كل action على SHA كامل، لسا بحتاج ملف قفل؟

إي، إذا بدك تغطي التبعيات غير المباشرة. SHA بملف workflow بيثبّت السطر يلي كتبته إنت، وملف القفل بيثبّت كمان يلي بتناديه الـ action من جوّا وبيسجّل هوية الريبو. وتوثيق GitHub بيقول إنو الريبو يلي عنده ملف قفل ما عاد بيحتاج SHA pinning.

ليش فحص gh actions-lock --verify عم يفشل على workflows ما لمستها؟

لأن من الإصدار v0.2.0 الفحص بيفشل على أي workflow ما إلها سطر بالقفل، وعلى أي سطر بالقفل ما في workflow عم تستعمله. شغّل gh actions-lock مرة بلا مسار، واعمل commit للنتيجة.

بقدر عدّل ملف actions.lock بإيدي؟

لأ. GitHub بتقول إنو الملف بيتولّد بأمر gh actions-lock وما بيتعدّل يدوياً. إذا شكله غلط، صلّح ملفات workflow وولّده من جديد.

هل ملف القفل بيثبّت صور Docker يلي بتسحبها workflow؟

لأ. القفل بيثبّت commits تبع actions بس. أي صورة مش مثبّتة على sha256 digest بتطلع تنبيه container-image ما بيوقّف التشغيل، فثبّت الصور على digest بنفسك.

هل package firewall بيدعم pip أو Maven؟

لأ. لحد 20 تشرين الأول 2026 بيدعم حزم npm بس، وهو معاينة عامة لعملاء GitHub Enterprise Cloud، ومجاني لحد ما يوصل للإصدار العام.

كيف تحمي GitHub Actions تبعك إذا حدا غيّر tag لـ action بتستعملها؟

ليش الـ <span dir="ltr">tag</span> ممكن يشغّل كود ما راجعته؟

شو هو ملف <span dir="ltr">actions.lock</span> وشو بيسجّل؟

كيف تعمل أول ملف قفل لمشروعك؟

كيف تتأكد إنو ملف القفل مش قديم قبل الدمج؟

شو بتعمل إذا الفحص قال إنو <span dir="ltr">tag</span> تحرّك؟

إمتى تفرض القفل على كل الـ <span dir="ltr">workflows</span>؟

شو بيعمل <span dir="ltr">Dependabot</span> مع ملف القفل؟

شو هو <span dir="ltr">package firewall</span> وهل بيلزم فريقك؟

من وين تبلّش هلق؟

أسئلة شائعة

نزّلت LiteLLM 1.107.0 أو سحبت صورة latest؟ شو لازم تعمل هلق

PHP2Shell: ثغرتين بقلب PHP، وليش تحديث WordPress لحاله ما بيحميك

تحديثات أمان Node.js لأكتوبر 2026: شو بتسكّر، وأي نسخة بعد 28 أكتوبر

ليش الـ <span dir="ltr">tag</span> ممكن يشغّل كود ما راجعته؟

شو هو ملف <span dir="ltr">actions.lock</span> وشو بيسجّل؟

كيف تعمل أول ملف قفل لمشروعك؟

كيف تتأكد إنو ملف القفل مش قديم قبل الدمج؟

شو بتعمل إذا الفحص قال إنو <span dir="ltr">tag</span> تحرّك؟

إمتى تفرض القفل على كل الـ <span dir="ltr">workflows</span>؟

شو بيعمل <span dir="ltr">Dependabot</span> مع ملف القفل؟

شو هو <span dir="ltr">package firewall</span> وهل بيلزم فريقك؟

من وين تبلّش هلق؟

أسئلة شائعة

مقالات أخرى

نزّلت LiteLLM 1.107.0 أو سحبت صورة latest؟ شو لازم تعمل هلق

PHP2Shell: ثغرتين بقلب PHP، وليش تحديث WordPress لحاله ما بيحميك

تحديثات أمان Node.js لأكتوبر 2026: شو بتسكّر، وأي نسخة بعد 28 أكتوبر