एक DevOps पाइपलाइन को DevSecOps पाइपलाइन में कैसे बदलें: एक शिफ्ट लेफ्ट कॉन्सेप्ट अवलोकन

नमस्ते, हैकरनून! मेरा नाम सोफिया है, और मैं एक DevOps/क्लाउड इंजीनियर हूं। मैंने HackerNoon और Aptible की प्रतियोगिता में भाग लेने का निर्णय लिया।

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

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

लेफ्ट कॉन्सेप्ट को शिफ्ट करें

DevSecOps पद्धति का मुख्य लक्ष्य DevOps पाइपलाइनों में, यानी सॉफ़्टवेयर विकास प्रक्रिया में स्वचालित सुरक्षा जांच शुरू करना है।

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

नीचे दी गई छवि पर एक नज़र डालें। आप देख सकते हैं कि त्रुटि सुधार की लागत प्रत्येक चरण के साथ बढ़ती जाती है।

विकास और कार्यात्मक परीक्षण के दौरान पाए गए सुरक्षा मुद्दों को ठीक करने में लगभग कुछ भी खर्च नहीं होता है। स्रोत कोड में सभी आवश्यक परिवर्तन तुरंत किए जा सकते हैं और पुनः जाँच के लिए भेजे जा सकते हैं।

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

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

परिनियोजन चरण में पाई गई सुरक्षा समस्याओं से उपयोगकर्ता डेटा लीक हो सकता है। कंपनी को लाखों डॉलर का जुर्माना और उसकी प्रतिष्ठा को नुकसान हो सकता है, जिसका अर्थ है कि एक गलती की कीमत सैकड़ों गुना बढ़ जाती है।

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

DevSecOps पाइपलाइन संरचना

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

ऊपर दी गई छवि सुरक्षा जांच के सभी मुख्य चरणों के साथ DevSecOps पाइपलाइन संरचना को दिखाती है। उनमें से प्रत्येक के बारे में यहां कुछ शब्द दिए गए हैं:

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

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

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

• परीक्षण समय। इसका तात्पर्य एकत्रित आर्टिफैक्ट से चलने वाले एप्लिकेशन की सुरक्षा का परीक्षण करना है। इस चरण में उपकरण हमलावरों के कार्यों का अनुकरण करके एप्लिकेशन को "तोड़ने" का प्रयास करते हैं।

• तैनाती के बाद. इसका तात्पर्य किसी एप्लिकेशन को उत्पादन परिवेश में तैनात करने के बाद उसकी सुरक्षा की जाँच करना है। उपकरण वास्तविक समय में ज्ञात कमजोरियों की खुली रजिस्ट्रियों की निगरानी करते हैं और एप्लिकेशन के लिए खतरा पता चलने पर सूचित करते हैं।

आगे, आइए इस पर करीब से नज़र डालें कि ये जाँचें क्या हैं और इन्हें करने के लिए किन उपकरणों का उपयोग किया जाता है।

पूर्व-प्रतिबद्ध जाँचें

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

यह जाँच उस स्थिति से बचाती है जब अनियंत्रित कोड, उदाहरण के लिए, अनएन्क्रिप्टेड रहस्यों के साथ, रिपॉजिटरी में आ जाता है।

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

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

प्री-कमिट जांच के लिए उपकरण

प्री-कमिट चेक सेट करने के लिए कई ओपन-सोर्स टूल का उपयोग किया जा सकता है:

1. गिटलीक्स
2. गिट-रहस्य
3. ट्रिवी सीक्रेट स्कैनिंग
4. फुसफुसाते
5. गिट-सभी रहस्य
6. रहस्य का पता लगाएं
7. गड़बड़ लीक

प्री-कमिट जांच के लिए ये बेहतरीन उपकरण हैं।

निर्माण-पूर्व जाँचें

प्री-बिल्ड चरण में, व्हाइट बॉक्स परीक्षण किया जाता है। इन जाँचों का उपयोग पिछले चरण की तरह, स्रोत कोड का विश्लेषण करने के लिए किया जाता है। इस मामले में, एप्लिकेशन एक "व्हाइट बॉक्स" है क्योंकि हम इसकी वास्तुकला और आंतरिक संरचना को जानते और समझते हैं।

