डर और लोथिंग DevSecOps

हमारे पास 2 कोड एनालाइज़र, डायनेमिक टेस्टिंग के लिए 4 टूल, हमारे खुद के शिल्प और 250 स्क्रिप्ट थे। वर्तमान प्रक्रिया में यह सब आवश्यक नहीं था, लेकिन जब से मैंने DevSecOps को लागू करना शुरू किया है, तब हमें अंत तक जाना चाहिए।



स्रोत । चरित्र लेखक: जस्टिन रॉयलैंड और डैन हार्मन।

SecDevOps क्या है? DevSecOps के बारे में क्या? अंतर क्या हैं? आवेदन सुरक्षा - यह किस बारे में है? क्लासिक दृष्टिकोण अब क्यों काम नहीं करता है? स्वोर्डफ़िश सिक्योरिटी के यूरी शबलिन इन सभी सवालों का जवाब जानते हैं । यूरी क्लासिक एप्लिकेशन सिक्योरिटी मॉडल से DevSecOps प्रक्रिया में संक्रमण की समस्याओं के बारे में विस्तार से सब कुछ का जवाब देगा: कैसे DevOps प्रक्रिया में सुरक्षित विकास प्रक्रिया के एम्बेडिंग से संपर्क करें और कुछ भी नहीं तोड़ें, सुरक्षा परीक्षण के मुख्य चरणों के माध्यम से कैसे जाएं, क्या उपकरण का उपयोग किया जा सकता है, क्या वे भिन्न हैं और कैसे नुकसान से बचने के लिए उन्हें सही तरीके से कॉन्फ़िगर करें।


वक्ता के बारे में: यूरी शबलिन - स्वॉर्डफ़िश सिक्योरिटी में मुख्य सुरक्षा वास्तुकार। वह एसएसडीएल के कार्यान्वयन के लिए जिम्मेदार है, एक ही विकास और परीक्षण पारिस्थितिकी तंत्र में अनुप्रयोग विश्लेषण उपकरणों के सामान्य एकीकरण के लिए। सूचना सुरक्षा में 7 साल का अनुभव। उन्होंने अल्फा बैंक, सर्बैंक और पॉजिटिव टेक्नोलॉजीज में काम किया, जो सॉफ्टवेयर विकसित करता है और सेवाएं प्रदान करता है। अंतरराष्ट्रीय सम्मेलनों के अध्यक्ष Zeronights, PHDays, RISSPA, OWASP।

आवेदन सुरक्षा: यह किस बारे में है?

एप्लीकेशन सिक्योरिटी वह सिक्योरिटी सेक्शन है जो एप्लीकेशन सिक्योरिटी के लिए जिम्मेदार होता है। यह बुनियादी ढांचे या नेटवर्क सुरक्षा पर लागू नहीं होता है, अर्थात्, हम क्या लिखते हैं और डेवलपर्स क्या काम कर रहे हैं - ये आवेदन की खामियां और कमजोरियां हैं।

एसडीएल या एसडीएलसी की दिशा - सुरक्षा विकास जीवनचक्र - माइक्रोसॉफ्ट द्वारा विकसित की गई थी। आरेख कैनोनिकल एसडीएलसी मॉडल को दर्शाता है, जिसका मुख्य कार्य विकास के प्रत्येक चरण में सुरक्षा की आवश्यकताओं, आवश्यकताओं से, उत्पादन में रिलीज़ और जारी करना है। माइक्रोसॉफ्ट ने महसूस किया कि प्रोम में बहुत अधिक कीड़े थे, उनमें से कुछ और कुछ करने की आवश्यकता थी, और उन्होंने इस दृष्टिकोण का प्रस्ताव दिया, जो विहित हो गया।



अनुप्रयोग सुरक्षा और SSDL का उद्देश्य कमजोरियों का पता लगाना नहीं है, जैसा कि आमतौर पर माना जाता है, लेकिन उनकी घटना को रोकने में। समय के साथ, माइक्रोसॉफ्ट से विहित दृष्टिकोण में सुधार हुआ, विकसित हुआ, और इसमें एक विस्तृत विस्तृत विसर्जन दिखाई दिया।



