استخدام أداة فحص الضعف Snyk

مقدمة

تم تصميم Snyk ليكون منصة أمنية للمطورين مع مرونة في الاعتبار. هدفها الرئيسي هو مساعدتك في اكتشاف وإصلاح الثغرات في شفرة مصدر تطبيقك والاعتمادات الخارجية لأطراف ثالثة وصور الحاويات وملفات تكوين البنية التحتية (مثل Kubernetes و Terraform وما إلى ذلك).

ينقسم Snyk إلى أربعة مكونات:

1. Snyk Code – يساعدك في العثور على الثغرات وإصلاحها في شفرة مصدر تطبيقك.
2. Snyk Open Source – يساعدك في العثور على الثغرات وإصلاحها في أي مكتبات أو اعتمادات من الطرف الثالث يعتمد عليها تطبيقك.
3. Snyk Container – يساعدك في العثور على الثغرات وإصلاحها في صور الحاويات أو الأعباء العاملة في Kubernetes المستخدمة في مجموعتك.
4. Snyk Infrastructure as Code – يساعدك في العثور على الثغرات وإصلاحها في تكوينات Kubernetes الخاصة بك (ويتم دعم Terraform و CloudFormation و Azure أيضًا).

يمكن تشغيل Snyk بطرق مختلفة:

• عبر واجهة سطر الأوامر باستخدام Snyk CLI. هذه الطريقة المفضلة للتشغيل داخل النصوص النصية والتشغيلات الآلية المختلفة، بما في ذلك أنابيب CI/CD.
• في المتصفح بواسطة واجهة المستخدم على الويب لـ Snyk. يقدم Snyk منصة مستندة إلى السحابة يمكنك استخدامها لاستكشاف تقارير المسح، وتلقي تلميحات، واتخاذ الإجراءات اللازمة لإصلاح المشاكل المُبلَّغ عنها، إلخ. يمكنك أيضًا ربط مستودعات GitHub وإجراء مسح/تدقيق من واجهة الويب.
• عبر ملحقات IDE. بهذه الطريقة يمكنك اكتشاف المشكلات في وقت مبكر أثناء تطويرك باستخدام بيئة التطوير المفضلة لديك (على سبيل المثال، Visual Studio Code).
• برمجيًا، عبر واجهة برمجة التطبيقات لـ Snyk. تتوفر واجهة برمجة التطبيقات لـ Snyk للعملاء على الخطط المدفوعة وتسمح لك بالتكامل برمجيًا مع Snyk.

هل Snyk مجاني؟

نعم، الأدوات مجانية، باستثناء واجهة برمجة التطبيقات لـ Snyk وبعض الميزات المتقدمة من واجهة المستخدم على الويب (مثل التقارير المتقدمة). كما يوجد قيد على عدد الاختبارات التي يمكنك إجراؤها شهريًا.

انظر خطط التسعير لمزيد من المعلومات.

هل Snyk مفتوح المصدر؟

نعم، الأدوات و Snyk CLI بالتأكيد مفتوحة المصدر. يمكنك زيارة صفحة GitHub الرئيسية لـ Snyk للعثور على مزيد من التفاصيل حول تنفيذ كل مكون. بوابة السحابة وجميع الميزات المدفوعة مثل تنفيذ واجهة برمجة التطبيقات الباقية ليست مفتوحة المصدر.

مجموعة أخرى مهمة من المفاهيم التي تستخدمها Snyk هي الأهداف و المشاريع.

تمثل الأهداف موردًا خارجيًا تم فحصه من خلال تكامل Snyk ، سطر الأوامر (CLI) ، واجهة المستخدم أو واجهة برمجة التطبيقات (API). أمثلة على الأهداف هي مستودع SCM ، وعبء عمل Kubernetes ، إلخ.

من ناحية أخرى، تعرف المشاريع العناصر التي يقوم Snyk بفحصها في الهدف المعطى. يتضمن المشروع:

• A scannable item external to Snyk.
• التكوين لتحديد كيفية تشغيل هذا الفحص.

يمكنك قراءة المزيد عن مفاهيم Snyk الأساسية هنا.

في هذا الدليل، ستستخدم Snyk CLI لأداء تحليل المخاطر لسلسلة توريد تطبيقات Kubernetes الخاصة بك (صور الحاويات، ملفات YAML لـ Kubernetes). بعد ذلك، ستتعلم كيفية اتخاذ الإجراء المناسب لتصحيح الوضع. وأخيرًا، ستتعلم كيفية دمج Snyk في خط أنابيب CI/CD لفحص الضعف في المراحل الأولى من التطوير.

