DevSecOps से डर और घृणा

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

स्रोत. जस्टिन रोइलैंड और डैन हार्मन द्वारा निर्मित पात्र।

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

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

एप्लिकेशन सुरक्षा: यह किस बारे में है?

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

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

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

कैनोनिकल एसडीएलसी विभिन्न पद्धतियों में अत्यधिक विस्तृत है - ओपनएसएएमएम, बीएसआईएमएम, ओडब्ल्यूएएसपी। पद्धतियाँ भिन्न हैं, लेकिन आम तौर पर समान हैं।

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

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

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

DevSecOps क्यों

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

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

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

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

DevSecOps में संक्रमण

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

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

लोग औजारों से अधिक महत्वपूर्ण हैं

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

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

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

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

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

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

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

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

आवश्यकताओं, जांच आदि के लिए एक पेज बनाएं, उदाहरण के लिए यहां संगम - यह हर किसी के लिए सुविधाजनक है.

जो पहले से मौजूद है उसे पुन: स्वरूपित करना और आरंभ करने के लिए उसका उपयोग करना आसान है।

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

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

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

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

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

- और आप कौन है? मैं तुम्हें पहली बार देख रहा हूं. मेरे साथ सब कुछ ठीक है - मेरे वरिष्ठ मित्र ने कोड समीक्षा पर "लागू करें" डाला, हम आगे बढ़ते हैं!

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

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

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

परीक्षण चरण

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

मुख्य उपकरण समस्याएँ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्थैतिक विश्लेषण - एसएएसटी

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

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

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

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

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

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

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

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

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

सीवीएस स्तर पर एकीकरण

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

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

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

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

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

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

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

सीआई स्तर पर एकीकरण

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

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

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

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

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

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

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

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

एकीकरण विकल्प:

• प्रतिबद्ध होने से पहले ही विकास परिवेश से स्कैन प्रारंभ करना।
• परिणाम दर्शन।
• परिणामों का विश्लेषण।
• सर्वर के साथ सिंक्रनाइज़ेशन.

सर्वर से परिणाम प्राप्त करना इस प्रकार दिखता है।

हमारे विकास परिवेश में इंटेलीज आईडिया यह सिर्फ एक अतिरिक्त आइटम प्रतीत होता है जो कहता है कि स्कैन के दौरान ऐसी कमजोरियाँ पाई गईं। आप तुरंत कोड को संपादित कर सकते हैं, सिफ़ारिशें देख सकते हैं और प्रवाह ग्राफ. यह सब डेवलपर के कार्यस्थल पर स्थित है, जो बहुत सुविधाजनक है - आपको बाकी लिंक का अनुसरण करने और कुछ अतिरिक्त देखने की आवश्यकता नहीं है।

मुक्त स्रोत

यह मेरा पसंदीदा विषय है. हर कोई ओपन सोर्स लाइब्रेरी का उपयोग करता है - जब आप एक तैयार लाइब्रेरी ले सकते हैं जिसमें सब कुछ पहले से ही लागू है, तो बैसाखी और साइकिल का एक गुच्छा क्यों लिखें?

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

ओपन सोर्स विश्लेषण - ओएसए

टूल में तीन प्रमुख चरण शामिल हैं।

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

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

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

विशेषताएं:

• विकास के विभिन्न चरणों के लिए अलग-अलग नीतियाँ।
• औद्योगिक वातावरण में घटकों की निगरानी करें।
• संगठन की रूपरेखा में पुस्तकालयों का नियंत्रण।
• विभिन्न निर्माण प्रणालियों और भाषाओं के लिए समर्थन।
• डॉकर छवियों का विश्लेषण।

क्षेत्र के नेताओं के कुछ उदाहरण जो ओपन सोर्स के विश्लेषण में लगे हुए हैं।

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

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

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

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

विरूपण साक्ष्य एकीकरण: नेक्सस और जेफ्रॉग।

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

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

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

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

गतिशील विश्लेषण - DAST

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