कैनोनिकल SDLC विभिन्न कार्यप्रणालियों में अत्यधिक विस्तृत है - OpenSAMM, BSIMM, OWASP। कार्यप्रणाली अलग हैं, लेकिन आम तौर पर समान हैं।

परिपक्वता मॉडल में भवन सुरक्षा

मुझे बीएसआईएम सबसे ज्यादा पसंद है - बिल्डिंग सिक्योरिटी इन मैच्योरिटी मॉडल । कार्यप्रणाली का आधार अनुप्रयोग सुरक्षा प्रक्रिया को 4 डोमेन में अलग करना है: शासन, खुफिया, एसएसडीएल टचप्वाइंट और तैनाती। प्रत्येक डोमेन में 12 अभ्यास होते हैं, जिन्हें 112 गतिविधियों के रूप में दर्शाया जाता है।



112 गतिविधियों में से प्रत्येक में 3 परिपक्वता स्तर हैं : प्राथमिक, मध्यवर्ती और उन्नत। सभी 12 प्रथाओं का अध्ययन वर्गों में किया जा सकता है, आपके लिए महत्वपूर्ण चीजों का चयन करें, समझें कि उन्हें कैसे लागू किया जाए और धीरे-धीरे तत्वों को जोड़ा जाए, उदाहरण के लिए, स्थिर और गतिशील कोड विश्लेषण या कोड समीक्षा। आप योजना को चित्रित करते हैं और चयनित गतिविधियों के कार्यान्वयन के भाग के रूप में उस पर शांति से काम करते हैं।

क्यों DevSecOps

DevOps एक सामान्य बड़ी प्रक्रिया है जिसमें आपको सुरक्षा का ध्यान रखने की आवश्यकता होती है।

शुरुआत में, DevOps में सुरक्षा जांच शामिल थी । व्यवहार में, सुरक्षा टीमों की संख्या अब की तुलना में बहुत कम थी, और उन्होंने इस प्रक्रिया में प्रतिभागियों के रूप में नहीं, बल्कि एक नियंत्रण और निरीक्षण निकाय के रूप में काम किया, जो आवश्यकताओं को निर्धारित करता है और रिलीज के अंत में उत्पाद की गुणवत्ता की जांच करता है। यह एक क्लासिक दृष्टिकोण है जिसमें सुरक्षा दल विकास से दीवार के पीछे थे और इस प्रक्रिया में शामिल नहीं थे।



मुख्य समस्या यह है कि सूचना सुरक्षा विकास से अलग है। आमतौर पर यह एक तरह का आईबी सर्किट होता है और इसमें 2-3 बड़े और महंगे उपकरण होते हैं। हर छह महीने में एक बार सोर्स कोड या एप्लिकेशन आता है, जिसे चेक करने की जरूरत होती है, और साल में एक बार पेंट्स का उत्पादन किया जाता है। यह सब इस तथ्य की ओर जाता है कि प्रोम में प्रवेश करने की समय सीमा को स्थगित कर दिया गया है, और स्वचालित टूल से बड़ी संख्या में कमजोरियां डेवलपर पर पड़ती हैं। यह सब असंतुष्ट और मरम्मत नहीं किया जा सकता है, क्योंकि पिछले छह महीनों के परिणामों को हल नहीं किया गया है, और यहां एक नया बैच है।

हमारी कंपनी की प्रक्रिया में, हम देखते हैं कि सभी क्षेत्रों और उद्योगों में सुरक्षा समझती है कि यह अपने आप को खींचने और एक पहिया में विकास के साथ स्पिन करने का समय है - एजाइल में । DevSecOps प्रतिमान चुस्त विकास पद्धति पर अच्छी तरह से लागू होता है, प्रत्येक रिलीज और पुनरावृत्ति में कार्यान्वयन, समर्थन और भागीदारी पर।

DevSecOps को संक्रमण

सुरक्षा विकास जीवनचक्र में सबसे महत्वपूर्ण शब्द "प्रक्रिया" है । उपकरण खरीदने के बारे में सोचने से पहले आपको यह समझना चाहिए।

बस DevOps प्रक्रिया में उपकरण शामिल करना पर्याप्त नहीं है - प्रक्रिया प्रतिभागियों के बीच बातचीत और समझ महत्वपूर्ण है।

लोगों से ज्यादा महत्वपूर्ण, औजार नहीं

