كان لدينا 2 محلل الشفرات ، 4 أدوات للاختبار الديناميكي ، الحرف اليدوية الخاصة بنا و 250 مخطوطة. ليس هذا كله ضروريًا في العملية الحالية ، ولكن منذ أن بدأت في تطبيق DevSecOps ، يجب أن ننتقل إلى النهاية.
مصدر . مؤلفو الشخصية: جوستين رولاند ودان هارمون.ما هو SecDevOps؟ ماذا عن DevSecOps؟ ما هي الاختلافات؟ أمان التطبيق - ما هو؟ لماذا لا يعمل النهج الكلاسيكي بعد الآن؟ يعرف
Yury Shabalin من
Swordfish Security الإجابة على كل هذه الأسئلة
. سوف يجيب Yuri على كل شيء بالتفصيل ويحلل مشاكل الانتقال من نموذج أمان التطبيق الكلاسيكي إلى عملية DevSecOps: كيفية التعامل مع تضمين عملية التطوير الآمنة في عملية DevOps وعدم كسر أي شيء ، وكيفية المرور بالمراحل الرئيسية لاختبار الأمان ، والأدوات التي يمكن استخدامها ، وما أنها تختلف وكيفية تكوينها بشكل صحيح لتجنب المزالق.
نبذة عن المتحدث: يوري شبالين - كبير مهندسي الأمن في
أمن سمك أبو سيف . وهو مسؤول عن تنفيذ SSDL ، عن الدمج العام لأدوات تحليل التطبيقات في نظام بيئي واحد للتطوير والاختبار. خبرة 7 سنوات في مجال أمن المعلومات. كان يعمل في بنك Alfa و Sberbank و Positive Technologies ، الذي يقوم بتطوير البرامج وتقديم الخدمات. رئيس المؤتمرات الدولية ZerONights ، PHDays ، RISSPA ، OWASP.
أمان التطبيق: ما هو؟
أمان التطبيق هو قسم الأمان المسؤول عن أمان التطبيق. لا ينطبق هذا على البنية التحتية أو أمان الشبكة ، أي ما نكتبه وما الذي يعمل عليه المطورون - هذه هي العيوب ونقاط الضعف في التطبيق نفسه.
تم تطوير اتجاه
SDL أو SDLC -
دورة حياة تطوير الأمان - بواسطة Microsoft. يُظهر الرسم التخطيطي نموذج SDLC الكنسي ، وتتمثل مهمته الرئيسية في مشاركة الأمن في كل مرحلة من مراحل التطوير ، بدءًا من المتطلبات ، وحتى إطلاقها وإطلاقها في الإنتاج. أدركت Microsoft أن هناك الكثير من الأخطاء في حفلة موسيقية ، وكان هناك الكثير منهم ، وهناك حاجة إلى القيام بشيء ما ، واقترحوا هذا النهج ، الذي أصبح قانونيًا.
لا يهدف أمان التطبيق و SSDL إلى الكشف عن الثغرات الأمنية ، كما هو شائع ، ولكن لمنع حدوثها. بمرور الوقت ، تم تطوير النهج المقبول من Microsoft وتطويره ، وظهر فيه غمر تفصيلي أعمق فيه.
SDLC الكنسي مفصلة للغاية في مختلف المنهجيات - OpenSAMM ، BSIMM ، OWASP. المنهجيات مختلفة ، لكنها متشابهة بشكل عام.
بناء الأمن في نموذج النضج
أنا أحب
BSIMM الأكثر -
بناء الأمن في نموذج النضج . أساس المنهجية هو فصل عملية أمان التطبيق إلى 4 مجالات: الحوكمة ، الذكاء ، نقاط اتصال SSDL والنشر. يحتوي كل مجال على 12 ممارسة ، والتي تمثل 112 نشاطًا.
يحتوي كل نشاط من 112 نشاطًا على
3 مستويات نضج : أولي ومتوسط ومتقدم. يمكن دراسة جميع الممارسات الـ 12 في أقسام ، وتحديد أشياء مهمة لك ، وفهم كيفية تنفيذها وإضافة عناصر تدريجياً ، على سبيل المثال ، تحليل الشفرة الثابتة والديناميكية أو مراجعة الشفرة. ترسم خطة وتعمل بهدوء عليها كجزء من تنفيذ الأنشطة المحددة.
لماذا DevSecOps
DevOps هي عملية كبيرة مشتركة تحتاج فيها إلى الاهتمام بالأمان.
في البداية ،
شملت DevOps عمليات الفحص الأمني. في الممارسة العملية ، كان عدد فرق الأمن أقل بكثير من الآن ، ولم يتصرفوا كمشاركين في العملية ، ولكن كهيئة مراقبة وإشراف تضع المتطلبات عليها وتحقق من جودة المنتج في نهاية الإصدار. هذا هو النهج الكلاسيكي الذي كانت فيه فرق الأمن وراء الجدار من التنمية ولم تشارك في هذه العملية.
المشكلة الرئيسية هي أن أمن المعلومات منفصل عن التطوير. عادةً ما يكون هذا نوعًا من دارات IB ويحتوي على 2-3 أدوات كبيرة ومكلفة. مرة واحدة كل ستة أشهر ، يصل الكود المصدري أو التطبيق ، وهو الأمر الذي يجب التحقق منه ، ومرة واحدة
يتم إنتاج
الآفات . كل هذا يؤدي إلى حقيقة أنه تم تأجيل المواعيد النهائية لدخول حفلة موسيقية ، وعدد كبير من نقاط الضعف من الأدوات الآلية تقع على المطور. لا يمكن تفكيك كل هذا وإصلاحه ، لأن نتائج الأشهر الستة السابقة لم يتم حلها ، وهنا مجموعة جديدة.
في عملية شركتنا ، نرى أن الأمن في جميع المجالات والصناعات يدرك أن الوقت قد حان لكي تسحب نفسك وتدور مع التطور في عجلة واحدة - في
Agile . يتلاءم نموذج DevSecOps بشكل جيد مع منهجية التطوير الرشيق والتنفيذ والدعم والمشاركة في كل إصدار وتكرار.
الانتقال إلى DevSecOps
الكلمة الأكثر أهمية في دورة حياة تطوير الأمان هي
"العملية" . يجب أن تفهم هذا قبل التفكير في شراء الأدوات.
مجرد دمج الأدوات في عملية DevOps لا يكفي - التفاعل والتفاهم بين المشاركين في العملية أمر مهم.
أكثر أهمية من الناس ، وليس الأدوات
غالبًا ما يبدأ التخطيط لعملية التطوير الآمن باختيار وشراء الأداة ، وينتهي بمحاولات لدمج الأداة في العملية الحالية ، والتي تظل محاولات. هذا يؤدي إلى عواقب محزنة ، لأن جميع الأدوات لها خصائصها وقيودها.
حالة شائعة عندما اختار قسم الأمن أداة جيدة ومكلفة ، مع ميزات رائعة ، وجاء للمطورين - لتضمينها في العملية. لكنها لا تنجح - حيث تم تنظيم العملية بحيث لا تتناسب قيود الأداة التي تم شراؤها بالفعل مع النموذج الحالي.
أولاً ، صف النتيجة التي تريدها وكيف ستبدو العملية. هذا سوف يساعد على فهم أدوار الأداة والسلامة في هذه العملية.
ابدأ بما هو مستخدم بالفعل
قبل شراء أدوات باهظة الثمن ، انظر إلى ما لديك بالفعل. كل شركة لديها متطلبات السلامة من أجل التنمية ، فهناك اختبارات ، ومخلفات - لماذا لا يتم تحويل كل هذا إلى شكل مفهوم ومريح للجميع؟
عادة ، متطلبات ورقة التلمود ، التي تقع على الرف. كانت هناك حالة عندما وصلنا إلى الشركة للاطلاع على العمليات ونطلب إظهار متطلبات الأمان للبرنامج. المتخصص الذي فعل هذا كان يبحث لفترة طويلة:
- الآن ، في مكان ما في الملاحظات كان هناك طريقة حيث تكمن هذه الوثيقة.نتيجة لذلك ، تلقينا المستند بعد أسبوع.
للمتطلبات والشيكات وغيرها ، قم بإنشاء صفحة ، على سبيل المثال ، على
Confluence - وهذا مناسب للجميع.
من الأسهل إعادة تهيئة ما هو موجود بالفعل واستخدامه للبدء.
استخدام أبطال الأمن
عادة ، في شركة متوسطة الحجم لمطوري 100-200 يعمل ضابط أمن واحد ، الذي يؤدي عدة وظائف ، وجسديا ليس لديه الوقت للتحقق من كل شيء. حتى لو بذل قصارى جهده ، فلن يقوم بمفرده بالتحقق من جميع الشفرات التي ينشئها التطوير. لمثل هذه الحالات ، تم تطوير مفهوم -
أبطال الأمن .
أبطال الأمن هو شخص داخل فريق التطوير مهتم بأمن منتجك.
يعتبر Security Champion نقطة الدخول لفريق التطوير وقد تم دمج كل من المبشر الأمني في واحدة.
عادة ، عندما تأتي الخزانة إلى فريق التطوير وتشير إلى وجود خطأ في الكود ، فإنها تتلقى إجابة مفاجئة:
"من أنت؟" أراك للمرة الأولى. أنا بخير - صديقي الكبير في مجموعة مراجعة الشفرة "قدم" ، نذهب إلى أبعد من ذلك!هذا موقف مثالي ، لأن هناك ثقة أكبر بكثير في كبار زملائه أو فقط في الفريق ، والذين يتفاعل معهم المطور باستمرار في العمل وفي مراجعة التعليمات البرمجية. إذا أشار "بطل الأمان" بدلاً من حارس الأمن إلى الخطأ والعواقب ، فستكون لكلمته أهمية أكبر.
أيضًا ، يعرف المطورون التعليمات البرمجية الخاصة بهم بشكل أفضل من أي موفر أمان. بالنسبة للشخص الذي لديه ما لا يقل عن 5 مشاريع في أداة التحليل الثابت ، يكون من الصعب عادة تذكر جميع الفروق الدقيقة. تعرف Security Champions على منتجها: ما الذي يتفاعل مع ماذا وما الذي يجب أن ننظر إليه في المقام الأول - فهي أكثر فعالية.
لذا فكر في تطبيق "أبطال الأمن" وتوسيع نطاق تأثير فريق الأمن. وهذا مفيد أيضًا للبطل نفسه: التطوير المهني في مجال جديد ، وتوسيع آفاقه التقنية ، وزيادة المهارات التقنية والإدارية والقيادية ، وزيادة القيمة السوقية. هذا عنصر من عناصر الهندسة الاجتماعية ، "عينيك" في فريق التطوير.
خطوات الاختبار
نموذج 20 إلى 80 يقول أن 20 ٪ من الجهد ينتج 80 ٪ من النتيجة. هذه 20 ٪ هي ممارسات تحليل التطبيق التي يمكن وينبغي أن يكون آليا. ومن الأمثلة على هذه الأنشطة التحليل الثابت -
SAST ، والتحليل الديناميكي -
DAST ، والتحكم في المصدر المفتوح . سوف أخبركم أكثر عن الأنشطة ، وكذلك عن الأدوات ، والميزات التي نواجهها عادة عند تقديمها في العملية ، وكيفية القيام بذلك بشكل صحيح.
المشاكل الرئيسية للأدوات
سأسلط الضوء على المشكلات ذات الصلة بجميع الأدوات التي تتطلب الاهتمام. سأحللهم بمزيد من التفاصيل حتى لا أكرر مرة أخرى.
تحليل وقت طويل. إذا استغرق الأمر 30 دقيقة لإكمال جميع الاختبارات والتجميع من الالتزام بالانتقال إلى المنتج ، فإن فحوصات أمن المعلومات ستستغرق يومًا. لذلك لا أحد سوف تبطئ العملية. النظر في هذه الميزة واستخلاص النتائج.
ارتفاع كاذبة سلبية أو إيجابية كاذبة. جميع المنتجات مختلفة ، الجميع يستخدم أطر عمل مختلفة وأسلوبهم الخاص في كتابة التعليمات البرمجية. على قواعد وتقنيات الكود المختلفة ، يمكن للأدوات إظهار مستويات مختلفة من الكاذبة السالبة والإيجابية الكاذبة. لذلك ، انظر بالضبط ما في شركتك والتطبيقات
الخاصة بك سوف تظهر نتيجة جيدة وموثوق بها.
لا التكامل مع الأدوات الحالية . انظر إلى الأدوات من حيث عمليات الدمج بحيث تستخدمها بالفعل. على سبيل المثال ، إذا كان لديك Jenkins أو TeamCity ، فتحقق من تكامل الأدوات مع هذا البرنامج ، وليس مع GitLab CI ، التي لا تستخدمها.
غياب أو التعقيد المفرط للتخصيص. إذا لم يكن للأداة واجهة برمجة تطبيقات ، فلماذا تكون هناك حاجة إليها؟ يجب الوصول إلى كل ما يمكن القيام به في الواجهة من خلال واجهة برمجة التطبيقات. من الناحية المثالية ، يجب أن يكون للأداة القدرة على تخصيص الشيكات.
لا تطوير منتجات خارطة الطريق. لا تقف التنمية ثابتة ، فنحن نستخدم دائمًا أطر عمل ووظائف جديدة ، ونعيد كتابة التعليمات البرمجية القديمة إلى لغات جديدة. نريد أن نتأكد من أن الأداة التي نشتريها ستدعم الأطر والتقنيات الجديدة. لذلك ، من المهم معرفة أن المنتج يحتوي على
خريطة طريق للتطوير الحقيقي والسليم.
ميزات العملية
بالإضافة إلى ميزات الأدوات ، فكر في ميزات عملية التطوير. على سبيل المثال ، التدخل في التنمية هو خطأ نموذجي. دعونا نرى الميزات الأخرى التي يجب مراعاتها وما الذي يجب على فريق الأمان الانتباه إليه.
من أجل عدم تعطيل تواريخ التطوير والإصدار ، قم بإنشاء
قواعد مختلفة
وسدادات عرض مختلفة - معايير لإيقاف عملية الإنشاء في وجود ثغرات أمنية -
لبيئات مختلفة . على سبيل المثال ، نحن نفهم أن الفرع الحالي يذهب إلى جناح التطوير أو UAT ، لذلك لا نتوقف ولا نقول:
- لديك نقاط ضعف هنا ، لن تذهب إلى أي مكان آخر!في هذه المرحلة ، من المهم إخبار المطورين بوجود مشكلات أمنية تستحق الاهتمام بها.
لا يمثل وجود الثغرات الأمنية عقبة أمام إجراء مزيد من الاختبارات : يدوي أو تكامل أو يدوي. من ناحية أخرى ، نحتاج إلى زيادة أمان المنتج بطريقة أو بأخرى ، حتى لا ينسى المطورون ما يجدون الأمان. لذلك ، في بعض الأحيان نقوم بذلك: في المنصة ، عندما ينتقل إلى بيئة التطوير ، فإننا ببساطة نعلم التطوير:
- الرجال ، لديك مشاكل ، يرجى الانتباه إليها.في مرحلة UAT ، نعرض مرة أخرى تحذيرات حول نقاط الضعف ، وفي مرحلة الخروج في حفلة موسيقية نقول:
- الرجال ، لقد حذرنا عدة مرات ، لم تفعل شيئًا - لن نسمح لك بذلك.إذا تحدثنا عن الكود والديناميكيات ، فمن الضروري إظهار الثغرات والتحذير منها فقط لتلك الميزات والكود الذي تم كتابته للتو في هذه الميزة. إذا قام المطور بتحريك الزر 3 بيكسلات وأخبرناه أن لديه حقن SQL هناك وبالتالي يحتاج إلى الإصلاح بشكل عاجل ، فهذا خطأ. انظر فقط إلى ما هو مكتوب الآن والتغيير الذي يأتي إلى التطبيق.
لنفترض أن لدينا عيبًا وظيفيًا معينًا - الطريقة التي يجب أن لا يعمل بها التطبيق: لا يتم تحويل الأموال ، عند النقر فوق الزر ، لا يوجد انتقال إلى الصفحة التالية أو عدم تحميل البضائع.
العيوب الأمنية هي نفس العيوب ، ولكن ليس في سياق التطبيق ، ولكن الأمن.
ليست كل مشكلات جودة البرامج هي مشكلات أمنية. لكن جميع مشكلات الأمان مرتبطة بجودة البرامج. شريف منصور ، اكسبيديا.
نظرًا لأن جميع الثغرات الأمنية هي نفس العيوب ، فيجب أن تكون موجودة في نفس المكان مثل جميع عيوب التطوير. حتى ننسى التقارير وملفات PDF مخيفة أن لا يقرأ أحد.
عندما عملت في شركة تطوير ، حصلت على تقرير من أدوات التحليل الثابتة. فتحته ، شعرت بالرعب وصنعت القهوة وألقت أوراقاً على 350 صفحة ، وأغلقتها وذهبت إلى العمل.
التقارير الكبيرة هي تقارير ميتة . عادةً ما لا يذهبون إلى أي مكان ، يتم حذف الرسائل أو نسيانها أو فقدها أو يقول النشاط التجاري إنه يتحمل المخاطر.
ما يجب القيام به نقوم فقط بتحويل العيوب المؤكدة التي وجدناها إلى شكل مناسب للتطوير ، على سبيل المثال ، نضيفها إلى الأعمال المتراكمة في Jira. نعطي الأولوية للتخلص من العيوب ونرتبها حسب الأولوية مع العيوب الوظيفية وعيوب الاختبار.
تحليل ثابت - SAST
هذا هو تحليل الكود الخاص بالثغرات
الأمنية ، لكنه ليس هو نفسه SonarQube. نتحقق ليس فقط من خلال الأنماط أو الأسلوب. في التحليل ، يتم استخدام عدد من الأساليب: في شجرة الضعف ، في
DataFlow ، في تحليل ملفات التكوين. هذا كله يرتبط مباشرة بالكود.
مزايا النهج :
تحديد الثغرات الموجودة في الكود في مرحلة مبكرة من التطوير ، عند عدم وجود منصات وأداة منتهية ،
وإمكانية المسح التدريجي : مسح قسم من الكود الذي تغير ، والميزة التي نقوم بها الآن فقط ، مما يقلل من وقت المسح.
سلبيات - وهذا هو عدم وجود دعم للغات اللازمة.
الدمجات الضرورية التي يجب أن تكون في الأدوات ، في رأيي الشخصي:
- أداة التكامل: جنكينز ، TeamCity و Gitlab CI.
- بيئة التطوير: Intellij IDEA ، Visual Studio. يعد الأمر أكثر ملاءمةً للمطوِّر ألا يصطدم بواجهة غير مفهومة لا تزال بحاجة إلى أن نتذكرها ، ولكن في مكان العمل في بيئة التطوير الخاصة به لرؤية جميع أوجه التكامل والتكامل الضرورية التي وجدها.
- مراجعة التعليمات البرمجية: SonarQube والمراجعة اليدوية.
- تتبع العيوب: جيرا و Bugzilla.
تظهر الصورة بعضًا من أفضل ممثلي التحليل الثابت.
إنها ليست الأدوات المهمة ، ولكن العملية ، لذلك هناك حلول مفتوحة المصدر مفيدة أيضًا لإدارة العملية.
لن يجد SAST Open Source عددًا كبيرًا من الثغرات أو DataFlow المعقدة ، ولكن يمكنك وينبغي عليك استخدامها عند إنشاء عملية. فهي تساعد على فهم كيفية بناء العملية ، ومن الذي سيستجيب للأخطاء ، ومن يقدم التقارير ، ومن يقدم التقارير. إذا كنت ترغب في تنفيذ المرحلة الأولى من بناء أمان الكود ، فاستخدم حلول Open Source.
كيف يمكن دمج هذا إذا كنت في بداية الطريق ، لا يوجد لديك شيء: لا CI ولا جنكينز ولا TeamCity؟ النظر في التكامل في هذه العملية.
السيرة الذاتية التكامل
إذا كان لديك Bitbucket أو GitLab ، فيمكنك القيام بالتكامل على مستوى
نظام إصدارات المتزامنة .
حسب الحدث - طلب السحب ، ارتكاب. يمكنك مسح الرمز وإظهاره في حالة البناء اجتاز اختبار الأمان أو فشل.
الاتصال بنا. بالطبع ، هناك حاجة دائما ردود الفعل. إذا قمت بالأداء على الجانب الأمني ، فضعه في صندوق ولم تخبره بأي شخص ، ثم ألقيت مجموعة من الأخطاء في نهاية الشهر - هذا ليس صحيحًا ولا جيدًا.
التكامل مع مراجعة الرمز
مرة واحدة ، في عدد من المشاريع المهمة ، نقوم بتعيين المراجع الافتراضي للمستخدم الفني AppSec. بناءً على ما إذا كان قد تم اكتشاف الأخطاء في الكود الجديد أو في حالة عدم وجود أخطاء ، يضع المراجع الحالة على "قبول" أو "بحاجة إلى عمل" بناءً على طلب السحب - إما أن يكون كل شيء على ما يرام ، أو تحتاج إلى الصقل والارتباطات لتحديد ما تريده تمامًا. للتكامل مع الإصدار الذي يذهب إلى prod ، تم تمكين حظر الدمج إذا لم يتم اجتياز اختبار IB. لقد قمنا بتضمين ذلك في مراجعة التعليمات البرمجية اليدوية ، وشهد المشاركون الآخرون في العملية حالات أمان لهذه العملية المحددة.
SonarQube التكامل
العديد من
بوابة الجودة لجودة الرمز. نفس الشيء هنا - يمكنك إنشاء نفس البوابات فقط لأدوات SAST. سيكون هناك نفس الواجهة ، نفس بوابة الجودة ، فقط سوف يطلق عليها
بوابة الأمن . وأيضًا ، إذا كانت لديك عملية باستخدام SonarQube ، يمكنك بسهولة دمج كل شيء هناك.
التكامل CI
هنا أيضًا ، كل شيء بسيط جدًا:
- في نفس المستوى مع الاختبارات الذاتية ، اختبارات الوحدة.
- فصل بمراحل التنمية : ديف ، اختبار ، همز. قد يتم تضمين مجموعات مختلفة من القواعد ، أو شروط فشل مختلفة: إيقاف التجميع ، لا توقف التجميع.
- بداية متزامن / غير متزامن . نحن ننتظر نهاية اختبار الأمان أو لا ننتظر. هذا هو ، أطلقناهم للتو والمضي قدمًا ، وبعد ذلك نتلقى حالة أن كل شيء جيد أو سيء.
كل شيء في عالم وردي مثالي. في الحياة الحقيقية ، هذا ليس كذلك ، لكننا نسعى جاهدين. يجب أن تكون نتيجة عمليات الفحص الأمني مشابهة لنتائج اختبارات الوحدة.
على سبيل المثال ، اتخذنا مشروعًا كبيرًا وقررنا الآن أن نقوم بمسحه ضوئيًا باستخدام SAST'om - OK. لقد دفعنا هذا المشروع إلى SAST ، لقد أعطانا 20.000 نقطة ضعف ، وبقرار قوي الإرادة ، قبلنا أن كل شيء على ما يرام. 20،000 نقاط الضعف هي واجبنا الفني. سنضع الديون في صندوق ، وسنشعل النار ببطء ونبدأ الأخطاء في أجهزة تتبع العيوب. نحن نؤجر شركة وننفذ كل شيء بأنفسنا أو سوف يساعدنا أبطال الأمن - وسوف ينخفض الدين الفني لدينا.
ويجب إصلاح جميع الثغرات الناشئة حديثًا في الكود الجديد وكذلك الأخطاء في الوحدة أو في الاختبارات التلقائية. من الناحية النسبية ، بدأ التجميع وانطلق بعيدًا وسقط اختباران واختباران أمنيان. حسنًا - لقد ذهبوا ، ونظروا إلى ما حدث ، وصححوا شيئًا واحدًا ، وصححوا الشيء الثاني ، وأخرجوه في المرة التالية - كل شيء على ما يرام ، ولم تكن هناك نقاط ضعف جديدة ، فشلت الاختبارات. إذا كانت هذه المهمة أعمق وكنت بحاجة إلى فهمها جيدًا ، أو أن إصلاح الثغرات الأمنية يؤثر على طبقات كبيرة مما يكمن تحت الغطاء: لقد جلبوا خللًا في متعقب العيوب ، حيث يتم تحديد أولوياته وثباته. لسوء الحظ ، فإن العالم ليس مثاليًا وتنجح الاختبارات في بعض الأحيان.
مثال على بوابة الأمن هو التناظرية لبوابة الجودة ، من خلال وجود وعدد من نقاط الضعف في التعليمات البرمجية.
نحن ندمج مع SonarQube - تم تثبيت البرنامج المساعد ، كل شيء مريح للغاية وبارد.
تكامل بيئة التطوير
قدرات التكامل:- بدء مسح ضوئي من بيئة التطوير قبل الالتزام.
- عرض النتائج.
- تحليل النتائج.
- التزامن مع الخادم.
يبدو وكأنه الحصول على نتائج من الخادم.
Intellij IDEA , , . ,
Flow Graph . , — - .
Open Source
. Open Source — , , ?
, , , , , , . Application Security — Open Source .
Open Source — OSA
.
. , , - ,
CVE - - , . , , , .
. , , , . , . , , . , , .
, . , . — , , . , , . Open Source , , -. , , . , . .
:, Open Source.
—
Dependency-Check OWASP. , , . , on-premise, . , , , , .
, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .
CI . , - : dev, test, prod. , , , - «critical» -, .
: Nexus JFrog.
. , , . , CVS.
CD. , — . .
Public Component Repositories — , . , trusted components. , . , , . , - , — .
- build' , , .
- trusted components.
- : war, jar, DL Docker- , .
- , : .
— DAST
, . . -, , , , : , , , , .
Open Source. DAST , Open Source , «» :
— , , ., , — .
, AppScan: , 3 — - ! , , AppScan — -, , ,
mailform -. :
— , ?! , !. , -, . — , .
, . 10-15 , , , , .
, .
Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .
:
.
mock-, — , .
, . — , , OpenSource, - , ,
Waf .
.
, , , , -.
. , , . , , . , .
API, , , , —
AppSec , .
, security- , , , , , . , , — Confluence , Jira -, / CI/CD.
Key Takeaways
. — . , , . — «» , — - high mega super critical, , .
— , . , , . DevSecOps, SecDevOps, .
, : , , , , . —
. —
.
.
, . , — . - , . , .
—
Security Champions .
, , , - — .
, . , community, , . , .
.- False Positive.
- تحليل الوقت المناسب.
- سهولة الاستخدام.
- توافر التكامل.
- فهم تطوير خارطة الطريق.
- القدرة على تخصيص الأدوات.
تم اختيار تقرير Yuri كواحد من أفضل التقارير في DevOpsConf 2018. للتعرف على الأفكار الأكثر إثارة والحالات العملية ، تعال إلى Skolkovo يومي 27 و 28 مايو في DevOpsConf كجزء من مهرجان RIT ++ . والأفضل من ذلك ، إذا كنت مستعدًا لمشاركة تجربتك ، فتقدم بطلب للحصول على تقرير بحلول 21 أبريل.