प्री-बिल्ड चेक कई प्रकार के होते हैं:

• गुप्त जांच
• स्थैतिक अनुप्रयोग सुरक्षा परीक्षण (SAST)
• सॉफ़्टवेयर संरचना विश्लेषण (एससीए)

अब आइए उन पर विस्तार से चर्चा करें।

प्री-बिल्ड सीक्रेट डिटेक्शन चेक

सीक्रेट डिटेक्शन एक स्वचालित जांच है जो अनएन्क्रिप्टेड संवेदनशील जानकारी का पता लगाती है: स्रोत कोड में अनएन्क्रिप्टेड रहस्य जो एक संस्करण नियंत्रण प्रणाली में प्रवेश कर चुके हैं।

स्रोत कोड के संस्करण नियंत्रण प्रणाली के भंडार में प्रवेश करने के बाद प्री-बिल्ड जांच की जाती है। इसलिए, स्टोरेज में सभी अनएन्क्रिप्टेड संवेदनशील डेटा को संभावित रूप से हमलावरों द्वारा एक्सेस किया जा सकता है, उदाहरण के लिए, यदि रिपॉजिटरी की सामग्री लीक हो जाती है।

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

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

गुप्त जांच के लिए उपकरण

गुप्त जांच का उपयोग करके कॉन्फ़िगर किया जा सकता है गिटलीक्स , गिट-रहस्य , या रहस्य का पता लगाएं . हालाँकि, प्रसिद्ध सीआई/सीडी प्लेटफार्मों द्वारा प्रदान की गई सेवाओं का उपयोग करना सबसे अच्छा है, उदाहरण के लिए, GitLab गुप्त जांच .

प्री-बिल्ड SAST चेक

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

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

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

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

एसएएसटी उपकरण

मालिकाना समाधान:

• सोनारक्यूब ई
• चेकमार्क्स एसएएसटी
• सोलर ऐपस्क्रीनर

निःशुल्क समाधान GitLab SAST है।

प्री-बिल्ड सोर्स एससीए चेक

सॉफ़्टवेयर संरचना विश्लेषण (एससीए) एक पद्धति है जो अनुप्रयोगों को उनके ओपन-सोर्स घटकों का विश्लेषण करके सुरक्षित करती है।

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

स्रोत एससीए स्रोत कोड का विश्लेषण करता है और, विशेष रूप से, स्रोत कोड में परिभाषित एप्लिकेशन निर्भरता का विश्लेषण करता है। इस विश्लेषण को अक्सर निर्भरता स्कैनिंग के रूप में जाना जाता है।

एससीए आपको उस समस्या का पता लगाने की अनुमति देता है जहां एक घटक में भेद्यता सभी अनुप्रयोगों में सुरक्षा समस्याएं पैदा कर सकती है।

एक अच्छा उदाहरण है लॉग4शेल . इस भेद्यता को 2021 के अंत में एक लोकप्रिय जावा लॉगिंग फ्रेमवर्क Log4j में खोजा गया था। यह सबसे भयावह कमजोरियों में से एक बन गई क्योंकि इसने हमलावरों को करोड़ों उपकरणों पर मनमाना जावा कोड निष्पादित करने की अनुमति दी।

एससीए उपकरण

तुच्छ एक ओपन-सोर्स समाधान है.

मुफ़्त मूल्य निर्धारण योजनाओं के साथ वाणिज्यिक समाधान:

• गढ़ा
• एससीए को ठीक करें

GitLab के भाग के रूप में (केवल अल्टीमेट-संस्करण में उपलब्ध), आप इसका उपयोग कर सकते हैं GitLab निर्भरता स्कैनिंग .

पोस्ट-बिल्ड चेक: बाइनरी एससीए

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

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