अक्सर, एक सुरक्षित विकास प्रक्रिया की योजना एक उपकरण के चयन और खरीद से शुरू होती है, और उपकरण को वर्तमान प्रक्रिया में एकीकृत करने के प्रयासों के साथ समाप्त होती है, जो प्रयास रहते हैं। यह दुखद परिणाम की ओर जाता है, क्योंकि सभी उपकरणों की अपनी विशेषताओं और सीमाएं हैं।

एक सामान्य मामला जब सुरक्षा विभाग ने एक अच्छा, महँगा उपकरण चुना, जिसमें शानदार फीचर्स थे, और डेवलपर्स के लिए आया था - प्रक्रिया में एम्बेड करने के लिए। लेकिन यह काम नहीं करता है - यह प्रक्रिया संरचित है ताकि पहले से खरीदे गए टूल की सीमाएं वर्तमान प्रतिमान में फिट न हों।

पहले, वर्णन करें कि आपको क्या परिणाम चाहिए और प्रक्रिया कैसे दिखेगी। यह प्रक्रिया में उपकरण और सुरक्षा की भूमिकाओं को समझने में मदद करेगा।

जो पहले से उपयोग में है, उससे शुरुआत करें

महंगे उपकरण खरीदने से पहले, देखें कि आपके पास पहले से क्या है। प्रत्येक कंपनी के पास विकास की सुरक्षा आवश्यकताएं हैं, चेक, पेंटेस्ट हैं - यह सब को सभी के लिए एक समझने योग्य और सुविधाजनक रूप में क्यों नहीं तब्दील करता है?

आमतौर पर, आवश्यकताएँ एक कागज तलमुद हैं, जो एक शेल्फ पर स्थित है। एक मामला था जब हम प्रक्रियाओं को देखने के लिए कंपनी में आते हैं और सॉफ्टवेयर के लिए सुरक्षा आवश्यकताओं को दिखाने के लिए कहते हैं। ऐसा करने वाला विशेषज्ञ लंबे समय से देख रहा था:

- अब, कहीं न कहीं नोटों में एक ऐसा तरीका था जहां यह दस्तावेज़ निहित है।

परिणामस्वरूप, हमें एक सप्ताह बाद दस्तावेज़ प्राप्त हुआ।

आवश्यकताओं, जांच और अन्य चीजों के लिए, एक पेज बनाएं, उदाहरण के लिए, कंफ्लुएंस पर - यह सभी के लिए सुविधाजनक है।

पहले से ही जो कुछ है उसे सुधारना आसान है और इसे शुरू करने के लिए इसका उपयोग करें।

सुरक्षा चैंपियनों का उपयोग करें

आमतौर पर, 100-200 डेवलपर्स के लिए एक मध्यम आकार की कंपनी में एक सुरक्षा अधिकारी काम करता है, जो कई कार्य करता है, और शारीरिक रूप से सब कुछ जांचने का समय नहीं होता है। यहां तक ​​कि अगर वह अपनी पूरी कोशिश करता है, तो वह अकेले उन सभी कोड की जांच नहीं करेगा जो विकास उत्पन्न करता है। ऐसे मामलों के लिए, एक अवधारणा विकसित की गई है - सुरक्षा चैंपियंस ।

सुरक्षा चैंपियंस विकास टीम के भीतर एक व्यक्ति है जो आपके उत्पाद की सुरक्षा में रुचि रखता है।

सुरक्षा चैंपियन विकास टीम के लिए प्रवेश बिंदु है और सुरक्षा इंजीलवादी सभी एक में लुढ़का।

आमतौर पर, जब एक सुरक्षित विकास टीम में आता है और कोड में एक त्रुटि को इंगित करता है, तो यह एक आश्चर्यचकित उत्तर प्राप्त करता है:

"आप कौन हैं?" मैं तुम्हें पहली बार देख रहा हूं। मैं ठीक कर रहा हूँ - कोड समीक्षा सेट पर मेरे वरिष्ठ मित्र "लागू करें", हम और आगे जाते हैं!

यह एक विशिष्ट स्थिति है, क्योंकि वरिष्ठ या सिर्फ टीम के साथियों में बहुत अधिक भरोसा है, जिनके साथ डेवलपर लगातार काम और कोड समीक्षा में बातचीत करता है। यदि, सुरक्षा गार्ड के बजाय, सुरक्षा चैंपियन गलती और परिणाम का संकेत देता है, तो उसके शब्द का वजन अधिक होगा।