جدول المحتويات

• مقدمة
• المتطلبات
• الخطوة 1 – التعرف على Snyk CLI
• الخطوة 2 – التعرف على واجهة مستخدم Snyk على الويب
  • فهم مستويات خطورة Snyk
  • المساعدة في إصلاح مشكلات الأمان المبلغ عنها
• الخطوة 3 – استخدام Snyk لفحص ثغرات تكوين Kubernetes في أنبوب CI/CD
  • تنفيذ سير العمل CI/CD لـ GitHub Actions
• الخطوة 4 – التحقيق في نتائج فحص Snyk وإصلاح المشكلات المبلغ عنها
• التحقيق في وإصلاح ثغرات صور الحاويات
• التحقيق في وإصلاح ثغرات توجيهات Kubernetes
• مراقبة مشاريعك بشكل منتظم
• معالجة الاستثناءات
• Snyk لبيئات التطوير المتكاملة
• الخطوة 5 – تشغيل سير العمل Snyk CI/CD تلقائيًا
• الخطوة 6 – تمكين إشعارات Slack
• الاستنتاج
• موارد إضافية

المتطلبات الأساسية

لإكمال جميع الخطوات من هذا الدليل، ستحتاج إلى:

1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
3. Kubectl واجهة سطر الأوامر للتفاعل مع Kubernetes. اتبع هذه التعليمات للاتصال بمجموعتك باستخدام kubectl و doctl.
4. Snyk CLI للتفاعل مع ماسح ثغرات Snyk.
5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

الخطوة 1 – التعرف على واجهة سطر الأوامر لـ Snyk

يمكنك فحص الثغرات يدويًا عبر واجهة سطر الأوامر باستخدام أمر snyk. تم تصميم واجهة سطر الأوامر لـ Snyk لاستخدامها في مختلف النصوص والأتمتة. مثال عملي هو في خط أنابيب CI/CD يتم تنفيذه باستخدام أدوات مختلفة مثل Tekton و Jenkins و GitHub Workflows وما إلى ذلك.

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

يمكنك اختيار دفع النتائج إلى بوابة Snyk السحابية (أو واجهة المستخدم عبر الويب) عبر العلمة --report لتخزين نتائج المسح وتصورها لاحقًا.

يتم تقسيم واجهة سطر الأوامر لـ Snyk إلى عدة أوامر فرعية. يخصص كل أمر فرعي لميزة محددة، مثل:

• مسح المصدر المفتوح – يحدد تبعيات المشروع الحالية ويُبلغ عن المشاكل الأمنية المكتشفة.
• مسح الشيفرة – يُبلغ عن المشاكل الأمنية الموجودة في شيفرة مصدر التطبيق الخاص بك.
• مسح الصورة – يُبلغ عن المشاكل الأمنية الموجودة في صور الحاويات (مثل Docker).
• مسح ملفات البنية كشيفرة – يُبلغ عن المشاكل الأمنية الموجودة في ملفات التكوين المستخدمة بواسطة Kubernetes، Terraform، إلخ.

قبل المتابعة، يرجى التأكد من إنشاء حساب مجاني باستخدام واجهة مستخدم Snyk على الويب. كما يجب مصادقة واجهة سطر الأوامر الخاصة بـ snyk مع حسابك السحابي أيضًا لكي تعمل بعض الأوامر/الأوامر الفرعية (مثل snyk code test).

A few examples to try with Snyk CLI:

1. مسح المصدر المفتوح:

# يقوم بمسح شيفرة مشروعك من الدليل الحالي
snyk test
# يقوم بمسح مسار محدد من دليل مشروعك (تأكد من استبدال الرموز التعبيرية `<>` بشكل مناسب)
snyk test <path/to/dir>

2. مسح الشيفرة:

# مسح رمز مشروعك من الدليل الحالي
snyk code test

# مسح مسار محدد من دليل مشروعك (تأكد من استبدال العلامات التكميلية `<>` وفقًا لذلك)
snyk code test <path/to/dir>

3. مسح الصورة:

# يقوم بفحص صورة دوكر debian عن طريق سحبها أولاً
snyk container debian

# قدم المزيد من السياق للماسح عن طريق تقديم ملف Dockerfile (تأكد من استبدال العلامات التكميلية `<>` وفقًا لذلك)
snyk container debian --file=<path/to/dockerfile>

4. مسح البنية كرمز:

# مسح رمز مشروعك من الدليل الحالي
snyk iac test