डॉकर छवियों के साथ काम करते समय कुछ रोमांचक विशेषताएं हैं। बाइनरी एससीए विश्लेषक डॉकर छवियों की परतों की जांच करते हैं और उन्हें सार्वजनिक भेद्यता डेटाबेस जैसे हैश रकम के रूप में ढूंढते हैं राष्ट्रीय भेद्यता डेटाबेस (एनवीडी) या स्निक भेद्यता डीबी .

कुछ विश्लेषक न केवल कमजोर घटकों को ढूंढ सकते हैं, बल्कि उन्हें ठीक करने का सुझाव भी दे सकते हैं, उदाहरण के लिए, पहले से तय भेद्यता वाले घटक के न्यूनतम आवश्यक संस्करण को निर्दिष्ट करके।

लोकप्रिय बाइनरी एससीए विश्लेषकों के उदाहरण

निःशुल्क समाधान है GitLab कंटेनर स्कैनिंग ।

मुक्त स्रोत समाधान:

• सामान्य ज्ञान
• क्लैर
• अंगूर
• घाट
• जेफ्रॉग एक्सरे
• डॉकर हब

अंतर्निर्मित विश्लेषक के साथ डॉकर रजिस्ट्री - बंदरगाह .

टेस्ट-टाइम चेक: DAST, IAST, और OAST

इस स्तर पर, गतिशील ग्रे बॉक्स परीक्षण और ब्लैक बॉक्स परीक्षण किया जाता है। जब एप्लिकेशन की आंतरिक संरचना आंशिक रूप से या पूरी तरह से अज्ञात होती है, तो ये सुरक्षा जांच एक हमलावर के कार्यों का अनुकरण करके की जाती है जो कमजोरियों का पता लगाता है और उनका फायदा उठाकर एप्लिकेशन को "तोड़ने" की कोशिश करता है। आइए उनमें से प्रत्येक पर संक्षेप में चर्चा करें: DAST, IAST, और OAST।

टेस्ट-टाइम DAST चेक

DAST स्कैनर विभिन्न कमजोरियों के माध्यम से बाहरी हमलों का अनुकरण करके स्वचालित रूप से अनुप्रयोगों का परीक्षण करते हैं। एप्लिकेशन विश्लेषक के लिए एक ब्लैक बॉक्स है; इसके बारे में कुछ भी पता नहीं है.

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

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

उस स्थिति में, DAST स्कैनर क्लाइंट (विश्लेषक) और सर्वर (एप्लिकेशन इंस्टेंस) के बीच ट्रैफ़िक एन्क्रिप्शन की कमी से संबंधित कुछ त्रुटियाँ उत्पन्न करेगा।

DAST टूल्स के उदाहरण

उपकरण जो आपके ध्यान देने योग्य हैं:

• गिटलैब DAST - केवल अंतिम संस्करण में उपलब्ध है
• OWASP जेड अटैक प्रॉक्सी (ZAP) — एक ओपन-सोर्स समाधान, जिसका उपयोग GitLab DAST में भी किया जाता है
• एक्यूनेटिक्स
• वेबइंस्पेक्ट को मजबूत करें
• एचसीएल सुरक्षा ऐपस्कैन
• सारांश प्रबंधित DAST
• Tenable.io (वेब ऐप स्कैनिंग)
• वेराकोड गतिशील विश्लेषण

बढ़िया, आगे बढ़ें.

टेस्ट-टाइम आईएएसटी चेक

IAST (इंटरएक्टिव एप्लिकेशन सिक्योरिटी टेस्टिंग) एक ग्रे बॉक्स टेस्टिंग है जो व्हाइट बॉक्स टेस्टिंग SAST और ब्लैक बॉक्स टेस्टिंग DAST के फायदे और ताकत को जोड़ती है।

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

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

इसका मतलब यह है कि IAST समाधान उस प्रोग्रामिंग भाषा को समझने में सक्षम होना चाहिए जिसमें एप्लिकेशन लिखा गया है। यह ध्यान दिया जाना चाहिए कि किसी विशेष IAST समाधान के लिए समर्थन कुछ भाषाओं के लिए दूसरों की तुलना में बेहतर ढंग से कार्यान्वित किया जा सकता है।

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