साथ ही, डेवलपर्स किसी भी सुरक्षा प्रदाता की तुलना में अपने कोड को बेहतर जानते हैं। एक ऐसे व्यक्ति के लिए जिसके पास स्थैतिक विश्लेषण उपकरण में कम से कम 5 परियोजनाएं हैं, आमतौर पर सभी बारीकियों को याद रखना मुश्किल है। सुरक्षा चैंपियंस अपने उत्पाद को जानते हैं: पहली जगह में क्या और क्या देखना है, इसके साथ क्या बातचीत करता है - वे अधिक प्रभावी हैं।

इसलिए सुरक्षा चैंपियनों को लागू करने और सुरक्षा टीम के प्रभाव का विस्तार करने के बारे में सोचें। स्वयं चैंपियन के लिए, यह भी उपयोगी है: एक नए क्षेत्र में व्यावसायिक विकास, तकनीकी क्षितिज का विस्तार, तकनीकी, प्रबंधकीय और नेतृत्व कौशल को पंप करना, बाजार मूल्य में वृद्धि करना। यह सोशल इंजीनियरिंग के कुछ तत्व हैं, विकास टीम में आपकी "आँखें"।

परीक्षण कदम

20 से 80 प्रतिमान कहते हैं कि 20% प्रयास 80% परिणाम उत्पन्न करता है। ये 20% अनुप्रयोग विश्लेषण प्रथाएं हैं जिन्हें स्वचालित किया जाना चाहिए। ऐसी गतिविधियों के उदाहरण स्थैतिक विश्लेषण हैं - SAST , डायनेमिक विश्लेषण - DAST और ओपन सोर्स नियंत्रण । मैं आपको गतिविधियों के बारे में और साथ ही टूल के बारे में अधिक बताऊंगा, कि हम आम तौर पर इस प्रक्रिया में पेश किए जाने पर कौन-सी सुविधाओं का सामना करते हैं, और इसे सही तरीके से कैसे करें

साधनों की मुख्य समस्याएँ

मैं उन समस्याओं को उजागर करूंगा जो सभी उपकरणों के लिए प्रासंगिक हैं जिन पर ध्यान देने की आवश्यकता है। मैं उन्हें और अधिक विस्तार से विश्लेषण करूंगा ताकि आगे दोहराना न पड़े।

लंबे समय का विश्लेषण। यदि सभी परीक्षणों और विधानसभा को ठिकानों पर जाने से पूरा करने में 30 मिनट लगते हैं, तो सूचना सुरक्षा जांच में एक दिन लगेगा। तो कोई भी इस प्रक्रिया को धीमा नहीं करेगा। इस विशेषता पर विचार करें और निष्कर्ष निकालें।

उच्च झूठी नकारात्मक या झूठी सकारात्मक। सभी उत्पाद अलग-अलग हैं, हर कोई कोड लिखने की अपनी अलग शैली और अपनी शैली का उपयोग करता है। विभिन्न कोड आधारों और प्रौद्योगिकियों पर, उपकरण भिन्न स्तर के झूठे नकारात्मक और गलत सकारात्मक दिखा सकते हैं। इसलिए, देखें कि आपकी कंपनी में क्या है और आपके अनुप्रयोगों के लिए एक अच्छा और विश्वसनीय परिणाम दिखाई देगा।

मौजूदा उपकरणों के साथ कोई एकीकरण नहीं । एकीकरण के संदर्भ में टूल देखें ताकि आप पहले से ही उपयोग कर रहे हैं। उदाहरण के लिए, यदि आपके पास जेनकिंस या टीमसिटी है, तो इस सॉफ़्टवेयर के साथ उपकरणों के एकीकरण की जांच करें, न कि गिटलैब सीआई के साथ, जिसका आप उपयोग नहीं करते हैं।

अनुकूलन की अनुपस्थिति या अत्यधिक जटिलता। यदि उपकरण में एपीआई नहीं है, तो इसकी आवश्यकता क्यों है? इंटरफ़ेस में जो कुछ भी किया जा सकता है वह एपीआई के माध्यम से सुलभ होना चाहिए। आदर्श रूप से, उपकरण में चेक को अनुकूलित करने की क्षमता होनी चाहिए।

