- सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की परिभाषा
- सॉफ़्टवेयर आपूर्ति श्रृंखलाओं पर हमले: वे इतने आम क्यों हैं?
- एसएसडीएफ (एनआईएसटी 800-218) को अंतिम रूप दे दिया गया है और यह प्रभावी है
- एसएलएसए एक ऐसा ढांचा है जिसका आपको अनुपालन करना चाहिए
- अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला को कैसे सुरक्षित करें?
- सॉफ़्टवेयर अखंडता को मान्य करना चुनौतीपूर्ण है
- संपूर्ण एसडीएलसी में कोड आश्वासन
- सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की व्याख्या की गई
- एसएलएसए-अनुपालन मूल्यांकन को स्वचालित करना
- स्क्राइब सुरक्षा - एक नया सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा मानक
- मुंशी कैसे मदद कर सकता है?
सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा क्या है?
सॉफ़्टवेयर आपूर्ति श्रृंखला में संपूर्ण सॉफ़्टवेयर विकास जीवन चक्र (एसडीएलसी) के दौरान किसी उत्पाद या एप्लिकेशन को प्रभावित करने वाली या भूमिका निभाने वाली हर चीज़ शामिल होती है।
हाल के वर्षों में, सॉफ़्टवेयर आपूर्ति श्रृंखला पर हमले अधिक प्रचलित और अधिक परिष्कृत होते जा रहे हैं। उनकी 2022 रिपोर्ट में, गार्टनर राज्यों: "उद्यम हमले की सतह के निरंतर विस्तार की आशा करें और पहचान के खतरे का पता लगाने और उपचार और डिजिटल आपूर्ति श्रृंखला अखंडता के लिए प्रक्रियाओं और उपकरणों में निवेश बढ़ाएं।"
सॉफ़्टवेयर के निर्माण और परिनियोजन में शामिल सभी घटकों, गतिविधियों और SDLC प्रथाओं को सुरक्षित करना पहले से कहीं अधिक महत्वपूर्ण है। विकास टीमों और सॉफ्टवेयर विक्रेताओं को यह सुनिश्चित करना चाहिए कि वे केवल ज्ञात कमजोरियों से मुक्त कोड घटकों का उपयोग करें और अनधिकृत छेड़छाड़ की जांच करते हुए, अपने निर्माण की अखंडता को मान्य करने के तरीके खोजें।
- सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की परिभाषा
- सॉफ़्टवेयर आपूर्ति श्रृंखलाओं पर हमले: वे इतने आम क्यों हैं?
- एसएसडीएफ (एनआईएसटी 800-218) को अंतिम रूप दे दिया गया है और यह प्रभावी है
- एसएलएसए एक ऐसा ढांचा है जिसका आपको अनुपालन करना चाहिए
- अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला को कैसे सुरक्षित करें?
- सॉफ़्टवेयर अखंडता को मान्य करना चुनौतीपूर्ण है
- संपूर्ण एसडीएलसी में कोड आश्वासन
- सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की व्याख्या की गई
- एसएलएसए-अनुपालन मूल्यांकन को स्वचालित करना
- स्क्राइब सुरक्षा - एक नया सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा मानक
- मुंशी कैसे मदद कर सकता है?
सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की परिभाषा
सॉफ़्टवेयर आपूर्ति श्रृंखला संपूर्ण सॉफ़्टवेयर विकास जीवन चक्र (एसडीएलसी) के दौरान किसी एप्लिकेशन के विकास में शामिल हर चीज़ को संदर्भित करती है। सॉफ़्टवेयर बनाने और तैनात करने के लिए इसकी आपूर्ति श्रृंखला की गतिविधियों, प्रक्रियाओं और घटकों को सुरक्षित करने की आवश्यकता होती है। इस संबंध में विचार करने के लिए कई कारक हैं, जिनमें कस्टम कोड (इन-हाउस घटक), ओपन सोर्स निर्भरता और लाइब्रेरी (तीसरे पक्ष के घटक), DevOps उपकरण और बुनियादी ढांचे जो CI/CD प्रक्रिया बनाते हैं, और अंत में डेवलपर्स और DevOps शामिल हैं। टीमें.
इन सुरक्षा गतिविधियों को निष्पादित करना और उपभोक्ताओं को अपने सुरक्षा प्रयासों का प्रमाण प्रदान करना संगठनों की जिम्मेदारी है।
सॉफ़्टवेयर आपूर्ति श्रृंखलाओं पर हमले: वे इतने आम क्यों हैं?
आधुनिक सॉफ़्टवेयर पाइपलाइनें स्वचालित वातावरण हैं जो निरंतर एकीकरण और निरंतर वितरण के लिए विभिन्न उपकरणों पर निर्भर करती हैं। एक सॉफ़्टवेयर प्रोजेक्ट हजारों ओपन सोर्स निर्भरताओं सहित समाप्त हो सकता है।
दुर्भावनापूर्ण अभिनेता ओपन-सोर्स पैकेज प्रबंधकों में "तार्किक खामियों" का फायदा उठाकर दुष्ट पुस्तकालयों को वैध मान सकते हैं। उदाहरण के लिए, मैलवेयर-युक्त पैकेजों को उनकी जानकारी के बिना विश्वसनीय अनुरक्षकों को सौंपा जा सकता है। इस तरह का गलत विश्वास आपके कोड में समस्याग्रस्त और छिपी हुई कमजोरियाँ ला सकता है। ये कमजोरियाँ हमलावरों को संवेदनशील डेटा तक पहुंच प्रदान कर सकती हैं या उन्हें आपूर्ति श्रृंखला में मैलवेयर और नियंत्रण प्रणाली लगाने की अनुमति दे सकती हैं।
आधुनिक विकास परिवेश की अपनी कमजोरियाँ हैं, और विभिन्न प्रकार के सॉफ़्टवेयर आपूर्ति श्रृंखला हमलों ने विकास प्रक्रिया के दौरान किसी बिंदु पर दुर्भावनापूर्ण कोड डालने के लिए सीआई/सीडी पाइपलाइन को लक्षित किया। यहां भी, शून्य विश्वास धारणा अंतिम सॉफ्टवेयर उत्पाद में विश्वास हासिल करने के लिए पर्याप्त दृष्टिकोण है - आंतरिक विकास श्रृंखला में हर चरण की जांच, सत्यापन और सत्यापन करें।
आज की सीआई/सीडी पाइपलाइनों में सॉफ्टवेयर विकास प्रक्रिया की पर्याप्त सुरक्षा के लिए दृश्यता और नियंत्रण का अभाव है। उन्हें कोड से छेड़छाड़ का पता लगाने में भी संघर्ष करना पड़ता है, जिससे यह आक्रमण वेक्टर और भी आकर्षक हो जाता है।
एसएसडीएफ (एनआईएसटी 800-218) को अंतिम रूप दे दिया गया है और यह प्रभावी है
एसएसडीएफ (एनआईएसटी 800-218) ढांचा आपूर्तिकर्ताओं को सॉफ़्टवेयर विकास जीवन चक्र (एसडीएलसी) को कवर करने वाली सुरक्षा प्रथाओं को लागू करने की आवश्यकता है। यह सुरक्षा कमजोरियों और दुर्भावनापूर्ण हस्तक्षेप को कम करने के प्रयास में पारदर्शिता और छेड़छाड़-प्रतिरोधी उपायों को बढ़ावा देता है।
विशेष रूप से, इसमें सॉफ़्टवेयर को छेड़छाड़ से बचाने के लिए साक्ष्य-आधारित दृष्टिकोण के लिए दिशानिर्देश शामिल हैं।
SSDF के चार मुख्य भाग हैं:
/ 01
संगठन तैयार करें (पीओ):
सुनिश्चित करें कि संगठन स्तर पर और, कुछ मामलों में, व्यक्तिगत विकास समूहों या परियोजनाओं के लिए सुरक्षित सॉफ़्टवेयर विकास करने के लिए लोग तैयार हैं और प्रक्रियाएँ और तकनीक मौजूद हैं।
/ 02
सॉफ़्टवेयर को सुरक्षित रखें (पीएस):
सभी सॉफ़्टवेयर घटकों को किसी भी अनधिकृत पहुंच या छेड़छाड़ से सुरक्षित रखें।
/ 03
अच्छी तरह से सुरक्षित सॉफ़्टवेयर (पीडब्लू) तैयार करें:
अपने रिलीज़ में न्यूनतम सुरक्षा कमजोरियों के साथ अच्छी तरह से सुरक्षित सॉफ़्टवेयर का उत्पादन करें।
/ 04
कमजोरियों पर प्रतिक्रिया (आरवी):
सॉफ़्टवेयर रिलीज़ में अवशिष्ट कमजोरियों की पहचान करें, उन कमजोरियों को दूर करने के लिए उचित प्रतिक्रिया दें और भविष्य में इसी तरह की कमजोरियों को होने से रोकें।
आपको एसएसडीएफ को एक चेकलिस्ट के रूप में नहीं, बल्कि सुरक्षित सॉफ्टवेयर विकसित करने के लिए जोखिम-आधारित और साक्ष्य-आधारित दृष्टिकोण की योजना बनाने और लागू करने के लिए एक मार्गदर्शिका के रूप में संदर्भित करना चाहिए।
उभरते नियामक परिवर्तनों के अनुपालन को सुविधाजनक बनाने के लिए कंपनियों को अपनी सुरक्षा स्थिति में सुधार के लिए कदम उठाने चाहिए।
एसएलएसए एक ऐसा ढांचा है जिसका आपको अनुपालन करना चाहिए
Google में उत्पन्न एक ढाँचा, जिसे SLSA (सॉफ़्टवेयर कलाकृतियों के लिए आपूर्ति-श्रृंखला स्तर) कहा जाता है, सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के चार स्तरों तक पहुँचने के लिए दिशानिर्देश प्रदान करता है। यह ढांचा छेड़छाड़ को रोकने और कलाकृतियों को सुरक्षित करने के इरादे से कलाकृतियों के निर्माण की अखंडता पर केंद्रित है।
एसएलएसए इस तरह से काम करता है: आप सुरक्षा नियंत्रणों की चेकलिस्ट लागू करते हैं जिन्हें आपको अपनी पाइपलाइन में लागू करना चाहिए, और ये नियंत्रण स्रोत नियंत्रण सिस्टम, बिल्ड सिस्टम और निर्भरता जैसे उपडोमेन में हैं जिन्हें आप अपने सॉफ़्टवेयर प्रोजेक्ट में लाते हैं।
एसएलएसए स्तर 4 तक पहुंचने के उद्देश्य से अनुपालन के चार स्तर निर्धारित करता है, जिसमें उच्चतम सुरक्षा मूल्य होगा, लेकिन आवश्यकताओं की एक लंबी सूची होगी।
एसएलएसए ढांचा उद्गम की अवधारणा पर आधारित है। एक दस्तावेज़ जो कलाकृतियों की उत्पत्ति और निर्माण प्रक्रिया को दर्शाते हुए "साक्ष्य की श्रृंखला" का प्रतिनिधित्व करता है। जैसे-जैसे आप एसएलएसए स्तर पर ऊपर जाते हैं, आपको साक्ष्यों को बेहतर ढंग से सुरक्षित रखने की आवश्यकता होती है।
आपको एसएलएसए को एक उद्योग मानक, सुरक्षा और अनुपालन का एक पहचानने योग्य और सहमत स्तर के रूप में मानना चाहिए जिसका आपको पालन करना होगा।
अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला को कैसे सुरक्षित करें?
हालाँकि, हम रेखांकित करना चाहेंगे सुरक्षा नियंत्रण के तीन मुख्य वर्ग:
1. अपने सॉफ़्टवेयर विकास जीवनचक्र के कॉन्फ़िगरेशन को सुरक्षित करें
समझौता किए गए क्रेडेंशियल्स, अनुमतियों का अपर्याप्त नियंत्रण, और कमजोर बिल्ड सिस्टम हमले की सतह बनाते हैं जो सॉफ्टवेयर निर्माता को प्रभावित करते हैं। इन कमजोरियों का फायदा उठाकर हमलावर असुरक्षित रहस्य चुरा सकते हैं या सॉफ्टवेयर कलाकृतियों के साथ छेड़छाड़ कर सकते हैं। इस वर्ग में वाणिज्यिक और खुले स्रोत समाधानों की एक श्रृंखला सुरक्षा स्थिति में कमियों को दूर करने और उन्हें दूर करने के लिए नियंत्रण प्रदान कर सकती है।
2. कमजोर या दुर्भावनापूर्ण निर्भरता पर भरोसा करने से बचें
निश्चित रूप से, ओपन सोर्स और वाणिज्यिक सॉफ़्टवेयर में नई कमजोरियाँ खोजी जाती रहेंगी। सॉफ्टवेयर उत्पादकों को कमजोर ओपन सोर्स घटकों को अपग्रेड करके, अपने मालिकाना कोड में स्व-प्रेरित कमजोरियों को स्कैन करके और सॉफ्टवेयर उपभोक्ताओं को सामग्री के सॉफ्टवेयर बिल (एसबीओएम) और इसके संबंधित निहितार्थों के बारे में सूचित करके इस जोखिम को कम करना चाहिए। ये उपभोक्ता, बदले में, तदनुसार कार्रवाई कर सकते हैं।
अपहृत ओपन सोर्स प्रोजेक्ट खाते और वैध होने का दिखावा करने वाले दुर्भावनापूर्ण पैकेज अतिरिक्त जोखिम पैदा करते हैं, जो मुख्य रूप से पाइपलाइनों से गुप्त चोरी को प्रभावित करते हैं। ओपन सोर्स समुदाय और कुछ वाणिज्यिक विक्रेता बढ़ी हुई प्रतिष्ठा और दुर्भावनापूर्ण व्यवहार का पता लगाने के माध्यम से इसे संबोधित करने के लिए काम कर रहे हैं।
3. सॉफ़्टवेयर कलाकृतियों की अखंडता और सुरक्षित निर्माण को मान्य करें
साइबर सुरक्षा के लिए गहन सुरक्षा की आवश्यकता होती है। सुरक्षा के लिए पारंपरिक हमले की सतह में कमी, पता लगाने और प्रतिष्ठा दृष्टिकोण का उपयोग करने पर हमले दरारों से बच सकते हैं। मोरेसो, आजकल, डाउनस्ट्रीम सॉफ़्टवेयर उपभोक्ताओं का इन नियंत्रणों पर बहुत कम प्रभाव होता है। अधिक से अधिक, वे पॉइंट-इन-टाइम सुरक्षा ऑडिट पर भरोसा कर सकते हैं, जैसे कि कोड स्कैनिंग जो आपूर्तिकर्ताओं की भेद्यता स्नैपशॉट प्रदान करती है, जो वास्तविक विश्वास पैदा नहीं करती है कि सॉफ्टवेयर आर्टिफैक्ट अच्छी तरह से सुरक्षित है और विकास जीवन चक्र के दौरान सुरक्षित है।
नियंत्रणों का एक नया, उभरता हुआ वर्ग अब उपलब्ध है जो प्रत्येक सॉफ़्टवेयर आर्टिफैक्ट बिल्ड की अखंडता और सुरक्षित विकास प्रक्रिया को लगातार प्रमाणित करता है। ये सत्यापन गैर-प्रतिष्ठित हैं और सत्यापन की तलाश में उत्पादकों और डाउनस्ट्रीम उपभोक्ताओं के बीच साझा किए जा सकते हैं। गैर-अस्वीकरण क्रिप्टोग्राफ़िक तरीकों से प्राप्त किया जाता है और इसलिए, आपूर्ति श्रृंखला में घुसपैठ करने वाले किसी भी हमलावर के लिए कीमत में उल्लेखनीय वृद्धि होती है।
सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के क्षेत्र में विशेषज्ञ इस दृष्टिकोण को आवश्यक मानते हैं। हालाँकि, इस वर्ग के नियंत्रणों का समर्थन करने के लिए कुछ ओपन-सोर्स बिल्डिंग ब्लॉक मौजूद हैं, केवल कुछ विक्रेता ही एकीकृत समाधान प्रदान कर सकते हैं।
एक पूर्ण सॉफ़्टवेयर आपूर्ति श्रृंखला समाधान में शामिल होना चाहिए:
सॉफ़्टवेयर विकास और निर्माण प्रक्रियाओं से साक्ष्य एकत्र करना और सत्यापन के रूप में उस पर हस्ताक्षर करना। आम तौर पर, यह साक्ष्य मेटाडेटा के साथ फ़ाइल हैश होता है जिसकी तुलना प्रक्रिया में प्रासंगिक चरणों, सुरक्षा-संबंधित चरणों जैसे कोड कमिटर पहचान, कोड समीक्षा, स्वचालित सुरक्षा परीक्षण इत्यादि के बीच की जाती है। सॉफ़्टवेयर आर्टिफ़ैक्ट के निर्माण के समय सॉफ़्टवेयर निर्माता की निर्माण प्रक्रिया की सुरक्षा स्थिति के बारे में एक सत्यापन प्रदान करना भी आवश्यक है।
एक सुरक्षित सत्यापन स्टोर जो दृश्यता की अनुमति देता है और कोड अखंडता को मान्य करने जैसे विश्लेषण का समर्थन करता है।
एक नीति इंजन जो अनुपालन के सत्यापन और प्रदर्शन के लिए किसी संगठनात्मक परिभाषित नीति या मानक-आधारित नीति के विरुद्ध इन सत्यापनों को मापता है।
सॉफ़्टवेयर उत्पादकों या उपभोक्ताओं के बीच विश्वास-संबंधी जानकारी के लिए एक साझाकरण केंद्र; यह अंतर-उद्यम हो सकता है)।
सॉफ़्टवेयर अखंडता को मान्य करना चुनौतीपूर्ण है
सैद्धांतिक रूप से कोड अखंडता की जाँच करना आसान होना चाहिए। बस फाइलों की तुलना करें, है ना? वास्तव में, विचार करने के लिए बहुत कुछ है। शुरुआत के लिए, प्रत्येक भाषा फ़ाइलों को अलग-अलग तरीके से संकलित करती है। इसके अलावा, फ़ाइलों का उपयोग उनके उद्देश्य के आधार पर बहुत अलग तरीके से किया जाता है। कुछ बदलने के लिए हैं, जबकि अन्य हटा दिए जाते हैं, और अन्य संकलन प्रक्रिया के दौरान बनाए जाते हैं।
इसमें यह तथ्य भी जोड़ें कि कंपनियां अपना मालिकाना कोड एक-दूसरे को नहीं सौंपना चाहतीं।
संपूर्ण एसडीएलसी में कोड आश्वासन
स्क्राइब आपके संपूर्ण एसडीएलसी को लगातार सुरक्षित करने के लिए प्रतिबद्ध है। विकास और निर्माण प्रक्रिया के विभिन्न हिस्सों से एकत्र किए गए सबूतों के साथ, स्क्राइब अचूक सत्यापन बनाने के लिए डिजिटल हस्ताक्षर का उपयोग करता है।
एक बार हस्ताक्षर करने के बाद, साक्ष्य के प्रत्येक टुकड़े को बाद में सत्यापित किया जा सकता है ताकि यह सुनिश्चित किया जा सके कि सभी प्रक्रियाएं योजना के अनुसार हुईं और कोई अनियोजित परिवर्तन नहीं हुआ।
एसएसडीएफ में निर्धारित सर्वोत्तम प्रथाओं का पालन करते हुए, स्क्राइब आपको विकास प्रक्रिया के दौरान अपना आत्मविश्वास बढ़ाने के लिए सामान्य ज्ञान नीतियों को नियोजित करने की अनुमति देता है। हस्ताक्षरित प्रतिबद्धताओं की आवश्यकता, डेवलपर्स के लिए 2एफए, 2-व्यक्ति कोड समीक्षा आदि जैसी नीतियां, विश्वास पैदा करने में मदद करती हैं कि सॉफ्टवेयर का प्रत्येक टुकड़ा सही सुरक्षा स्थिति के बाद तैयार किया गया था।
कोड अखंडता रिपोर्ट और सभी नीतियों और सत्यापनों के सारांश के साथ इन सभी सबूतों को एक ही स्थान पर एकत्रित करने से विकास प्रक्रिया और अंत में उत्पादित सॉफ्टवेयर कलाकृतियों में अधिक दृश्यता और आत्मविश्वास की अनुमति मिलती है और यह एसएसडीएफ दिशानिर्देशों के साथ संरेखित होता है। नए साइबर विनियमन के आधार पर।
चुनिंदा ग्राहकों को नीतिगत आवश्यकताओं और अखंडता परिणामों के साथ उत्पाद के अनुपालन को देखने की अनुमति देने से उपयोगकर्ताओं को आपकी विकास पाइपलाइनों और अंतिम सॉफ़्टवेयर उत्पाद में अधिक दृश्यता और विश्वास मिलता है।
अंतिम परिणाम न केवल कोड या पाइपलाइन से छेड़छाड़ का पता लगाना है, बल्कि सॉफ्टवेयर के डिजाइन और निर्माण के दौरान हुए परीक्षणों और सुरक्षा प्रक्रियाओं के साथ-साथ स्रोत कोड और ओपन-सोर्स पैकेज की अखंडता को प्रमाणित करने की क्षमता भी है। इसे बनाने में उपयोग किया जाता है।
सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा की व्याख्या की गई
एसएलएसए-अनुपालन मूल्यांकन को स्वचालित करना
गतिशील पाइपलाइनों की सुरक्षा को लगातार मापा जाना चाहिए। एसएलएसए (सॉफ्टवेयर कलाकृतियों के लिए आपूर्ति-श्रृंखला स्तर) उन तक पहुंचने के दिशानिर्देशों के साथ चार सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा स्तरों को परिभाषित करता है।
उनकी आवश्यकताओं को पूरा करने के लिए एसएलएसए अनुपालन मूल्यांकन को स्वचालित किया जा सकता है। लेकिन किसी संगठन को इसे कैसे प्राप्त करना चाहिए? क्या ऐसी विशिष्ट सर्वोत्तम प्रथाएँ हैं जिनका आपको पालन करना चाहिए?
इस वीडियो को देखें जहां हम वास्तविक दुनिया के परिदृश्यों में सिगस्टोर और ओपीए जैसे ओपन-सोर्स टूल का उपयोग करके स्वचालन को लागू करने के लिए सर्वोत्तम प्रथाओं को साझा करते हैं। वैचारिक और तकनीकी दोनों सर्वोत्तम प्रथाएं वास्तविक दुनिया के विवरण और एसएलएसए अनुपालन के मूल्यांकन और स्वचालित करने की चुनौतियों पर प्रकाश डालती हैं।
स्क्राइब का उपयोग करने से पहले | Scribe का उपयोग करने के बाद | |
---|---|---|
ट्रस्ट हब - सूचना साझाकरण |
|
|
सुरक्षित एसडीएलसी - नीति और अनुपालन |
|
|
सत्यनिष्ठा एवं छेड़छाड़ का पता लगाना |
|
|
दर्शनीयता |
|
|
सुरक्षा मुद्रा |
|
|
स्क्राइब सुरक्षा - एक नया सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा मानक
सॉफ़्टवेयर विकास प्रक्रिया में प्रत्येक विवरण और घटना, साथ ही सॉफ़्टवेयर घटकों और कलाकृतियों की अखंडता को ट्रैक करें
सत्यापित करें कि सॉफ़्टवेयर विकास प्रक्रिया के किसी भी और सभी भागों में छेड़छाड़ नहीं हुई है
कोड बनाने के लिए उपयोग किए गए सीआई/सीडी टूल की अखंडता को सत्यापित करें
विकास प्रक्रिया की अखंडता की पुष्टि करें - यह सुनिश्चित करना कि सुरक्षा संबंधी कदम संगठन की नीति के अनुसार उठाए गए हैं और उन्हें नजरअंदाज नहीं किया गया है
विकास जीवन चक्र के हर चरण में, कोड के साथ होने वाली किसी भी चीज़ और हर चीज़ के सबूत इकट्ठा करने और हस्ताक्षर करने से आप हमलावरों के लिए फ़ाइलों, टूल या आपके सीआई/सीडी पाइपलाइन के अपेक्षित व्यवहार के साथ छेड़छाड़ करना अधिक कठिन बना देते हैं।