تكوين فحص التعليمة البرمجية

مكتمل

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

كما ناقشنا في الوحدات السابقة، يمكنك تشغيل فحص التعليمة البرمجية على GitHub، باستخدام إجراءات GitHub، أو من نظام التكامل المستمر (CI). يؤدي تحديد خيار الإعداد المتقدم على GitHub إلى إنشاء ملف سير عمل قابل للتخصيص يمكنك بعد ذلك الالتزام به مباشرة في المستودع الخاص بك. عادة لا تحتاج إلى تحرير سير العمل هذا. ومع ذلك، إذا لزم الأمر، يمكنك تخصيص بعض الإعدادات.

على سبيل المثال، يمكنك تحرير سير عمل تحليل CodeQL في GitHub لتحديد تواتر عمليات الفحص واللغات أو الأدلة المراد مسحها وما يبحث عنه فحص لكود CodeQL في التعليمة البرمجية الخاصة بك. قد تحتاج أيضاً إلى تحرير سير عمل تحليل CodeQL إذا كنت تستخدم مجموعة معينة من الأوامر لتجميع التعليمة البرمجية الخاصة بك. يعد تحليل CodeQL نوعاً واحداً فقط من فحص التعليمة البرمجية الذي يمكنك إجراؤه في GitHub. يحتوي GitHub Marketplace على العديد من مهام سير عمل فحص للتعليمات البرمجية الأخرى.

التبديل من الإعداد الافتراضي إلى الإعداد المتقدم لفحص التعليمات البرمجية

إذا كان لديك بالفعل مستودع تم إعداده لاستخدام مسح التعليمات البرمجية باستخدام أسلوب الإعداد الافتراضي، يمكنك التبديل إلى استخدام الإعداد المتقدم في الإعدادات. انتقل إلى قسم Code scanning ضمن Settings > Code security and analysis، ثم حدد رمز تجاوز النقاط الثلاث (...). في القائمة المنسدلة، حدد التبديل إلى خيارات متقدمة. بعد ذلك، اتبع المطالبات لتعطيل CodeQL، وأعد تمكينه باستخدام ملف سير العمل الذي تم إنشاؤه للإعداد المتقدم.

تحرير سير عمل مسح التعليمات البرمجية

يحفظ GitHub ملفات سير العمل في دليل .github/workflows لمستودعك. يمكنك العثور على سير عمل قمت بإضافته من خلال البحث عن اسم الملف الخاص به. على سبيل المثال، بشكل افتراضي، يسمى ملف سير العمل لفحص التعليمات البرمجية CodeQL codeql-analysis.yml.

اتبع هذه الخطوات لتحرير ملف سير عمل:

1. لفتح محرر سير العمل، حدد أيقونة تحرير في الزاوية العلوية اليسرى من طريقة عرض الملف.

   

2. قم بإجراء التعديلات الخاصة بك.

3. بعد تحرير الملف، حدد Commit changes وأكمل نموذج Commit changes. يمكنك اختيار الالتزام مباشرة بالفرع الحالي، أو إنشاء فرع جديد وبدء طلب سحب.

   

راجع الأقسام التالية للتعرف على بعض خيارات التكوين الشائعة لمسح التعليمة البرمجية.

تكوين التردد

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

الفحص عند دفع البيانات

بشكل افتراضي، يستخدم سير عمل تحليل CodeQL الحدث on:push لبدء فحص التعليمة البرمجية في كل دفع للبيانات إلى الفرع الافتراضي للمستودع وأي فروع محمية. لكي يتم تشغيل فحص التعليمة البرمجية في فرع معين، يجب أن يكون سير العمل موجوداً في هذا الفرع. إذا قمت بالمسح الضوئي عند الدفع، فستظهر النتائج في علامة التبويب Security لمستودعك.

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

الفحص في حالة PR

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

إذا كنت تستخدم pull_request المشغل، الذي تم تكوينه لمسح تثبيت دمج طلب السحب ضوئيا بدلا من تثبيت الرأس، فإنه ينتج نتائج أكثر كفاءة ودقة من فحص رأس الفرع على كل دفعة. ومع ذلك، إذا كنت تستخدم نظام CI/CD لا يمكن تكوينه لتشغيل طلبات السحب، فلا يزال بإمكانك استخدام on:push المشغل بحيث يقوم فحص التعليمات البرمجية بتعيين النتائج لفتح طلبات السحب على الفرع وإضافة التنبيهات كتعليقات توضيحية على طلب سحب.

تحديد مدى الخطورة التي تسببت في فشل فحص طلب السحب

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

1. في GitHub.com، انتقل إلى الصفحة الرئيسية للمستودع. ضمن اسم المستودع الخاص بك، حدد الإعدادات.

   

2. في الشريط الجانبي الأيسر، حدد Code security and analysis.

   

3. في قسم فحص التعليمات البرمجية ضمن قواعد الحماية، استخدم القائمة المنسدلة لتحديد مستوى الخطورة الذي ترغب في تشغيل فشل التحقق من طلب السحب.

   

تجنب عمليات فحص غير الضرورية لطلبات السحب

قد ترغب في تجنب بدء فحص التعليمة البرمجية في طلبات سحب محددة تستهدف الفرع الافتراضي، بغض النظر عن الملفات التي تم تغييرها. يمكنك تكوين هذا الإعداد عن طريق تحديد on:pull_request:paths-ignore أو on:pull_request:paths في سير عمل مسح التعليمات البرمجية. على سبيل المثال، إذا كانت التغييرات الوحيدة في طلب السحب تتعلق بملفات بامتدادات الملفات .md أو .txt يمكنك استخدام مصفوفة paths-ignore التالية.

on:
   push:
      branches: [main, protected]
   pull_request:
      branches: [main]
      paths-ignore:
         - '**/*.md'
         - '**/*.txt'

ضبط جدول المسح

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

يوضح المثال التالي سير عمل تحليل CodeQL لمستودع مع فرع افتراضي يسمى main وفرع محمي واحد يسمى protected:

on:
   push:
      branches: [main, protected]
   pull_request:
      branches: [main]
   schedule:
      - cron: '20 14 * * 1'

يقوم سير العمل هذا بفحص:

• كل دفع بيانات إلى الفرع الافتراضي والفرع المحمي
• كل طلب سحب إلى الفرع الافتراضي
• الفرع الافتراضي كل يوم إثنين الساعة 14:20 بالتوقيت العالمي المنسق