कोई रोडमैप उत्पाद विकास नहीं। विकास अभी भी खड़ा नहीं है, हम हमेशा नए ढांचे और कार्यों का उपयोग करते हैं, पुराने कोड को नई भाषाओं में फिर से लिखते हैं। हम यह सुनिश्चित करना चाहते हैं कि जो उपकरण हम खरीदेंगे वह नए ढांचे और प्रौद्योगिकियों का समर्थन करेगा। इसलिए, यह जानना महत्वपूर्ण है कि उत्पाद का वास्तविक और उचित विकास रोडमैप है ।

प्रक्रिया सुविधाएँ

उपकरणों की सुविधाओं के अलावा, विकास प्रक्रिया की सुविधाओं पर विचार करें। उदाहरण के लिए, विकास में हस्तक्षेप करना एक सामान्य गलती है। आइए देखें कि अन्य विशेषताओं पर क्या विचार किया जाना चाहिए और सुरक्षा टीम को किस पर ध्यान देना चाहिए।

विकास को बाधित करने और तारीखों को जारी नहीं करने के लिए, विभिन्न नियमों और विभिन्न शो स्टॉपर बनाएं - कमजोरियों की उपस्थिति में निर्माण प्रक्रिया को रोकने के लिए मानदंड - विभिन्न वातावरणों के लिए । उदाहरण के लिए, हम समझते हैं कि वर्तमान शाखा विकास स्टैंड या यूएटी में जाती है, इसलिए हम नहीं रुकते हैं और यह नहीं कहते हैं:

- आपकी यहां कमजोरियां हैं, आप कहीं और नहीं जाएंगे!

इस बिंदु पर, डेवलपर्स को यह बताना महत्वपूर्ण है कि सुरक्षा मुद्दों पर ध्यान देने योग्य हैं।

कमजोरियों की उपस्थिति आगे के परीक्षण के लिए एक बाधा नहीं है : मैनुअल, एकीकरण, या मैनुअल। दूसरी ओर, हमें किसी तरह उत्पाद की सुरक्षा बढ़ाने की आवश्यकता है, और इसलिए कि डेवलपर्स सुरक्षा के बारे में नहीं भूलते हैं। इसलिए, कभी-कभी हम ऐसा करते हैं: स्टैंड पर, जब यह विकास के माहौल से बाहर निकलता है, हम बस विकास को सूचित करते हैं:

- दोस्तों, आपको समस्याएं हैं, कृपया उन पर ध्यान दें।

यूएटी चरण में, हम फिर से कमजोरियों के बारे में चेतावनी देते हैं, और प्रोम में बाहर निकलने के चरण में हम कहते हैं:

- दोस्तों, हमने कई बार चेतावनी दी है, आपने कुछ नहीं किया - हमने आपको इससे बाहर नहीं निकलने दिया।

यदि हम कोड और गतिशीलता के बारे में बात करते हैं, तो केवल उन विशेषताओं और कोड के कमजोरियों के बारे में दिखाना और चेतावनी देना आवश्यक है जो अभी इस सुविधा में लिखे गए थे। यदि डेवलपर ने बटन 3 पिक्सेल स्थानांतरित किया है और हम उसे बताते हैं कि उसके पास वहां SQL इंजेक्शन है और इसलिए तत्काल इसे ठीक करने की आवश्यकता है, यह गलत है। केवल वही देखें जो अभी लिखा गया है और जो परिवर्तन अनुप्रयोग में आता है।

मान लें कि हमारे पास एक निश्चित कार्यात्मक दोष है - जिस तरह से एप्लिकेशन को काम नहीं करना चाहिए: धन हस्तांतरित नहीं किया जाता है, जब आप बटन पर क्लिक करते हैं, तो अगले पृष्ठ पर कोई संक्रमण नहीं होता है या माल लोड नहीं होता है। सुरक्षा दोष समान दोष हैं, लेकिन आवेदन के संदर्भ में नहीं, बल्कि सुरक्षा।

सभी सॉफ्टवेयर गुणवत्ता मुद्दे सुरक्षा मुद्दे नहीं हैं। लेकिन सभी सुरक्षा मुद्दे सॉफ्टवेयर गुणवत्ता से संबंधित हैं। शेरिफ मंसूर, एक्सपीडिया।

