सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा क्या है?

सॉफ़्टवेयर आपूर्ति श्रृंखला में संपूर्ण सॉफ़्टवेयर विकास जीवन चक्र (एसडीएलसी) के दौरान किसी उत्पाद या एप्लिकेशन को प्रभावित करने वाली या भूमिका निभाने वाली हर चीज़ शामिल होती है।

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

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

सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की परिभाषा

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

इन सुरक्षा गतिविधियों को निष्पादित करना और उपभोक्ताओं को अपने सुरक्षा प्रयासों का प्रमाण प्रदान करना संगठनों की जिम्मेदारी है।

 

 

सॉफ़्टवेयर आपूर्ति श्रृंखलाओं पर हमले: वे इतने आम क्यों हैं?

आधुनिक सॉफ़्टवेयर पाइपलाइनें स्वचालित वातावरण हैं जो निरंतर एकीकरण और निरंतर वितरण के लिए विभिन्न उपकरणों पर निर्भर करती हैं। एक सॉफ़्टवेयर प्रोजेक्ट हजारों ओपन सोर्स निर्भरताओं सहित समाप्त हो सकता है।

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

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

एसएसडीएफ (एनआईएसटी 800-218) को अंतिम रूप दे दिया गया है और यह प्रभावी है

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

विशेष रूप से, इसमें सॉफ़्टवेयर को छेड़छाड़ से बचाने के लिए साक्ष्य-आधारित दृष्टिकोण के लिए दिशानिर्देश शामिल हैं।

SSDF के चार मुख्य भाग हैं:

/ 01
संगठन तैयार करें (पीओ):

सुनिश्चित करें कि संगठन स्तर पर और, कुछ मामलों में, व्यक्तिगत विकास समूहों या परियोजनाओं के लिए सुरक्षित सॉफ़्टवेयर विकास करने के लिए लोग तैयार हैं और प्रक्रियाएँ और तकनीक मौजूद हैं।

/ 02
सॉफ़्टवेयर को सुरक्षित रखें (पीएस):

सभी सॉफ़्टवेयर घटकों को किसी भी अनधिकृत पहुंच या छेड़छाड़ से सुरक्षित रखें।

/ 03
अच्छी तरह से सुरक्षित सॉफ़्टवेयर (पीडब्लू) तैयार करें:

अपने रिलीज़ में न्यूनतम सुरक्षा कमजोरियों के साथ अच्छी तरह से सुरक्षित सॉफ़्टवेयर का उत्पादन करें।

/ 04
कमजोरियों पर प्रतिक्रिया (आरवी):

सॉफ़्टवेयर रिलीज़ में अवशिष्ट कमजोरियों की पहचान करें, उन कमजोरियों को दूर करने के लिए उचित प्रतिक्रिया दें और भविष्य में इसी तरह की कमजोरियों को होने से रोकें।

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

एसएलएसए एक ऐसा ढांचा है जिसका आपको अनुपालन करना चाहिए

Google में उत्पन्न एक ढाँचा, जिसे SLSA (सॉफ़्टवेयर कलाकृतियों के लिए आपूर्ति-श्रृंखला स्तर) कहा जाता है, सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के चार स्तरों तक पहुँचने के लिए दिशानिर्देश प्रदान करता है। यह ढांचा छेड़छाड़ को रोकने और कलाकृतियों को सुरक्षित करने के इरादे से कलाकृतियों के निर्माण की अखंडता पर केंद्रित है।

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

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

एसएलएसए ढांचा उद्गम की अवधारणा पर आधारित है। एक दस्तावेज़ जो कलाकृतियों की उत्पत्ति और निर्माण प्रक्रिया को दर्शाते हुए "साक्ष्य की श्रृंखला" का प्रतिनिधित्व करता है। जैसे-जैसे आप एसएलएसए स्तर पर ऊपर जाते हैं, आपको साक्ष्यों को बेहतर ढंग से सुरक्षित रखने की आवश्यकता होती है।

आपको एसएलएसए को एक उद्योग मानक, सुरक्षा और अनुपालन का एक पहचानने योग्य और सहमत स्तर के रूप में मानना ​​चाहिए जिसका आपको पालन करना होगा।

अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला को कैसे सुरक्षित करें?

हमने जिन विभिन्न ढाँचों का उल्लेख किया है, वे सॉफ़्टवेयर आपूर्ति श्रृंखला को सुरक्षित करने के सिद्धांतों को परिभाषित करते हैं और उन पर आपका ध्यान आकर्षित करने की आवश्यकता है।