# مسح مسار محدد من دليل مشروعك (تأكد من استبدال العلامات التكميلية `<>` وفقًا لذلك)
snyk iac test <path/to/dir>

# مسح مشاريع Kustomize القائمة (أولاً تحتاج إلى تقديم القالب النهائي، ثم تمريره إلى الماسح)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

يوفر Snyk CLI صفحات مساعدة لجميع الخيارات المتاحة. يمكن استخدام الأمر أدناه لطباعة الصفحة الرئيسية للمساعدة:

snyk --help

الناتج يبدو مشابهًا لذلك:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

لكل أمر (أو فرعي) في snyk CLI صفحة مساعدة مرتبطة أيضًا، والتي يمكن الوصول إليها عبر snyk [الأمر] --مساعدة.

يرجى زيارة الصفحة الرسمية لـ توثيق snyk CLI لمزيد من الأمثلة.

الخطوة 2 – التعرف على واجهة المستخدم عبر الويب لـ Snyk

بعد التسجيل في حساب Snyk، والمصادقة وتسجيل الدخول إلى Snyk، يتم فتح واجهة المستخدم عبر الويب إلى لوحة المعلومات، مع معالج لإرشادك خلال خطوات الإعداد:

• تحديد موقع الشفرة التي ترغب في مراقبتها في Snyk.
• تحديد المشاريع داخل الشفرة التي تريد من Snyk مسحها.
• ربط Snyk بالمشاريع ذات الصلة لمسحها.
• مراجعة نتائج مسح Snyk الخاص بك.

الميزات التالية متوفرة عبر واجهة المستخدم عبر الويب:

• استكشاف لوحة المعلومات
• تحقيق التقارير
• إدارة المشاريع
• إدارة التكاملات
• إدارة أعضاء المجموعة أو المنظمة
• عرض تحديثات Snyk
• احصل على مساعدة
• إدارة حساب المستخدم الخاص بك

يرجى زيارة صفحة التوثيق الرسمية لمعرفة المزيد حول واجهة المستخدم على الويب لـ Snyk.

فهم مستويات الخطورة في Snyk

في كل فحص، يتحقق snyk من مواردك لاكتشاف المخاطر الأمنية المحتملة وكيفية تأثير كل منها على نظامك. يتم تطبيق مستوى الخطورة على الثغرة للإشارة إلى المخاطرة الناتجة عن تلك الثغرة في التطبيق.

يمكن أن تتخذ مستويات الخطورة واحدة من القيم التالية:

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

يحدد نظام التصنيف الشائع للثغرات (CVSS) مستوى الخطورة للثغرة. يستخدم Snyk إطار عمل إصدار 3.1 من نظام تصنيف الثغرات الشائع (CVSS) للتواصل بشأن خصائص وخطورة الثغرات.

الجدول أدناه يوضح تعيين مستوى الخطورة لكل مستوى:

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

يرجى زيارة صفحة الوثائق الرسمية لمعرفة المزيد حول مستويات الخطورة.

التصحيح المساعد لمشاكل الأمان المبلغ عنها

ميزة أخرى مفيدة توفرها واجهة المستخدم عبر الويب المقدمة من Snyk هي مساعدة في تصحيح مشاكل الأمان. يعني ذلك أنك تتلقى توصية بشأن كيفية إصلاح كل مشكلة أمان تم العثور عليها بواسطة ماسح snyk. هذا أمر مهم للغاية لأنه يبسط العملية ويغلق الحلقة لكل تكرار تحتاج إلى إجرائه لإصلاح كل مشكلة أمان تم الإبلاغ عنها.

الصورة أدناه توضح هذه العملية بشكل أفضل:

لكل مشكلة مُبلَغ عنها، هناك زر يمكنك النقر عليه للحصول على مساعدة في الإصلاح:

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

الخطوة 3 – استخدام Snyk لفحص التهديدات الأمنية في تكوين Kubernetes في أنبوب CI/CD

كيف يمكنك الاستفادة من تضمين أداة فحص الامتثال الأمني في أنبوب CI/CD الخاص بك وتجنب المواقف الغير مريحة في بيئة الإنتاج؟

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

لذا، يعمل أداة فحص الأمان (مثل snyk) كبوابة توقف الفناء غير المرغوب فيه من دخول بيئة الإنتاج الخاصة بك من المراحل الأولى للتطوير. بنفس الطريقة، تستخدم خطوط الأنابيب في البيئات العليا snyk للسماح أو منع أنظمة التطبيق من دخول المرحلة الإنتاجية النهائية.

تنفيذ سير عمل CI/CD في GitHub Actions

