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

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

لإضافة مرحلة جديدة من التطوير - التحليل الثابت ، سيكون عليك دراسة كيفية عمل كل فريق واقتراح حل مناسب للجميع. في الشركات الصغيرة ، قد لا يكون أمر التطوير الثابت موجودًا على الإطلاق. يمكن أن يكون تنفيذ المحلل ذريعة لبناء العملية. لكي يكون التكامل أكثر ليونة ، ننصحك بمعرفة أي المحلل لديه الإمكانيات لذلك.
ما هي خيارات التكامل؟
عادة ، يفترض المحلل وجود واجهة غير رسومية (CLI ، REST) للتكامل في أي عملية. هناك محللات مع تكامل جاهز: مع أدوات البناء وبيئات التطوير ، مع أنظمة التحكم في الإصدار (Git ، SVN) ، خوادم CI / CD (Jenkins ، TeamCity ، TFS) ، أنظمة إدارة المشاريع (Jira) وإدارة المستخدم (Active Directory). كلما كان ذلك مفيدًا لشركتك ، سيكون من الأسهل إعداد كل شيء.
كيف يمكنك بناء عملية؟
النظر في الوضع القياسي: الإدارات المعنية هي أمن المعلومات ، وإدارة الإصدار والتطوير. وكقاعدة عامة ، فإن عميل تنفيذ المحلل هو أمن المعلومات (IS). المهمة هي الاتفاق على من ومتى وماذا سيفعل. نحن نميز الخطوات التالية:
بدء التحليل ، ومعالجة نتائج التحليل ، وإنشاء طلب لإصلاح الثغرة الأمنية ، وإصلاح الثغرة الأمنية ، والتحقق من التصحيح . النظر في كل خطوة في مزيد من التفاصيل.
الخطوة 1. قم بتشغيل التحليل
يمكنك تشغيل التحليل يدويًا أو تلقائيًا. النهج لها إيجابيات وسلبيات.
يدوياهو نفسه يتذكر المحلل ، قام بتنزيل الكود بنفسه ، وذهب ونظر إلى النتائج.

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