हालाँकि, हम रेखांकित करना चाहेंगे सुरक्षा नियंत्रण के तीन मुख्य वर्ग:

1. अपने सॉफ़्टवेयर विकास जीवनचक्र के कॉन्फ़िगरेशन को सुरक्षित करें

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

2. कमजोर या दुर्भावनापूर्ण निर्भरता पर भरोसा करने से बचें

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

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

3. सॉफ़्टवेयर कलाकृतियों की अखंडता और सुरक्षित निर्माण को मान्य करें

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

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

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

एक पूर्ण सॉफ़्टवेयर आपूर्ति श्रृंखला समाधान में शामिल होना चाहिए:

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

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

एक नीति इंजन जो अनुपालन के सत्यापन और प्रदर्शन के लिए किसी संगठनात्मक परिभाषित नीति या मानक-आधारित नीति के विरुद्ध इन सत्यापनों को मापता है।

सॉफ़्टवेयर उत्पादकों या उपभोक्ताओं के बीच विश्वास-संबंधी जानकारी के लिए एक साझाकरण केंद्र; यह अंतर-उद्यम हो सकता है)।

सॉफ़्टवेयर अखंडता को मान्य करना चुनौतीपूर्ण है

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

इसमें यह तथ्य भी जोड़ें कि कंपनियां अपना मालिकाना कोड एक-दूसरे को नहीं सौंपना चाहतीं।

संपूर्ण एसडीएलसी में कोड आश्वासन

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

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

एसएसडीएफ में निर्धारित सर्वोत्तम प्रथाओं का पालन करते हुए, स्क्राइब आपको विकास प्रक्रिया के दौरान अपना आत्मविश्वास बढ़ाने के लिए सामान्य ज्ञान नीतियों को नियोजित करने की अनुमति देता है। हस्ताक्षरित प्रतिबद्धताओं की आवश्यकता, डेवलपर्स के लिए 2एफए, 2-व्यक्ति कोड समीक्षा आदि जैसी नीतियां, विश्वास पैदा करने में मदद करती हैं कि सॉफ्टवेयर का प्रत्येक टुकड़ा सही सुरक्षा स्थिति के बाद तैयार किया गया था।

कोड अखंडता रिपोर्ट और सभी नीतियों और सत्यापनों के सारांश के साथ इन सभी सबूतों को एक ही स्थान पर एकत्रित करने से विकास प्रक्रिया और अंत में उत्पादित सॉफ्टवेयर कलाकृतियों में अधिक दृश्यता और आत्मविश्वास की अनुमति मिलती है और यह एसएसडीएफ दिशानिर्देशों के साथ संरेखित होता है। नए साइबर विनियमन के आधार पर।

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

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

एसएलएसए-अनुपालन मूल्यांकन को स्वचालित करना

गतिशील पाइपलाइनों की सुरक्षा को लगातार मापा जाना चाहिए। एसएलएसए (सॉफ्टवेयर कलाकृतियों के लिए आपूर्ति-श्रृंखला स्तर) उन तक पहुंचने के दिशानिर्देशों के साथ चार सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा स्तरों को परिभाषित करता है।

उनकी आवश्यकताओं को पूरा करने के लिए एसएलएसए अनुपालन मूल्यांकन को स्वचालित किया जा सकता है। लेकिन किसी संगठन को इसे कैसे प्राप्त करना चाहिए? क्या ऐसी विशिष्ट सर्वोत्तम प्रथाएँ हैं जिनका आपको पालन करना चाहिए?

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

स्क्राइब का उपयोग करने से पहले Scribe का उपयोग करने के बाद
ट्रस्ट हब - सूचना साझाकरण

  • एक उत्पन्न एसबीओएम स्थानीय रूप से प्रति एकल पाइपलाइन में सहेजा जाता है, उसे पूरे संगठन या बाहरी हितधारकों के साथ प्रबंधित करने या साझा करने की क्षमता के बिना।

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

सुरक्षित एसडीएलसी - नीति और अनुपालन

  • यह सुनिश्चित करने का कोई स्वचालित या लचीला तरीका नहीं है कि आवश्यकतानुसार सुरक्षित एसडीएलसी नीतियों का पालन किया गया।

  • एक साक्ष्य-आधारित विश्वसनीय तरीका जो सुरक्षित एसडीएलसी नीतियों को नवीनतम सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा नियमों और ढांचे (एसएलएसए 3, एसएसडीएफ) के अनुसार लागू करने का आश्वासन देता है।