في هذه الخطوة، ستتعلم كيفية إنشاء واختبار خط أنابيب CI/CD عيني مع فحص الضعف المتكامل عبر سير عمل GitHub. لتعلم أساسيات استخدام إجراءات Github مع Kubernetes من DigitalOcean، يُرجى الرجوع إلى هذا البرنامج التعليمي.

يقوم الخط الأنابيب المقدم في القسم التالي ببناء ونشر تطبيق game-2048-example من مستودع DigitalOcean kubernetes-sample-apps.

على مستوى عرض عالٍ، يتكون سير عمل CI/CD لـ game-2048 المقدم في مستودع kubernetes-sample-apps من المراحل التالية:

1. مرحلة بناء واختبار التطبيق – تقوم ببناء فنيات التطبيق الرئيسية وتشغيل الاختبارات التلقائية.
2. مرحلة فحص صورة تطبيق Snyk – تفحص صورة دوكر التطبيق للضعف المعروفة. إنها تعمل كبوابة، والحالة النهائية للخط الأنابيب (ناجح/فاشل) تعتمد على هذه الخطوة. في حالة الفشل، يتم إرسال إشعار Slack.
3. مرحلة بناء صورة التطبيق ودفعها – تقوم ببناء الصورة التطبيقية ووسمها باستخدام أحدث SHA للتعهد بالتوزيع. ثم، يتم دفع الصورة إلى DOCR.
4. مرحلة فحص بنية تطبيق Snyk كشف للثغرات المعروفة في توزيعات YAML الخاصة بـ Kubernetes المرتبطة بالتطبيق. تعمل كبوابة، وحالة الخط النهائية (نجاح/فشل) تعتمد على هذه الخطوة. في حالة الفشل، يتم إرسال إشعار عبر Slack أيضًا.
5. مرحلة نشر التطبيق – تنشئ التطبيق على Kubernetes (DOKS).

الرسم البياني أدناه يوضح كل وظيفة في الخط والخطوات المرتبطة بها (يتم عرض التكوين ذو الصلة فقط):

كيف يمكنك إخفاق الخط إذا لم يتم تحقيق مستوى الامتثال الأمني المطلوب؟

يوفر Snyk CLI علماً يسمى --severity-threshold لهذا الغرض. يترابط هذا العلم مع مستوى الخطورة العام المحسوب بعد كل فحص. في حالة Snyk، يأخذ مستوى الخطورة أحد القيم التالية: منخفض, متوسط, عالي, أو حرج. يمكنك إخفاق أو نجاح الأنبوب الخاص بالتطبيق بناءً على قيمة مستوى الخطورة وإيقاف نشر التطبيق إذا لم تتم المطابقة للشروط.

الصورة أدناه توضح تدفق مثال لأنبوب CI/CD المستخدم في هذا الدليل:

يرجى اتباع الخطوات أدناه لإنشاء واختبار سنيك CI/CD سير العمل في مستودع GitHub kubernetes-sample-apps:

1. انسخ مستودع GitHub kubernetes-sample-apps.
2. أنشئ الـ GitHub encrypted secrets التالية لنسختك kubernetes-sample-apps (علامة الإعدادات -> الأسرار -> الإجراءات):
   • DIGITALOCEAN_ACCESS_TOKEN – يحمل رمز حسابك في DigitalOcean.
   • DOCKER_REGISTRY – يحمل اسم سجل دوكر الخاص بك في DigitalOcean بما في ذلك النقطة النهائية (على سبيل المثال registry.digitalocean.com/sample-apps).
   • DOKS_CLUSTER – يحمل اسم عنقود DOKS الخاص بك. يمكنك تشغيل الأمر التالي للحصول على اسم عنقود DOKS الخاص بك: doctl k8s cluster list --no-header --format Name.
   • SNYK_TOKEN – يحمل معرف حساب مستخدم Snyk الخاص بك – قم بتشغيل: snyk config get api للحصول على المعرف. إذا لم يعمل ذلك، يمكنك استرداد الرمز من صفحة إعدادات حساب المستخدم الخاصة بك.
   • SLACK_WEBHOOK_URL – يحمل عنوان URL الوارد للويب هوك في Slack الخاص بك المستخدم لإشعارات مسح snyk.
3. انتقل إلى علامة الإجراءات في مستودع الشوكة الخاص بك وحدد سير العمل مثال CI/CD لـ لعبة 2048 Snyk:
   
4. انقر على زر تشغيل سير العمل واترك القيم الافتراضية:
   

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

