قد يحتوي مسار البناء على صلاحية كتابة للحزم أو التعليقات، مع أن وظيفته قراءة الشيفرة وتشغيل الاختبارات فقط. الخطر ليس في YAML وحده؛ فمصدر الحدث وتوقيت إتاحة الرمز وطريقة تشغيل الشيفرة تؤثر في ما يستطيع المسار فعله. يمكن لمشاريع تخرج أمن المعلومات تطوير مدقق يقرأ إعدادات workflows محلياً ويشرح الأذونات والمحفزات قبل أي تشغيل. يقتصر النموذج على الفحص الساكن ولا يحاول استغلال صلاحيات أو الوصول إلى مستودعات حقيقية.
اربط العمل بالإذن
ابدأ بتجميع مستويات الإذن في كل workflow وjob، ثم اربط كل واحدة بمهمة محددة مثل قراءة المستودع أو نشر artifact. يشرح توثيق GitHub للرمز GITHUB_TOKEN أن صلاحياته يمكن ضبطها داخل مسار العمل، وأن إعداداته تعتمد على المستودع والمؤسسة. لا تفترض أن غياب permissions في ملف يساوي دائماً المنع؛ سجل الافتراض والإعداد الافتراضي الذي راجعته في بيئة الاختبار.
وثيقة GitHub للأمان عند استخدام Actions تتناول تشغيل شيفرة غير موثوقة ومخاطر actions الخارجية وممارسات تقليل الصلاحية. صمم المدقق لتمييز trigger مثل pull_request عن workflow_dispatch أو push، ويعرض متى يتغير مصدر الشيفرة. لا يقدم تقريراً مطلقاً عن أمان المشروع؛ يوضح فقط ما استطاع المحلل قراءته من ملفات وإعدادات متاحة.
ابنِ محلل YAML محدوداً
استخدم parser معروفاً للتحقق من بنية الملف، ثم حول workflow إلى نموذج بيانات: events، jobs، permissions، actions references، secrets contexts، وcheckout/ref. إذا واجهت تعبيراً ديناميكياً أو action مركبة لا يفهمها المحلل، صنفها «غير محللة». لا تحاول تنفيذ تعبيرات GitHub داخل التطبيق. سجل مسار الملف ورقم السطر كي يستطيع المراجع فتحه مباشرة، واحفظ نسخة YAML الأصلية بجانب التقرير لإعادة الفحص.
يمكن أن يكون لكل finding مستوى «بحاجة إلى مراجعة» بدلاً من درجة خطورة تبدو علمية بلا منهج. مثال: وجود contents: write في مهمة اختبار يطرح سؤالاً؛ أما مهمة النشر فقد تحتاجه بوضوح. اسمح للفريق بإرفاق مبرر ومالك لكل استثناء، وتاريخ مراجعة. لا تحذف الإذن تلقائياً ولا تقترح تغييراً دون معاينة فرق الملف؛ فقد يوقف التغيير عملية نشر لازمة.
افحص السياق قبل الحكم
اعرض العلاقة بين مصدر الحدث والـjob: أي فرع أو fork يمكن أن يطلق المسار؟ أي خطوة تستخدم token؟ هل يثبت الاعتماديات بإصدار ثابت أم يشير إلى مرجع متحرك؟ لا تخلط تحليل التكوين مع إثبات ما حدث في تشغيل سابق. حفظ snapshot من الملفات والإصدار يساعد على مقارنة نتائج المراجعة بعد تعديل workflow. امنع المدقق من قراءة ملفات الأسرار أو طباعة قيمها؛ هو يحتاج أسماء السياقات فقط ولا يحتاج المحتوى.
مثال تعليمي: workflow يفحص طلبات السحب ويمنح كل jobs إذن contents: write. يظهر التقرير أن مهمة الاختبار لا تبدو بحاجة إلى هذا الإذن، ويقترح أن يراجع الفريق تقليل scope إلى read. إذا كان job آخر ينشر artifact، يجب تحليل حاجته منفصلاً. هذه ملاحظة على ملف تجريبي؛ لا تعني أن إعداداً بعينه في موقع المستخدم ضعيف أو أن تغييراً واحداً يكفي لحمايته.
سجل الاستثناءات والمجهول
قد يستخدم المسار action مركبة تمنحها المؤسسة صلاحية إضافية، أو policy مركزية لا تظهر في YAML. لذلك يعرض المدقق حدود رؤيته: الملف المقروء، branch أو commit، والإعدادات التي لم تتوفر. لا يحول كل uses إلى دليل على مورد خارجي ضار. بدلاً من ذلك، يسمح بتسجيل المصدر والمرجع المثبت وسياسة المراجعة، ثم يميز بين digest ثابت وtag قابل للتغير إن كان يفهم التنسيق.
حافظ على سجل الاستثناءات محدوداً: اسم الإذن، job، سبب الحاجة، مالك الفريق، وموعد مراجعة. لا تضع أسراراً ولا معلومات وصول. يمكن ربط الاستثناء بملف تصميم القرار إن وجد، لكن يجب ألا يعاد استعماله تلقائياً بعد تغير job أو trigger. اعرض اختلافاً حين يتغير السياق حتى يعيد الفريق المراجعة، ولا تعرض عبارة «موافق» لمجرد وجود ملاحظة قديمة.
اختبارات المحلل
أنشئ fixtures ذات workflow بلا permissions، وآخر يمنح قراءة فقط، وثالث فيه نشر بحاجة لمراجعة، وملف به صيغة غير مدعومة. قارن findings المتوقعة مع التقرير، واختبر أن line numbers ثابتة بعد YAML comments وتداخل jobs. خط الأساس هو فحص يدوي من مطورين؛ يقاس التحسن بقدرة المدقق على كشف التغيير وذكر موضعه، لا بعدد التحذيرات. أضف حالات trigger من fork وworkflow_call إن كان المحلل يدعمها.
اختبر file malformed، عقدة YAML مكررة، أو قيمة expression ديناميكية. ينبغي أن يصرح المدقق بأنه لا يعرف بدلاً من إسقاط job. تحقق أن تشغيله لا ينفذ أي step ولا يخرج محتويات secrets. استخدم ملفات محلية اصطناعية، ولا تجرب استغلال token أو محاكاة فعلية على حسابات. التقرير النهائي يضم coverage لما فُهم من grammar، وقرارات مراجع بشري لبعض النتائج، وأمثلة على حالات خارج النطاق.
مخرجات مشروع التخرج
النسخة الأولى قارئ YAML، نموذج إذن إلى job، واجهة تقرير، ومجموعة fixtures تشرح النتائج. يمكن إعدادها ضمن مشاريع التخرج مع خدمة المشاريع البرمجية. أرفق قواعد التحليل وإصدارات المصادر الرسمية التي راجعتها، وقدم مثالاً لملاحظة صحيحة وأخرى لم تحسمها الأداة. لا تستخدم نتائج المدقق بديلاً عن مراجعة فريق الأمن أو إعدادات المؤسسة التي لا يقرأها الملف.
هذا المشروع تعليمي لتحليل تكوين محدد. لا يثبت أن workflow آمن، ولا يحصي كل أسرار المؤسسة، ولا يعرف صلاحيات token الفعلية في كل سياسة. هذه الحدود جزء من تصميمه: إذا لم تتوفر بيانات، تظهر للمراجع. النجاح هو تقرير يمكن تتبع كل سطر فيه إلى إعداداته ومبرر التوصية، لا إنشاء درجة واحدة تخلط بين معلومات مؤكدة وافتراضات.
المصادر
- GitHub Docs: Use GITHUB_TOKEN for authentication in workflows
- GitHub Docs: Secure use reference for GitHub Actions
مراجعة المصادر: .
اختبار المثال وحدوده
يفحص أمثلة YAML محلية مصطنعة ولا يشغل workflows أو يتصل بمستودع خارجي.
مقالات ذات صلة
الخدمة المرتبطة: تطوير المشاريع البرمجية الجامعية.
أرسل متطلبات مشروعك