चूंकि सभी कमजोरियां समान दोष हैं, उन्हें सभी विकास दोषों के समान स्थान पर स्थित होना चाहिए। तो रिपोर्ट और डरावने पीडीएफ के बारे में भूल जाओ जो कोई भी नहीं पढ़ता है।



जब मैंने एक विकास कंपनी के लिए काम किया, तो मुझे स्थैतिक विश्लेषण उपकरण से एक रिपोर्ट मिली। मैंने इसे खोला, भयभीत किया, कॉफी बनाई, 350 पन्नों के माध्यम से ली, इसे बंद कर दिया और आगे काम करने के लिए चला गया। बड़ी खबरें मृत खबरें हैं । आमतौर पर वे कहीं भी नहीं जाते हैं, पत्र हटा दिए जाते हैं, भूल जाते हैं, खो जाते हैं या व्यवसाय कहता है कि इसमें जोखिम है।

क्या करें? हम सिर्फ पुष्टि किए गए दोषों को बदल देते हैं, जो हमें विकास के लिए सुविधाजनक रूप में मिलते हैं, उदाहरण के लिए, उन्हें जीरा में बैकलॉग में जोड़ें। हम कार्यात्मक दोषों और परीक्षण दोषों के साथ प्राथमिकता के क्रम में दोषों को प्राथमिकता देते हैं और समाप्त करते हैं।

स्थैतिक विश्लेषण - SAST

यह कमजोरियों के लिए कोड विश्लेषण है , लेकिन यह सोनारक्यूब के समान नहीं है। हम न केवल पैटर्न या शैली द्वारा जाँच करते हैं। विश्लेषण में, कई तरीकों का उपयोग किया जाता है: भेद्यता वृक्ष में, डेटाफ़्लो में , कॉन्फ़िगरेशन फ़ाइलों के विश्लेषण में। यह सब सीधे कोड से संबंधित है।

दृष्टिकोण के लाभ : विकास के एक प्रारंभिक चरण में कोड में कमजोरियों की पहचान , जब कोई स्टैंड और एक तैयार उपकरण नहीं होता है, और वृद्धिशील स्कैनिंग की संभावना : कोड के एक खंड को स्कैन करना जो बदल गया है, और केवल वह सुविधा जो हम अभी कर रहे हैं, जो स्कैनिंग समय को कम करता है।

विपक्ष - यह आवश्यक भाषाओं के लिए समर्थन की कमी है।

मेरे विषय में राय में आवश्यक एकीकरण उपकरण में होना चाहिए:

• एकीकरण उपकरण: जेनकिंस, टीमसिटी और गिटलैब सीआई।
  
• विकास पर्यावरण: इंटेलीज आईडीईए, विजुअल स्टूडियो। यह डेवलपर के लिए एक सुविधाजनक इंटरफ़ेस में नहीं चढ़ने के लिए अधिक सुविधाजनक है जिसे अभी भी याद रखने की आवश्यकता है, लेकिन अपने स्वयं के विकास के वातावरण में कार्यस्थल पर सही सभी आवश्यक एकीकरण और कमजोरियों को देखने के लिए जो उसने पाया।
  
• कोड समीक्षा: सोनारक्यूब और मैनुअल समीक्षा।
  
• दोष ट्रैकर्स: जीरा और बुगज़िला।
  

चित्र स्थिर विश्लेषण के कुछ सर्वश्रेष्ठ प्रतिनिधियों को दर्शाता है।



यह ऐसे उपकरण नहीं हैं जो महत्वपूर्ण हैं, बल्कि प्रक्रिया है, इसलिए ओपन सोर्स समाधान हैं जो प्रक्रिया को चलाने के लिए भी अच्छे हैं।



SAST ओपन सोर्स को भारी संख्या में कमजोरियां या जटिल DataFlow नहीं मिलेगा, लेकिन प्रक्रिया बनाते समय आपको उनका उपयोग करना चाहिए और उनका उपयोग करना चाहिए। वे यह समझने में मदद करते हैं कि प्रक्रिया का निर्माण कैसे किया जाएगा, जो बग का जवाब देंगे, किसे रिपोर्ट करना है, किसे रिपोर्ट करना है। यदि आप अपने कोड की सुरक्षा के प्रारंभिक चरण को पूरा करना चाहते हैं, तो ओपन सोर्स समाधान का उपयोग करें।