سيفشل الأنبوب ويتوقف عند تشغيل المهمة snyk-container-security-check. من المتوقع هذا لأن قيمة مستوى الخطورة الافتراضية المستخدمة في مدخل سير العمل، وهي متوسطة، لا تلبي التوقعات. يجب أن تتلقى أيضًا إشعارًا عبر Slack يحتوي على تفاصيل حول تشغيل سير العمل:

في الخطوات التالية، ستتعلم كيفية التحقيق في تقرير فحص snyk لتصحيح المشكلات، وخفض مستوى الخطورة، وتمرير الأنبوب.

الخطوة 4 – استكشاف نتائج فحص Snyk وإصلاح المشاكل المُبلغ عنها

عندما لا يتم تحقيق عتبة مستوى الخطورة، ستفشل سير العمل في GitHub لـ لعبة 2048، وسيتم إرسال إشعار إلى Slack مع تفاصيل إضافية. كما يتم نشر تقارير الأمان على GitHub والوصول إليها في علامة الأمان في مستودع مشروعك.

يقوم سير العمل لعبة 2048 بتشغيل فحصين أمنيين:

1. فحوص أمان صورة الحاوية – يتم استخدام وظيفة فحص أمان Snyk للحاوية لهذا الغرض. الأمر المعادل المستخدم هو – snyk container test <GAME-2048-IMAGE>:<TAG> --file=/path/to/game-2048/Dockerfile.
2. فحوصات إعدادات Kubernetes – يتم استخدام وظيفة فحص أمان Snyk للإعدادات لهذا الغرض. الأمر المعادل المستخدم هو – snyk iac test /path/to/project/kubernetes/manifests.

بالتالي، تخفيض مستوى الخطورة واجتياز سير العمل يتضمن:

1. استكشاف وإصلاح المشاكل المُبلغ عنها بواسطة وظيفة فحص أمان Snyk للحاوية.
2. استكشاف وإصلاح المشاكل المُبلغ عنها بواسطة وظيفة فحص أمان Snyk للإعدادات.

بعد ذلك، ستتعلم كيفية التعامل مع كلٍ منها بالترتيب.

التحقق وإصلاح الثغرات في صور الحاويات

الخط الزمني العيني المستخدم في هذا الدليل يقوم بتشغيل فحوصات الأمان لصورة الحاوية game-2048 والDockerfile المرتبطة عبر وظيفة snyk-container-security-check.

وظيفة snyk-container-security-check تقوم بتشغيل الخطوات التالية:

1. تنشيء صورة تطبيق game-2048 Docker محليًا. يتم تنفيذ هذه الخطوة باستخدام إجراء GitHub docker-build-push.
2. تشغيل فحوصات الأمان من Snyk لصورة حاوية التطبيق و Dockerfile. يتم تنفيذ هذه الخطوة باستخدام أمر snyk container test. يتم تصدير نتائج المسح باستخدام تنسيق GitHub SARIF. يتم التحكم في عتبة مستوى الأمان من خلال الوسيطة –severity-threshold – إما أن تكون معينة على أساس معامل الإدخال snyk_fail_threshold إذا تم تشغيل سير العمل يدويًا، أو عبر متغير البيئة SNYK_FAIL_THRESHOLD، إذا تم تشغيل سير العمل تلقائيًا.
3. تتم نشر نتائج المسح (تنسيق SARIF) في علامة الأمان في مستودع التطبيق الخاص بك. يتم تنفيذ هذه الخطوة باستخدام إجراء codeql على GitHub.

يظهر المقتطف أدناه المنطق الرئيسي لوظيفة snyk-container-security-check:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

لتصحيح المشاكل المبلغ عنها، تحتاج أولاً إلى التحقق من علامة الأمان في مستودع فرعي لتطبيقات kubernetes-sample-apps:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
 سترى مجموعة من الثغرات لصورة دوكر الأساسية في هذه الحالة. انقر على كل منها للتوسيع ورؤية المزيد من التفاصيل:
 لإنهاء التحقيقات ورؤية التوصيات التي تقدمها Snyk، تحتاج إلى فحص إخراج وظيفة snyk-container-security-check من سير العمل الرئيسي:
ملاحظة: Snyk container test يقدم إمكانية تصدير النتائج بتنسيق SARIF، ولكنه لا يعرف كيفية تحميل التقارير إلى بوابة Snyk السحابية. من ناحية أخرى، snyk container monitor يقدم إمكانية تحميل النتائج إلى بوابة Snyk السحابية، لكنه لا يمكنه تصدير SARIF. لذلك يستخدم هذا الدليل snyk container test مع ميزة التصدير إلى SARIF. بعض التوصيات غير متاحة في إخراج SARIF للأسف. لذلك، يجب عليك أيضًا البحث في إخراج وظيفة الوظيفة للحصول على التوصيات.
تُظهر نتائج عملية الـ snyk-container-security-check أن سنيك يوصي بتحديث إصدار الصورة الأساسية من node:16-slim إلى node:18.6.0-slim. هذا التغيير يقضي على مشكلة(مشاكل) الخطر العالي، ويقلل أيضًا من عدد الثغرات المُبلَغ عنها من 70 إلى 44 - وهذا تقليل كبير يقارب 50%!!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

الآن، قم بفتح ملف الـ Dockerfile لتطبيق لعبة 2048 من فرعك، وقم بتغيير التوجيهات FROM لتشير إلى الإصدار الجديد (node:18.6.0-slim في هذا الوقت من الكتابة):

#

# يمكن تعيين وضع البناء عبر متغير البيئة NODE_ENV (تطوير أو إنتاج)

# انظر إلى package.json و webpack.config.js للمشروع

#

أخيرًا، قم بتأكيد التغييرات إلى مستودع GitHub الخاص بك وقم بتشغيل سير العمل مرة أخرى (دون تغيير قيم الافتراضيات). في هذه المرة يجب أن يمر العملية الخاصة بـ snyk-container-security-check:

عند الانتقال إلى علامة الأمان في مشروعك، يجب أن لا تُبلَغ عن أي مشكلات.

كيف تضمن تقليل ثغرات الصورة الأساسية في المستقبل؟

1. أفضل الطرق هي استخدام صورة أساسية بأقل قدر ممكن من الآثار – كلما كانت الثنائيات أو التبعيات أقل في الصورة الأساسية، كلما كان ذلك أفضل. ممارسة جيدة أخرى هي مراقبة مشاريعك بشكل مستمر، كما هو موضح في قسم مراقبة مشاريعك بانتظام في هذا الدليل.
2. ستلاحظ أن الخط الأنابيب لا يزال يفشل، ولكن هذه المرة في مرحلة فحص أمان البنية التحتية للشبكة. من المتوقع هذا لأن هناك مشاكل أمان مع التصريحات الخاصة بـ Kubernetes المستخدمة لنشر التطبيق. في القسم التالي، ستتعلم كيفية التحقيق في هذا الوضع وتطبيق توصيات أمان Snyk لإصلاح المشاكل المبلغ عنها.

التحقيق في الثغرات في التصريحات الخاصة بـ Kubernetes وإصلاحها

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

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

1. تتحقق وظيفة فحص أمان البنية التحتية للشبكة من ثغرات (أو إعدادات غير صحيحة) في التصريحات الخاصة بـ Kubernetes، وتنفذ الخطوات التالية:
2. فحوصات أمان Snyk لملفات تكوين Kubernetes من دليل مشروع game-2048-example. يتم تنفيذ هذه الخطوة باستخدام الأمر snyk iac test. يتم تصدير نتائج المسح باستخدام تنسيق GitHub SARIF. يتم التحكم في عتبة مستوى الأمان عبر الوسيطة –severity-threshold – إما تعيينها إلى معلمة الإدخال snyk_fail_threshold إذا تم تشغيل سير العمل يدويًا، أو إلى متغير البيئة SNYK_FAIL_THRESHOLD إذا كان سير العمل يعمل تلقائيًا. وأخيرًا، يُستخدم أيضًا الوسيطة –report لإرسال نتائج المسح إلى بوابة Snyk السحابية.

تُنشر نتائج المسح (تنسيق SARIF) إلى علامة التبويب الأمنية في مستودع تطبيقك. يتم تنفيذ هذه الخطوة باستخدام إجراء GitHub codeql.

يظهر المقتطف التالي التنفيذ الفعلي لكل خطوة من وظيفة snyk-iac-security-check:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

لإصلاح المشكلات المُبلَغ عنها، لديك خياران:

• استخدم بوابة Snyk السحابية واستعرض مشروع game-2048 للتحقق من التفاصيل:
• استخدم علامة التبويب الأمانية في مستودع تطبيق لعبة 2048 الخاص بك للتحقق من التفاصيل:
  
• بأي حال من الأحوال، ستحصل على توصيات حول كيفية إصلاح المشكلات المبلغ عنها.
• لهذا الدليل، ستستخدم بوابة السحابة Snyk للتحقيق في المشكلات الأمنية المبلغ عنها. أولاً، انقر فوق الإدخال game-2048-example من قائمة المشاريع، ثم حدد الملف kustomize/resources/deployment.yaml:

بعد ذلك، حدد خانة الاختيار Medium في القائمة الفرعية Severity من اليسار لعرض مشاكل مستوى medium فقط:

بعد ذلك، يمكنك فحص كل بطاقة مشكلة مبلغ عنها والتحقق من التفاصيل. قم بالنقر على زر Show more details من بطاقة Container is running without root user control – ستتلقى المزيد من التفاصيل حول المشكلة الحالية، وتلميحات مهمة حول كيفية إصلاحها:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

1. بعد جمع جميع المعلومات من كل بطاقة، يمكنك المضي قدماً وتحرير ملف deployment.yaml من مستودعك (الموجود في المجلد الفرعي game-2048-example/kustomize/resources). الإصلاحات موجودة بالفعل، ما عليك سوى فك تعليق الأسطر الأخيرة من الملف. يجب أن يبدو الملف deployment.yaml النهائي على النحو التالي:
2. readOnlyRootFilesystem – يشغل صورة الحاوية في وضع القراءة فقط (لا يمكن تعديل الملفات باستخدام kubectl exec داخل الحاوية).

allowPrivilegeEscalation – تعيين allowPrivilegeEscalation إلى false يضمن عدم قدرة أي عملية فرعية للحاوية على الحصول على مزيد من الامتيازات من والديها.

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

أخيرًا، قم بتنفيذ التغييرات لملف deployment.yaml وقم بدفعها إلى الفرع الرئيسي. بعد تشغيل سير العمل يدويًا يجب أن يكتمل بنجاح هذه المرة:

يجب أيضًا أن تتلقى إشعارًا أخضر من Slack من عملية فحص snyk. انتقل إلى رابط بوابة Snyk وتحقق مما إذا كانت المشاكل التي قمت بإصلاحها مؤخرًا قد اختفت – يجب عدم وجود مشاكل متوسطة المستوى مُبلَّغ عنها.

تحقق مما إذا كان نشر لعبة 2048 لديه نظام ملفات للقراءة فقط (غير قابل للتغيير) عن طريق كتابة إلى ملف index.html المستخدم من قبل تطبيق لعبة 2048:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

الناتج يبدو مشابهاً لما يلي:

الناتج
/bin/bash: /public/index.html: نظام الملفات للقراءة فقط file
command terminated with exit code 1

تحقق مما إذا كان نشر لعبة 2048 لديه نظام ملفات للقراءة فقط (غير قابل للتغيير) عن طريق كتابة إلى ملف index.html المستخدم من قبل تطبيق لعبة 2048:

يبدو الناتج مشابهاً لذلك:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