सत्यनिष्ठा एवं छेड़छाड़ का पता लगाना

  • केवल वही जो आप लॉग और एपीआई से प्राप्त कर सकते हैं
  • प्रक्रिया के अंत तक हस्ताक्षर नहीं किए गए - डिलीवरी से ठीक पहले (केवल 'अंतिम अंतराल' एमआईटीएम से संबंधित)

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

दर्शनीयता

  • आप लॉग और एपीआई से जो कुछ भी प्राप्त कर सकते हैं
  • स्थानीय रूप से सहेजा गया और हस्ताक्षरित नहीं किया गया, जिससे संभावना है कि दुर्भावनापूर्ण अभिनेताओं ने इसके साथ छेड़छाड़ की है

  • हस्ताक्षरित सत्यापन एक अलग सुरक्षित-छेड़छाड़-प्रूफ साक्ष्य भंडार में सहेजे गए

सुरक्षा मुद्रा

  • सीआई/सीडी टूल्स की ग़लत कॉन्फ़िगरेशन की जाँच करना
  • लीक हुए रहस्यों की तलाश की जा रही है
  • ज्ञात कमजोरियों की जाँच (सीवीई)

  • आपके सीआई/सीडी टूलचेन में एसडीएलसी अंतराल की जाँच करना।
  • ज्ञात कमजोरियों (सीवीई) और ओएसएस रिपो की प्रतिष्ठा की जाँच करना
  • छेड़छाड़-रोधी साक्ष्य दर्ज करना कि संगठनों की एसडीएलसी नीति के अनुसार प्रक्रिया के हर चरण में आवश्यक सुरक्षा उपाय समय पर किए गए थे।

स्क्राइब सुरक्षा - एक नया सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा मानक

सतत कोड एश्योरेंस प्रक्रियाओं और उपकरणों से युक्त है:

सॉफ़्टवेयर विकास प्रक्रिया में प्रत्येक विवरण और घटना, साथ ही सॉफ़्टवेयर घटकों और कलाकृतियों की अखंडता को ट्रैक करें

सत्यापित करें कि सॉफ़्टवेयर विकास प्रक्रिया के किसी भी और सभी भागों में छेड़छाड़ नहीं हुई है

कोड बनाने के लिए उपयोग किए गए सीआई/सीडी टूल की अखंडता को सत्यापित करें

विकास प्रक्रिया की अखंडता की पुष्टि करें - यह सुनिश्चित करना कि सुरक्षा संबंधी कदम संगठन की नीति के अनुसार उठाए गए हैं और उन्हें नजरअंदाज नहीं किया गया है

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

कैसे मदद?

हमारा अनूठा प्लेटफ़ॉर्म यह सुनिश्चित करता है कि अग्रणी सुरक्षा अवधारणाओं और ढाँचों का उपयोग करते हुए कोड कलाकृतियाँ पूरे सॉफ़्टवेयर विकास जीवनचक्र के दौरान Git से उत्पादन तक सुरक्षित रहें।

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

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

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

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

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

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

एक एसबीओएम (सामग्री का सॉफ्टवेयर बिल), एक सॉफ्टवेयर उत्पाद या एप्लिकेशन को बनाने वाले कई घटकों के बारे में जानकारी का एक सेट है। इसमें आमतौर पर लाइसेंसिंग जानकारी, संस्करण संख्या, घटक विवरण, विक्रेता आदि शामिल होते हैं। ऐसी विस्तृत और औपचारिक सूची दूसरों को यह समझने की अनुमति देकर कि उनके सॉफ़्टवेयर में क्या है और उसके अनुसार कार्य करने से निर्माता और उपयोगकर्ता दोनों के लिए जोखिम कम हो जाते हैं।

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

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

सतत आश्वासन यह सुनिश्चित करता है कि विकास के दौरान सॉफ्टवेयर उत्पादों के साथ छेड़छाड़ नहीं की गई और सुरक्षा संबंधी परीक्षण किए गए।

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

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

का अंतिम संस्करण एनआईएसटी एसएसडीएफ 1.1 (सिक्योर सॉफ्टवेयर डेवलपमेंट फ्रेमवर्क) 22 मार्च को जारी किया गया था। सितंबर 2021 में, ढांचे का एक मसौदा संस्करण प्रकाशित किया गया था। कई अंतर उच्च-स्तरीय प्रथाओं और कार्यों के बजाय प्रदान किए गए विभिन्न उदाहरणों पर केंद्रित हैं।

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

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

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

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

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

आपको स्वचालन को लागू करने के लिए सर्वोत्तम प्रथाओं का पालन करने की आवश्यकता है, जैसे कि सिगस्टोर और ओपीए जैसे ओपन-सोर्स टूल का उपयोग करना।