इसके अलावा, विश्लेषण प्रक्रिया स्वयं कोड को स्कैन नहीं करती है बल्कि केवल उन अंशों की जांच करती है जिन्हें सीधे निष्पादित किया जाता है। इसलिए, IAST विश्लेषण को कार्यात्मक परीक्षण के साथ सबसे अच्छा जोड़ा जाता है जब आप यथासंभव अधिक से अधिक एप्लिकेशन परिदृश्यों का परीक्षण कर सकते हैं।

आईएएसटी टूल्स के उदाहरण

यहां आपके लिए बेहतरीन उपकरण हैं:

• सारांश साधक
• वेराकोड इंटरएक्टिव विश्लेषण
• माइक्रोफोकस फोर्टिफाई वेबइंस्पेक्ट
• चेकमार्क्स CxIAST
• कंट्रास्ट आकलन
• एचडीआईवी डिटेक्शन (आईएएसटी)

बढ़िया, आगे बढ़ें.

परीक्षण-समय OAST जाँच

OAST (आउट-ऑफ-बैंड एप्लिकेशन सिक्योरिटी टेस्टिंग) द्वारा विकसित एक तकनीक है पोर्टस्विगर और DAST का एक विस्तार है जो उन कमजोरियों का पता लगाता है जिन्हें DAST नहीं देखता है, जैसे कि log4shell।

OAST टूल के उदाहरण

मैं आपको अनुशंसित करता हूं:

• बर्प सुइट
• OWASP जैप के साथ OAST प्लगइन
• ओएएसटी सेवाएं डींग , टुक टुक , और इंटरैक्ट करना

आगे बढ़ो।

तैनाती के बाद की जाँचें

एप्लिकेशन सुरक्षा और संचालन क्षमता सुनिश्चित करने के लिए यह एक आवश्यक चरण है। प्री-कमिट जांच के विपरीत, जो विकास चरण में की जाती है, पोस्ट-तैनाती जांच आपको प्राकृतिक वातावरण में एप्लिकेशन ऑपरेशन के दौरान पहले से ही संभावित समस्याओं की पहचान करने की अनुमति देती है।

कलाकृतियों की सुरक्षा की निगरानी करना

समय पर नई कमजोरियों का पता लगाने के लिए, किसी एप्लिकेशन को तैनात करने के बाद नियमित रूप से आर्टिफैक्ट जांच करना आवश्यक है।

यह विशेष रिपॉजिटरी या टूल का उपयोग करके किया जा सकता है, जैसे स्निक कंटेनर , ट्रिवी, गिटलैब कंटेनर स्कैनिंग, या अपना एकीकरण मॉड्यूल विकसित करना।

अनुप्रयोग सुरक्षा निगरानी

सुरक्षा सुनिश्चित करने का दूसरा तरीका स्वयं एप्लिकेशन की निगरानी करना है। इस उद्देश्य के लिए कई प्रौद्योगिकियाँ उपलब्ध हैं:

• वेब एप्लिकेशन फ़ायरवॉल (WAF) एक ट्रैफ़िक फ़िल्टरिंग टूल है। यह एप्लिकेशन परत पर काम करता है और HTTP/HTTPS ट्रैफ़िक का विश्लेषण करके वेब एप्लिकेशन की सुरक्षा करता है।

• आरएएसपी (रनटाइम एप्लिकेशन सेल्फ-प्रोटेक्शन) एक ऐसी तकनीक है जो वास्तविक समय में किसी एप्लिकेशन पर हमलों का पता लगाती है और उन्हें रोकती है। यह रनटाइम वातावरण में एक रक्षा फ़ंक्शन जोड़ता है, जिससे एप्लिकेशन को स्वचालित रूप से स्वयं की सुरक्षा करने की अनुमति मिलती है।

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

WAF के विपरीत, RASP एप्लिकेशन के भीतर और उसके साथ काम करता है। WAF को मूर्ख बनाया जा सकता है। यदि कोई हमलावर एप्लिकेशन कोड बदलता है, तो WAF इसका पता नहीं लगा सकता क्योंकि यह निष्पादन संदर्भ को नहीं समझता है।

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