استخدام حالات التحقق. لالتقاط نتائج التحقق ، عادةً ما يعرض المحللون التعامل مع حالات عدم الحصانة: التأكيد أو الرفض باعتبارها إيجابية خاطئة. كقاعدة عامة ، يجب الحفاظ على العمل المنجز أثناء إعادة الفحص.
الخطوة 3. إنشاء طلب إصلاح الثغرة الأمنية
إذا بدأ المطور في تحليل الكود الخاص به وقام على الفور بإصلاح الثغرات الأمنية ، فلن تحتاج بالطبع إلى إنشاء طلبات غير ضرورية.
إذا قام ضابط الأمن بمراجعة النتائج والتحقق منها ، فعادةً ما يحتاج الشخص إلى تعيين مهمة لتصحيح الأخطاء الإضافية المؤكدة. لقد واجهنا مرارًا وتكرارًا حقيقة أنه في هذه الخطوة ظهرت الصعوبات.
نموذج طلبهناك شركات يتم فيها تثبيت المهام الكبيرة للمرحلة في نظام إدارة المشروع (على سبيل المثال ، جيرا). وبالنسبة للمهام الفرعية والأخطاء ، على سبيل المثال ، يتم استخدام GitLab Issues ، والتي يمكن الوصول إليها فقط من قائد الفريق وفريقه. يحدث أيضًا أن التجميع مستحيل دون إنشاء مهمة منفصلة في نظام إدارة المشروع. يمكن أن يحتوي المحلل على تكامل يمكنك من خلاله إنشاء الاستعلامات الضرورية على الفور في الواجهة.
غالبًا ما يكون داخل كل شركة مع العديد من مجموعات التطوير ، كل منهم لديه إجراءاته الخاصة لتنفيذ مهام العمل. وتحتاج إلى التكيف مع الجميع. أسئلة مطروحة:
- هل يستحق كل هذا العناء تخصيص مشروع منفصل لإصلاح الثغرات الأمنية أو إنشاء مهام في تلك القائمة؟
- هل الضعف مشكلة مألوفة أو كيان جديد؟
- إنشاء مهمة منفصلة لكل نقطة ضعف أو مجموعة مماثلة؟
- ما الذي يجب أن أقدمه بوصفًا للمشكلة: ارتباطًا لثغرة أمنية في واجهة المحلل أو مكانًا في الكود ووصف المشكلة بإيجاز؟
- وهل يحتاج المطور إلى الوصول إلى النتائج - فقط أرسل تقرير PDF مع النص "انظر صفحة 257 "وهذا يكفي؟
بالطبع ، يعتمد ذلك على كيفية ضبط العملية في الفريق ، وما أنظمة تتبع الأخطاء المستخدمة.
إذا كان الرمز مكتوبًا من قِبل المقاولين الذين يكون الوصول إليهم للأنظمة الداخلية في حده الأدنى ، يكون المخطط مع تقرير PDF مناسبًا. عادة ، بالنسبة للتقرير ، يمكنك تحديد نقاط الضعف التي تهمك وإرسالها على الفور إلى العنوان المطلوب من واجهة محلل.
إذا لم تتمكن الشركة من القيام بخطوة واحدة دون إنشاء مشروع لنوع معين من المهام مع قدر معين من الموارد ، فيجب عليك البحث عن أداة تكامل لنظامك. ستنشئ عمليات الدمج الأكثر مرونة وصفًا للمهمة نيابة عنك (لن ينسوا حتى رابط الكود المصدر في نظام التحكم في الإصدار) وسيسمح لك بملء جميع الحقول المطلوبة. اختر نوع المهمة ، وحدد الوالد والفنانين وحتى إصدار الإصدار.
تكاليف العمالة وشروطهاإذا قرر الفريق تقديم تقييم لتكاليف اليد العاملة لكل مهمة ، فإن مهمة إصلاح الثغرة الأمنية يجب أن تتم على نفس المنوال. على طول الطريق ، يتحقق المطورون من نقاط الضعف. في بعض الأحيان ، يتبين في هذه الخطوة أن الثغرة الأمنية خاطئة أو مستحيلة الاستغلال.
ولكن كقاعدة عامة ، لا تزال الموارد غير كافية لإصلاح جميع نقاط الضعف على الفور. لذلك ، من الضروري أيضًا تنسيق أولوياتها.
تم تحديد المهام حسب تكاليف العمل والأولويات - ثم يقرر المسؤولون عن تواريخ الإصدار (قد يكون هذا هو مدير المشروع أو قائد الفريق نفسه) ما يجب إصلاحه ومتى. في البداية ، باستخدام المحلل ، نوصيك بعدم تأجيل الإصدار ، إن لم تكن جميع نقاط الضعف ثابتة.
الخطوة 4. إصلاح نقاط الضعف
كيفية تخصيص الموارد بشكل صحيح: ربط أشخاص جدد أو تكليف أولئك الذين يشاركون بالفعل في التنمية هي مشكلة في الميزانية. هناك شيء واحد صحيح: إذا خصصت الشركة موارد لتثبيت المحلل ، فستحتاج إلى التحضير لتكاليف إصلاح الثغرات الأمنية. هناك طريقة ممكنة تتمثل في تحديد النسبة المئوية من الوقت لإصلاح الثغرات الأمنية باعتبارها وظيفة ذات دين تقني.
هناك سيناريوهان: صحح على الفور في عملية التطوير أو بناءً على طلب ضابط الأمن. إصلاح الثغرات الأمنية أثناء التطوير هو سيناريو مثالي. وجدت على الفور - تصحيح على الفور. يقوم المطور بفحص فرع الميزة الخاص به قبل طلب الدمج مع الفرع الرئيسي. يمكن أتمتة هذا أيضًا من خلال عمليات الدمج: مع بيئة التطوير أو أدوات البناء أو نظام التحكم في الإصدار أو CI / CD.
سيناريو آخر هو تحليل فرع التطوير الرئيسي بعد كل التغييرات. يقوم مسؤول الأمن أو قائد الفريق بمراجعة النتائج وإنشاء مهام لإصلاح الثغرات الأمنية. هذا السيناريو هو مضيعة للوقت. عند إدخال المطور هو الكود المصدري ومهمة التصحيح ونتائج التحليل. بالنسبة للمطور ، لا تختلف مهمة إصلاح الثغرة الأمنية عن إصلاح الخلل.
الخطوة 5. تحقق من الإصلاح
تحتاج إلى التأكد من أن مشكلة عدم الحصانة ثابتة بالفعل ولم تظهر مشكلة جديدة في مكانها. هناك نتائج تحليل الشفرة المصححة. ما الذي تبحث عنه؟ ملف ورقم السطر من الضعف؟ أو البحث عن طريق اسم الضعف؟ إنه ممكن و كذلك. ولكن إذا تم تغيير الكود ، فقد يتحول الخط مع الثغرة الأمنية ، وقد لا يزال هناك العديد من تكرارات الثغرة الأمنية الواحدة. قد يظهر بعض المحللين نقاط ضعف "ثابتة". توافق ، حتى تتمكن من التحقق من إصلاح الثغرات بشكل أسرع (انظر لقطة الشاشة).