वही सिस्टम आपको ओपन सोर्स में टेम्पलेट कमजोरियों की जांच करने की अनुमति देता है। चूँकि DAST नहीं जानता कि हम किस ओपन सोर्स का उपयोग कर रहे हैं, यह बस "दुर्भावनापूर्ण" पैटर्न फेंकता है और सर्वर की प्रतिक्रियाओं का विश्लेषण करता है:

- हाँ, यहाँ एक अक्रमांकन समस्या है, लेकिन यहाँ नहीं।

इसमें बड़े जोखिम हैं, क्योंकि यदि आप इस सुरक्षा परीक्षण को उसी स्टैंड पर करते हैं जिसके साथ परीक्षक काम करते हैं, तो अप्रिय चीजें घटित हो सकती हैं।

• एप्लिकेशन सर्वर नेटवर्क पर उच्च लोड।
• कोई एकीकरण नहीं.
• विश्लेषित एप्लिकेशन की सेटिंग्स को बदलने की क्षमता।
• आवश्यक प्रौद्योगिकियों के लिए कोई समर्थन नहीं है.
• सेटिंग की कठिनाई.

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

“दोस्तों, क्या तुम मुझसे मज़ाक कर रहे हो?! हमने आपको हिसाब दिया, और आपने पक्ष रखा!

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

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

कुछ संसाधन जिनका हम आमतौर पर उपयोग करते हैं।

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

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

एकीकरण बहुत अच्छा और सरल है: सफल इंस्टालेशन के बाद स्कैन प्रारंभ करें स्टैंड पर आवेदन और सफल एकीकरण परीक्षण के बाद स्कैनिंग.

यदि एकीकरण काम नहीं करता है या स्टब्स और मॉक फ़ंक्शन हैं, तो यह अर्थहीन और बेकार है - चाहे हम कोई भी पैटर्न भेजें, सर्वर अभी भी उसी तरह प्रतिक्रिया देगा।

• आदर्श रूप से, एक अलग परीक्षण बेंच।
• परीक्षण से पहले, लॉगिन अनुक्रम लिख लें।
• प्रशासन प्रणाली का परीक्षण केवल मैनुअल है।

प्रक्रिया

सामान्यतः प्रक्रिया के बारे में और विशेष रूप से प्रत्येक उपकरण के कार्य के बारे में थोड़ा सामान्यीकृत। सभी एप्लिकेशन अलग-अलग हैं - एक गतिशील विश्लेषण के साथ बेहतर काम करता है, दूसरा स्थैतिक विश्लेषण के साथ, तीसरा ओपनसोर्स विश्लेषण, पेंटेस्ट, या सामान्य रूप से कुछ और, उदाहरण के लिए, घटनाओं के साथ waf.

हर प्रक्रिया को नियंत्रित करने की जरूरत है.

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

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

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

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

चाबी छीन लेना

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

उत्पाद की गुणवत्ता - साँझा उदेश्य सुरक्षा और विकास दोनों। हम एक काम करते हैं, हम यह सुनिश्चित करने का प्रयास करते हैं कि सब कुछ सही ढंग से काम करे और कोई प्रतिष्ठा जोखिम और वित्तीय नुकसान न हो। इसीलिए हम संचार स्थापित करने और उत्पाद को बेहतर बनाने के लिए DevSecOps, SecDevOps के दृष्टिकोण को बढ़ावा देते हैं।

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

आईएस दोषों और कार्यात्मक दोषों के बीच समान चिह्न.

सब कुछ स्वचालित करेंवह गतिशील है. कोई भी चीज़ जो चलती नहीं है, चलती है और स्वचालित होती है। यदि कुछ हाथ से किया जाता है, तो यह प्रक्रिया का अच्छा हिस्सा नहीं है। शायद इस पर पुनर्विचार करना और इसे स्वचालित करना भी उचित है।

यदि IB टीम का आकार छोटा है - सुरक्षा चैंपियंस का उपयोग करें.

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

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

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

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

स्रोत: www.habr.com