आरएएसपी तकनीक की विशेषता डिफ़ॉल्ट रूप से हमलों को रोकने पर ध्यान केंद्रित करना है। सिस्टम को स्रोत कोड तक पहुंच की आवश्यकता नहीं है।

आरएएसपी मूर्ख

मैं आपको अनुशंसित करता हूं:

• मज़बूत
• स्क्रिन
• ओपनआरएएसपी Baidu द्वारा विकसित एक ओपन-सोर्स समाधान है
• सिग्नल विज्ञान
• जेस्क्रैम्बलर
• Hdiv
• इम्पेर्वा

बढ़िया, आगे बढ़ें.

DevSecOps P पाइपलाइन परिणाम और भेद्यता प्रबंधन का विज़ुअलाइज़ेशन

पाइपलाइन के विभिन्न चरणों में, मैं कई एप्लिकेशन सुरक्षा परीक्षण/DevSecOps विश्लेषक का उपयोग करता हूं। उनमें से प्रत्येक अपने स्वयं के प्रारूप में एक रिपोर्ट तैयार करता है, और उनमें से कुछ तथाकथित झूठी सकारात्मकताएँ उत्पन्न करते हैं। इस वजह से, संपूर्ण एप्लिकेशन की सुरक्षा का विश्लेषण करना आसान नहीं है।

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

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

DevSecOps उपकरण

उपकरणों की एक विस्तृत श्रृंखला आमतौर पर सुरक्षा डैशबोर्ड के रूप में उपयोग की जाती है: उदाहरण के लिए, क्लासिक SOAR/SIEM सिस्टम और स्वोर्डफ़िश सिक्योरिटी से विशेष DevSecOps ऑर्केस्ट्रेटर AppSec.Hub या ओपन-सोर्स भेद्यता प्रबंधन टूलकिट DefectDojo।

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

हालाँकि, अच्छी बात यह है कि DefectDojo डेवलपर्स और अनुरक्षक जटिलताओं को सुलझाने में मदद करते हैं। DefectDojo डेवलपर्स बहुत संवेदनशील लोग हैं - हम GitHub पर मुद्दों के माध्यम से सीधे उनसे संपर्क करने की सलाह देते हैं।

शिफ्ट लेफ्ट कॉन्सेप्ट: आइए संक्षेप में बताएं

एक बार फिर, लेख में जो कुछ था उसका संक्षिप्त विवरण यहां दिया गया है।

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

फिर, मैंने DevSecOps पाइपलाइन संरचना का पुनर्निर्माण किया और देखा कि पाइपलाइन के प्रत्येक चरण में कौन सी सुरक्षा जांच की जाती है:

• पूर्व-प्रतिबद्ध। इसका तात्पर्य संस्करण नियंत्रण प्रणाली में प्रवेश करने से पहले स्रोत कोड की सुरक्षा की जाँच करना है।

• पूर्व निर्माण. यह संस्करण नियंत्रण प्रणाली (सीक्रेट डिटेक्शन, एसएएसटी, एससीए) में स्रोत कोड सुरक्षा की जांच है।

• पोस्ट-बिल्ड. यह स्रोत कोड (स्रोत एससीए, बाइनरी एससीए) से निर्मित एक आर्टिफैक्ट की सुरक्षा जांच है।

• परीक्षण समय। इसका तात्पर्य उस एप्लिकेशन की सुरक्षा का परीक्षण करना है जो एकत्रित आर्टिफैक्ट (DAST, IAST, और OAST) से चल रहा है।

• पोस्ट-तैनाती. इसका तात्पर्य उत्पादन वातावरण (डब्ल्यूएएफ, आरएएसपी) में तैनाती के बाद एप्लिकेशन सुरक्षा की जांच करना है।

अब, आप समझ गए हैं कि DevSecOps पाइपलाइन कैसे काम करती है। अब, आप अपनी DevSecOps पाइपलाइनों की परिपक्वता का आकलन कर सकते हैं, इसके विकास के लिए एक रोडमैप विकसित कर सकते हैं और प्रत्येक कार्य के लिए सही उपकरण चुन सकते हैं।