أمثلة
فيما يلي اثنين من السيناريوهات المحتملة.
السيناريو 1
يستخدم الفريق Git للتحكم في الإصدار ، و Jira لإدارة المشاريع والمهام. جينكينز تكوين جدول البناء. على سبيل المثال ، مرة واحدة في اليوم إذا كانت هناك تغييرات في الفرع. كخطوة إضافية ، يشار إلى بداية المحلل.
يقوم ضابط الأمن بمراجعة نتائج تحليل الفرع الرئيسي (ماجستير أو تطوير) ، ويقوم المطورون بمراجعة فروع الميزة.
المطورين إصلاح الثغرات الأمنية إذا لزم الأمر. إذا كان بإمكان المحلل تصفية الثغرات الأمنية عند الطلب: قم بإظهار ثغرات أمنية جديدة فقط أو عدم إظهار ثغرات أمنية في مكتبات الطرف الثالث ، أو إظهار الثغرات الأمنية في دليل أو ملف محدد - سيتمكّن المطور من عرض النتائج المثيرة للاهتمام له بسرعة. لذا ، فإن احتمال التصحيح أعلى.
يقوم ضابط الأمن بمراجعة نتائج تحليل الفرع الرئيسي. باستخدام التكامل مع Jira ، ينشئ ضابط الأمن مهام إدارة الثغرة الأمنية من واجهة المحلل. التالي هو تنسيق المواعيد النهائية والأولويات.
عندما يتم إصلاح مشكلة عدم الحصانة ويمر الرمز الجديد بجميع مراحل التطوير الداخلي (المراجعة من قيادة الفريق ، واختبار المستخدم والانحدار) ، يجب أن يتأكد ضابط الأمن من أن مشكلة عدم الحصانة لم تعد موجودة. المؤلف يغلق المهمة المكتملة.
السيناريو 2
تتم كتابة رمز الشركة بواسطة مجموعة من المقاولين. يتفاعل Timlid مع المطورين عبر البريد الإلكتروني ويستخدم GitLab للتحكم في الإصدار. لا يستطيع المقاولون الوصول إلى أنظمة إدارة المشاريع الداخلية (جيرا).
يستعرض ضابط الأمن أو قائد الفريق نفسه نتائج تحليل فرع التطوير الرئيسي. المقاولون لا يستطيعون الوصول إلى محلل. إذا كانت هناك ثغرات تحتاج إلى إصلاح ، فإن ضابط الأمن يرسل تقرير PDF مع نتائج التحليل إلى قائد الفريق أو على الفور إلى المطور.
من خلال التقرير ، يكتشف المطور أين توجد مشكلة عدم الحصانة وما هي مكوناتها وكيف يمكن إصلاحها. من المهم إذا كانت الثغرات الأمنية المرتبطة بتدفق البيانات غير الآمنة (على سبيل المثال ، حقن SQL) ، سيتم تفريغ مخطط التوزيع في التقرير: من مصدر البيانات إلى استخدامه في استدعاء الوظيفة / الطريقة (انظر لقطة الشاشة).

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