تحقق مما إذا كان الحاوية تعمل كمستخدم غير جذري (يجب أن تطبع رقمًا صحيحًا مختلفًا عن الصفر – على سبيل المثال، 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

تحقق مما إذا كانت الحاوية تعمل كمستخدم غير جذري (يجب أن تطبع رقمًا صحيحًا مختلفًا عن الصفر – على سبيل المثال، 1000):

إذا نجحت جميع الفحوصات، فقد قمت بتطبيق التوصيات الأمنية المطلوبة بنجاح.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

راقب مشاريعك بشكل منتظم

تلك الأتمتة لفحص الثغرات التي قمت بتنفيذها حتى الآن هي بداية جيدة ولكنها ليست مثالية. لماذا؟

مشكلة واحدة مع النهج الحالي هو أنك لا تعرف أبدًا عندما يتم الإبلاغ عن مشاكل جديدة للأصول التي نشرتها بالفعل في بيئاتك. بعبارة أخرى، قمت بتقييم مخاطر الأمان واتخذت التدابير لإصلاح المشاكل في نقطة زمنية محددة – عند تنفيذ أتمتة CI/CD الخاصة بك.

ولكن ماذا لو تم الإبلاغ عن مشاكل جديدة في الوقت بين الحين والآخر، وكان تطبيقك عرضة للضعف مرة أخرى؟ يساعدك Snyk على التغلب على هذا الوضع من خلال ميزة المراقبة. تساعد ميزة المراقبة في Snyk على التعامل مع الثغرات الجديدة التي يتم الكشف عنها باستمرار. عندما يتم الجمع بين التكامل مع Slack في Snyk (الموضح في الخطوة 6 – تمكين إشعارات Slack)، يمكنك اتخاذ إجراءات فورية لإصلاح المشاكل المكتشفة حديثًا التي قد تؤثر على تطبيقك في بيئة الإنتاج.

للاستفادة من هذه الميزة، كل ما عليك فعله هو استخدام الأمر snyk monitor قبل أي خطوات نشر في أنابيب CI/CD الخاصة بك. بناء الجملة مشابه جدًا لأوامر snyk test (واحدة من الأشياء الرائعة حول واجهة سطر الأوامر لـ Snyk هو أنها تم تصميمها بتوحيد في الاعتبار). سيقوم أمر snyk monitor بإرسال لقطة إلى بوابة Snyk السحابية، ومن هناك ستتلقى إشعارًا بشأن الثغرات الجديدة التي تم الكشف عنها لمشروعك.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

من حيث أتمتة سير العمل في GitHub، يمكنك مراقبة تطبيقك في الحاوية باستخدام الأمر snyk-container-security-check في الوظيفة، بعد اختبار الثغرات. يظهر المقتطف أدناه تنفيذًا عمليًا للأنبوبة المستخدمة في هذا الدليل (تم حذف بعض الخطوات للوضوح):

1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
3. –target-name=${{ env.PROJECT_NAME }} \
4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

المقتطف أعلاه يوضح خطوة إضافية تسمى مراقبة حاوية التطبيق باستخدام Snyk حيث يتم تشغيل جهاز مراقبة حاوية snyk الفعلي.

بعد تشغيل أمر مراقبة snyk ، يمكنك تسجيل الدخول إلى واجهة مستخدم Snyk على الويب لرؤية أحدث لقطة وتاريخ ل مشروع الخاص بك:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

يمكنك اختبار ومراقبة مصدر تطبيقك أيضًا في بناء واختبار التطبيق الوظيفة. يوضح المقتطف التالي مثالًا على التنفيذ المستخدم في سير العمل على GitHub في هذا الدليل:

بعد ذلك ، ستتلقى إشعارات عبر Slack بانتظام حول الثغرات الأمنية الجديدة المكشوفة لمشروعك.

معالجة الاستثناءات

هناك حالات عندما لا ترغب في أن يؤثر التقرير النهائي على بعض المشاكل التي يعتبر فريقك آمنة تجاهلها. يقدم Snyk ميزة مدمجة لإدارة الاستثناءات والتغلب على هذا الوضع.

يمكنك قراءة المزيد حول هذه الميزة هنا.

Snyk لبيئات التطوير المتكاملة

تقدم Snyk الدعم لمجموعة متنوعة من بيئات التطوير المتكاملة، مثل:

ملحق Eclipse.

ملحق JetBrains.

• امتداد Visual Studio.
• امتداد Visual Studio Code.
• سيساعدك الملحقات المذكورة أعلاه في اكتشاف الأخطاء وإصلاحها في مراحل مبكرة من عملية التطوير، مما يقضي على الإحباط والتكاليف والثغرات الأمنية في أنظمة الإنتاج. كما يساعدك في تقليل الدورات والجهد البشري على المدى الطويل. على سبيل المثال، لكل مشكلة أمنية تقريرها أتمتة CI/CD الخاصة بك، تحتاج إلى العودة وإصلاح المشكلة في الكود الخاص بك، وتنفيذ التغييرات، وانتظار تشغيل أتمتة CI/CD مرة أخرى، ثم تكرار العملية في حالة الفشل.
• يمكنك من الوثائق الرسمية قراءة المزيد حول هذه الميزات على الصفحة Snyk لبيئات التطوير المتكاملة.
• الخطوة 5 – تشغيل سير عمل Snyk CI/CD تلقائيًا
• يمكنك ضبط سير العمل ليتم تشغيله تلقائيًا في كل عملية ارتباط أو طلب سحب ضد الفرع الرئيسي عن طريق فك تعليق الأسطر التالية في أعلى ملف game-2048-snyk.yaml:
• بعد تعديل الملف، قم بتأكيد التغييرات على فرعك الرئيسي، ويجب أن تكون جاهزًا للبدء.
• الخطوة 6 – تمكين إشعارات Slack
• يمكنك إعداد Snyk لإرسال تنبيهات Slack حول الثغرات الجديدة المكتشفة في مشاريعك وحول الترقيات أو التصحيحات الجديدة التي أصبحت متاحة.
• لتعيين ذلك، ستحتاج إلى إنشاء رابط ويب Slack. يمكنك القيام بذلك إما عبر واجهات الويب الواردة أو عن طريق إنشاء تطبيق Slack الخاص بك. بمجرد إنشاء رابط الويب الخاص بك في Slack، انتقل إلى إعدادات ‘إدارة المؤسسة’ الخاصة بك، أدخل الرابط، وانقر فوق الزر الاتصال: