الملف نظيف. ماذا تقول الجهة التي أصدرت المفتاح؟
حذفت السر. هل ألغيت صلاحية الوصول؟ يجعل GhostAction هذا السؤال عاجلاً: يمكن لحساب مشرف مخترق أن يضيف سير عمل يبحث في الالتزامات القديمة والملفات الحالية معاً. خلو شجرة العمل من السر لا يخبرك إن كان المفتاح الذي عثر عليه المهاجم ما زال يعمل. الخدمة التي أصدرته هي من تقرر ذلك.
حملة أكتوبر 2026 هي نقطة البداية، لكن النتيجة المفيدة هي طريقة لإغلاق الحادث بأدلة. أفصل بين ثلاثة أسئلة: أين بقي السر، وهل ما زالت الجهة المصدرة تقبله، وهل يستطيع المهاجم زرع سير عمل آخر؟ يعتمد هذا التحليل على أبحاث منشورة ووثائق GitHub؛ لم تُشغَّل حمولة الحملة هنا. [1][2]
يتحول سجل Git إلى مدخلات لعامل التنفيذ المخترق
تصف StepSecurity ملف security-audit.yml خبيثاً أُضيف مباشرة باسم مشرف اختُرق حسابه. تطلب خطوة checkout السجل الكامل، ثم يفحص السكربت التغييرات باستخدام git log -p --all. ويحاول أيضاً جمع قيم أسرار Actions المُعدّة، بإدراج أسماء اكتشفها في مسارات العمل القائمة. تحدد الأسماء ما سيطلبه؛ أما القيم فهي ما يريده المهاجم. [1]
انظر إلى السجل التوضيحي أدناه. يزيل الالتزام B الرمز من أحدث نسخة للملف، بينما يحتفظ الالتزام A به. لذلك يمكن لبحث يشمل السجل استعادة النص القديم. يظل الجمع مقيداً بالمراجع التي جُلبت وأنماط المطابقة وحدود المخرجات في الحمولة. لا تحوّل هذه القدرة إلى ادعاء بأن كل سر تاريخي استُخرج فعلاً.
Illustrative repository history; no real credential
A: config.env contains API_TOKEN=DEMO_NOT_A_REAL_TOKEN
B: config.env no longer contains API_TOKEN
Current file: absent
Earlier commit: present
Issuer status: a separate questionهل يستطيع السر المستعاد اجتياز المصادقة؟
إمكان العثور على السر وصلاحيته خاصيتان مستقلتان. قد يبقى رمز قديم ظاهراً بعد إلغائه من دون أن يمنح وصولاً. وقد يختفي من المستودع الذي تتحكم فيه، بينما يظل قابلاً للاستخدام من نسخة لدى شخص آخر. توصي GitHub بإلغاء بيانات الاعتماد المكشوفة أو تدويرها أولاً؛ أما إعادة كتابة السجل فتعالج النسخ الباقية وتتطلب التنسيق بشأن النسخ المحلية والتفرعات والمراجع. [2]
يغيّر هذا الفصل طريقة قراءتي لإحصاءات التنظيف. عدد المستودعات التي تحتوي نصاً قديماً لسر يقيس البقايا العامة، لا عدد المفاتيح التي ما زالت الجهة المصدرة تقبلها. ويتغير معيار القبول أيضاً: استبدال متغير في CI لا يكفي ما لم يُعطَّل المفتاح السابق لدى مصدره. سجّل ذلك منفصلاً عن نجاح البناء بالمفتاح الجديد.
Old credential accepted?
Yes No
Secret text recoverable Access remains Residual disclosure
Secret text no longer found Access may remain Both checks needed
A repository scan cannot answer the issuer-status column.أي ضابط سيوقف سير العمل التالي فعلاً؟
تفيد متطلبات المراجعة حين تكون ملزمة. إعداد GitHub للموافقة على مسارات العمل القادمة من التفرعات العامة يخص مسار المساهمة هذا؛ وليس بوابة موافقة عامة لدفع مباشر من مشرف. وثّقت StepSecurity بوابة موافقة أوقفت تشغيلات محددة، لكن هذه الملاحظة لا تثبت أن إعداد التفرعات يحمي كل مستودع من الحملة. [1][3]
في الفرع المحمي، اشترط طلب دمج ومراجعة مالك الشيفرة المناسب، ثم افحص من يستطيع تجاوز القاعدة. يحدد إدخال .github/workflows/ في CODEOWNERS الملكية؛ وتجعل قاعدة الفرع المراجعة إلزامية. احمِ CODEOWNERS نفسه، وافحص الفروع الأخرى التي تصل الأسرار إلى مسارات عملها عند push. حماية main وحده لا تغطي وصف كل مسار تنفيذ. [4][5]
قد تُسرق الأسرار مع رمز مستودع مخصص للقراءة فقط
تقليل صلاحيات GITHUB_TOKEN مفيد، لكنه لا يلغي مفتاحاً سحابياً يُمرَّر إلى المهمة بشكل مستقل. كان بإمكان سير العمل المرصود جمع بيانات اعتماد أخرى بينما تقتصر صلاحية محتوى المستودع على القراءة. لذلك يجب أن يشمل فحص الصلاحيات الرمز المدمج وكل سر منفصل يتاح أثناء التنفيذ. [1]
أتتبع سلسلة محددة: من يغير سير العمل، وما الحدث الذي يشغله، وأي هوية وأسرار تحصل عليها المهمة، وإلى أين تستطيع الاتصال؟ في مهمة النشر، السؤال هو إن كان من يكتب سير العمل يستطيع تحويلها إلى قارئ لبيانات الاعتماد. تقييد الكتابة إلى المستودع يعالج جزءاً واحداً فقط. هذا سؤال معماري، وليس ادعاء بأن كل عامل تنفيذ كشف كل الأسرار.
احتوِ الوصول قبل تجميل سجل المستودع
احفظ نسخة سير العمل ومعرّفات التشغيل وسجلات التدقيق ذات الصلة قبل أن يزيل التنظيف السياق. أوقف مسار التنفيذ الخبيث وألغِ بيانات اعتماد المشرف المخترقة. ثم احصر أسرار المهام الحالية والمفاتيح التاريخية الواقعة ضمن نطاق التعرض، وعيّن مالكاً لكل منها، وأثبت الإلغاء لدى الجهة المصدرة. إن تعذر تحديد الصلاحية، سجّلها مسألة غير محسومة بدلاً من إعلان نظافة المستودع. [1][2]
يجب أن يمر المفتاح البديل عبر مسار تنفيذ موثوق. وإلا قرأه سير العمل المخترق نفسه عند التشغيل التالي. يتطلب تنظيف السجل تنسيقاً مستقلاً، ولا يستعيد النسخ التي حصل عليها المهاجم. وللمفاتيح التي تستطيع إنشاء جلسات أو بيانات اعتماد أخرى، راجع ذلك الوصول اللاحق أيضاً؛ فتعطيل السر الأصلي لا يثبت منطقياً عدم إنشاء وصول منفصل.
اطلب سجل إغلاق، لا لقطة شاشة نظيفة
ينبغي أن يستطيع مهندس آخر التمييز بين العمل المكتمل والافتراضات في سجل المعالجة. لكل مفتاح مكشوف، احتفظ بمعرّفه غير السري ومالكه والجهة المصدرة وفترة التعرض ودليل الإلغاء وحالة نشر البديل. وثّق كيف احتُويت الهوية المستخدمة للزرع وكيف قُيّد مسار العمل. النموذج أدناه أداة مراجعة مقترحة، وليس سجلاً لتنفيذ هذا الحادث.
يصبح سؤال العميل دقيقاً: هل تستطيع فرقك إثبات أن الوصول المكشوف سابقاً لم يعد مقبولاً، وأن البديل لن يتسرب عبر الطريق نفسه؟ هذه هي الأدلة التي أطلبها في التحقق من المعالجة. إنها الفارق بين إغلاق تذكرة وإغلاق الوصول الذي أُنشئت التذكرة لإزالته.
Credential ID / owner / issuer: ____________________
Exposure scope and evidence: _______________________
Old credential disabled at issuer: _________________
Replacement deployed through trusted workflow: _____
Compromised maintainer access contained: ____________
Other credentials or sessions investigated: _________
Remaining copies / uncertainty / responsible owner: _المصادر
هل تحتاج إلى هذا الفحص في منتجك؟
المعالجة والتحقق من الإصلاحاتهل تريد أن تتعلم اكتشاف ثغرات كهذه بنفسك؟
دورة مراجعة الكود الأمني بتدريب فردي