यह कैसे एकीकृत किया जा सकता है यदि आप सड़क की शुरुआत में हैं, तो आपके पास कुछ भी नहीं है: न तो सीआई, न ही जेनकिंस, और न ही टीमसिटी? प्रक्रिया में एकीकरण पर विचार करें।

सीवीएस एकीकरण

यदि आपके पास Bitbucket या GitLab है, तो आप समवर्ती संस्करण सिस्टम स्तर पर एकीकरण कर सकते हैं।

घटना के अनुसार - अनुरोध करें, कमिट करें। आप कोड को स्कैन करते हैं और बिल्ड स्थिति में दिखाते हैं कि सुरक्षा जांच पास या विफल हो गई है।

हमसे संपर्क करें। बेशक, फीडबैक की हमेशा जरूरत होती है। यदि आपने बस सुरक्षा पक्ष में प्रदर्शन किया है, तो इसे एक बॉक्स में रखें और इसके बारे में किसी को न बताएं, और फिर महीने के अंत में बग का एक गुच्छा डंप किया - यह न तो सही है और न ही अच्छा है।

कोड समीक्षा के साथ एकीकरण

एक बार, कई महत्वपूर्ण परियोजनाओं में, हम AppSec तकनीकी उपयोगकर्ता का डिफ़ॉल्ट समीक्षक सेट करते हैं। नए कोड में त्रुटियों का पता लगाया गया था या कोई त्रुटि नहीं है, इसके आधार पर, समीक्षक पुल अनुरोध पर "स्वीकार" या "काम की जरूरत" पर स्थिति डालता है - या तो सब कुछ ठीक है, या आपको ठीक करने के लिए और लिंक करने की आवश्यकता है। ठेस पर जाने वाले संस्करण के साथ एकीकरण के लिए, हमने आईबी परीक्षण पास न होने पर सक्षम प्रतिबंध को मर्ज कर दिया था। हमने इसे मैन्युअल कोड समीक्षा में शामिल किया, और इस प्रक्रिया में अन्य प्रतिभागियों ने इस विशेष प्रक्रिया के लिए सुरक्षा स्थिति देखी।

सोनारक्यूब एकीकरण

कई कोड गुणवत्ता के लिए एक गुणवत्ता गेट है । यहाँ एक ही बात है - आप केवल फाटक उपकरण के लिए एक ही द्वार बना सकते हैं। एक ही इंटरफ़ेस होगा, एक ही गुणवत्ता वाला गेट, केवल इसे सुरक्षा द्वार कहा जाएगा। और यह भी, अगर आपके पास सोनारक्यूब का उपयोग करने की प्रक्रिया है, तो आप आसानी से वहां सब कुछ एकीकृत कर सकते हैं।

सीआई एकीकरण

यहाँ भी, सब कुछ काफी सरल है:

• ऑटोटेस्ट्स , यूनिट परीक्षणों के साथ समान स्तर पर ।
  
• विकास के चरणों द्वारा पृथक्करण : देव, परीक्षण, ठेस। नियमों के अलग-अलग सेट शामिल हो सकते हैं, या अलग-अलग विफल स्थितियां हो सकती हैं: विधानसभा को रोकें, विधानसभा को न रोकें।
  
• सिंक्रोनस / एसिंक्रोनस प्रारंभ । हम सुरक्षा परीक्षण की समाप्ति की प्रतीक्षा कर रहे हैं या प्रतीक्षा नहीं कर रहे हैं। यही है, हमने अभी उन्हें लॉन्च किया है और आगे बढ़ते हैं, और फिर हमें यह दर्जा प्राप्त होता है कि सब कुछ अच्छा है या बुरा।
  

यह एक संपूर्ण गुलाबी दुनिया में है। वास्तविक जीवन में, यह नहीं है, लेकिन हम प्रयास करते हैं। सुरक्षा जांच का परिणाम इकाई परीक्षणों के परिणामों के समान होना चाहिए।

