🔰 👩🏿‍🤝‍👩🏾 🚀 (S) SDLC ، أو كيفية جعل التنمية أكثر أمانًا. الجزء الأول 📄 👋🏿 ⭕️

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

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

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

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

يوشك

هنا مثال - إدخال SQL معروف. في هذا المثال ، تندرج البيانات من المستخدم في الوظيفة المكتملة من الاستعلام ، والتي يتم تمريرها إلى وظيفة injectableQuery ، وهناك تندرج بالفعل في استعلام SQL ، مما يجعل التطبيق عرضة لخطر إدخال SQL.

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

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

على أساس التعقيد الخوارزمي ، يبرز عدد من المشكلات الفنية التي تميز تنفيذ أداة SAST عن أجهزة التحليل الثابتة الأخرى ، على سبيل المثال ، SonarQube. سنناقش هذه القضايا في سلسلة من المقالات. المفسد: استهلاك الموارد ، ومدة التحليل ، والنتائج الإيجابية الخاطئة.

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

في المقالة الأولى ، حاولنا تصنيف القضايا الرئيسية التي تنشأ أثناء دراسة SAST ، وكذلك بعد قرار تنفيذ الأداة. سنتحدث عن بعض المشكلات هنا ، وسيذهب البعض إلى المقالات التالية.

لنبدأ

لماذا SAST إذا كان لديك بالفعل محللات ثابتة مجانية؟

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

هناك محللات ثابتة جيدة أخرى مفتوحة. يمكنك استدعاء البق البقعي (findbugs) لـ JVM bytecode باستخدام المكوّن الإضافي find-sec-bugs ، الذي ينفذ التحليل الجاري لدفق البيانات مع مجموعة صغيرة من القواعد. هناك محلل قطاع طرق معروف لـ Python. لا يسع المرء إلا أن يذكر محلل ثابت مدمج في clang ، والذي يحتوي على محرك تحليل جيد وقاعدة قاعدة جيدة.

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

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

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

ما أداة SAST للاختيار؟

سوف أسهب قليلاً في مرحلة اختيار الأداة. هناك الكثير من أدوات SAST ، وعادة ما يتم عرض عدة قطع في السوق (3-4). السؤال الذي يطرح نفسه ، كيف تختار الأداة المناسبة ، ما الذي تبحث عنه؟ لن أفاجأ هنا ، سأركز على ثلاث نقاط: المقارنة الوظيفية ، مقارنة الجودة والترخيص. من المهم أن تأخذ أداة الاختبار (التجريبية) في دائرتك المحلية وتتحقق من التعليمات البرمجية في بنيتك الأساسية.

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

الإطلاق الأكثر تلقائية للمسح الضوئي (من الناحية المثالية ، بدون إعدادات غير ضرورية في زرين ، يمكنك تشغيل المسح) ؛
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

إن قدرات التكامل مهمة للغاية - مع CI / CD ، و bugtrackers ، والمستودعات ، و Active Directory. سيكون من الرائع محاولة أتمتة إجراء بسيط باستخدام واجهة برمجة التطبيقات ، إن وجدت.

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

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

ثانيًا ، من المهم جدًا أثناء التجربة التواصل مع البائع. إن SAST ليس أسهل شيء ، وغالبًا ما يكون كافيًا الحصول على النصيحة المعتادة من البائع من أجل تقدير قوة الأداة تمامًا.

في أي نقطة تبدأ المسح؟

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

مع هذا النهج ، نحصل أيضًا على مكافأة: عندما يرى المطورون نتائج SAST "كل يوم" ، فإنهم يتقدمون في معرفة البرمجة الآمنة ، وبالتالي ، بشكل عام ، يتم تعزيز ثقافة التطوير الآمن وتتحسن الشفرة.

بالطبع ، عند تنفيذ SAST في عملية التطوير ، من الضروري التنفيذ في CI / CD ، وبناء DevSecOps. كان اتجاه نقل SAST من فحوصات التحكم قبل الإصدار إلى عملية التطوير مرئيًا منذ فترة طويلة ، وفي السنوات 2-3 الأخيرة ، لحق بسوقنا. الآن لا يمر الطيار دون اختبار قدرات التكامل.

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

مشكلة تقنية

ثم سأعطيك 4 أسئلة على الفور.

ربط SAST باسم SonarQube ، ما هي الصعوبة؟
يعمل SAST لفترة طويلة ، وكيفية تكوين DevSecOps؟
تقدم SAST نتائج إيجابية خاطئة ، وكيفية تكوين بوابة الجودة؟
وبدون ايجابيات كاذبة في التقرير ، عدة آلاف من نقاط الضعف ، ماذا أفعل بها؟

هذه هي المشاكل التقنية الرئيسية التي تنشأ عند تنفيذ ضريبة المبيعات. تنشأ للأسباب التالية.

نظرًا للطبيعة المتسارعة للخوارزميات ، يمكن لـ SAST العمل لفترة طويلة واستهلاك الكثير من الموارد - أكثر بكثير من اللنتر أو SonarQube.
للسبب نفسه ، يمكن أن تقدم SAST الكثير من الإيجابيات الخاطئة - من غير المحتمل أن يرغب المطورون في تحليل مجموعة من السقوط كل يوم بعد الفحص التالي.
عادة ، يتم إطلاق SAST على أساس التعليمات البرمجية للمرة الأولى ، ويمكن أن تُظهر التشغيل الأول الكثير من العمليات ، خاصة إذا كان هناك الكثير من التعليمات البرمجية ولم تكن قاعدة البيانات جديدة جدًا.

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

المسائل التنظيمية

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

يتم إنشاء القضايا التنظيمية بنفس الميزات التقنية التي ناقشناها في الفقرة السابقة. حسنًا ، إلى جانب ذلك ، لم يختف الانقسام القائم والمواجهة التاريخية بين التنمية والأمن. كما أشير إلى مقالنا السابق.

يتبع

تنفيذ SAST - من الضروري ، عادة ما يكون له ما يبرره. ولكن ، بدءًا من التنفيذ ، سيكون من الجيد التعرف على جميع المزالق التي تنشأ في طريقك. في هذه المقالة ، بدأنا في تفكيكها ، وسنستمر في الجوانب التقنية في ما يلي.

(S) SDLC ، أو كيفية جعل التنمية أكثر أمانًا. الجزء الأول