उदाहरण के लिए, हमने एक बड़ी परियोजना ली और फैसला किया कि अब हम इसे SAST'om - OK के साथ स्कैन करेंगे। हमने इस परियोजना को एसएटीएस में बदल दिया, इसने हमें 20,000 कमजोरियां दीं, और एक मजबूत इरादों वाले फैसले के साथ, हमने स्वीकार किया कि सब कुछ ठीक है। 20,000 कमजोरियां हमारे तकनीकी कर्तव्य हैं। हम ऋण को एक बॉक्स में डाल देंगे, और हम धीरे-धीरे उठेंगे और दोष ट्रैकर्स में कीड़े शुरू कर देंगे। हम एक कंपनी को किराए पर लेते हैं, यह सब खुद करें या सुरक्षा चैंपियंस हमारी मदद करेंगे - और हमारा तकनीकी ऋण घट जाएगा।

और नए कोड में सभी नई उभरती कमजोरियों के साथ-साथ यूनिट या ऑटोटेस्ट में त्रुटियों को ठीक किया जाना चाहिए। अपेक्षाकृत बोल, सभा शुरू हुई, दूर चली गई, दो परीक्षण और दो सुरक्षा परीक्षण नीचे गिर गए। ठीक है - वे गए, देखा कि क्या हुआ, एक चीज को ठीक किया, दूसरे को ठीक किया, अगली बार बाहर निकाल दिया - सब कुछ ठीक है, कोई नई कमजोरियां नहीं थीं, परीक्षण विफल नहीं हुए। यदि यह कार्य अधिक गहरा है और आपको इसे अच्छी तरह से समझने की आवश्यकता है, या कमजोरियों को ठीक करना हुड के नीचे झूठ की बड़ी परतों को प्रभावित करता है: वे दोष ट्रैकर में एक बग लाए, इसे प्राथमिकता और तय किया गया है। दुर्भाग्य से, दुनिया सही नहीं है और परीक्षण कभी-कभी विफल होते हैं।

सुरक्षा गेट का एक उदाहरण कोड में कमजोरियों की उपस्थिति और संख्या से, गुणवत्ता गेट का एक एनालॉग है।

हम सोनारक्यूब के साथ एकीकृत करते हैं - प्लगइन स्थापित है, सब कुछ बहुत सुविधाजनक और शांत है।

विकास पर्यावरण एकीकरण

एकीकरण क्षमताओं:

• प्रतिबद्ध होने से पहले विकास के माहौल से एक स्कैन शुरू करना।
  
• परिणाम देखें।
  
• परिणामों का विश्लेषण।
  
• सर्वर के साथ सिंक्रनाइज़ेशन।
  

यह सर्वर से परिणाम प्राप्त करने जैसा कुछ दिखता है।



Intellij IDEA , , . , Flow Graph . , — - .

Open Source

. Open Source — , , ?



, , , , , , . Application Security — Open Source .

Open Source — OSA

.

. , , - , CVE - - , . , , , .

. , , , . , . , , . , , .

, . , . — , , . , , . Open Source , , -. , , . , . .

:

• .
  
• .
  
• .
  
• .
  
• Docker-.
  

, 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 .

, , , - — . अपनी प्रक्रिया की आवश्यकताओं के आधार पर उपकरण चुनें । यह मत देखो कि समुदाय क्या कहता है कि यह उपकरण खराब है और यह अच्छा है। शायद यह आपके उत्पाद पर सटीक विपरीत है।

उपकरण आवश्यकताएँ।

• कम झूठी सकारात्मक।
  
• पर्याप्त विश्लेषण समय।
  
• उपयोग में आसानी।
  
• एकीकरण की उपलब्धता।
  
• रोडमैप उत्पाद विकास को समझना।
  
• उपकरणों को अनुकूलित करने की क्षमता।
  

यूरी की रिपोर्ट को DevOpsConf 2018 में सर्वश्रेष्ठ के रूप में चुना गया था। इससे भी अधिक दिलचस्प विचारों और व्यावहारिक मामलों से परिचित होने के लिए, RIT ++ उत्सव के भाग के रूप में 27 और 28 मई को DevOpsConf में स्कोलोवो में आएं । बेहतर अभी तक, यदि आप अपना अनुभव साझा करने के लिए तैयार हैं, तो 21 अप्रैल तक रिपोर्ट के लिए आवेदन करें ।