सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा सर्वोत्तम प्रथाएँ

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

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

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

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

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

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

अच्छी तरह से सुरक्षित घटक प्राप्त करें

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

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

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

सुरक्षित कोडिंग प्रथाओं का पालन करते हुए इन-हाउस सुरक्षित सॉफ़्टवेयर घटक बनाएं

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

प्रत्येक संगठन को एक व्यापक सॉफ्टवेयर विकास जीवनचक्र ढांचे की आवश्यकता होती है जिसमें सुरक्षित कोडिंग प्रथाओं को शामिल किया जाता है ताकि यह सुनिश्चित किया जा सके कि बनाई गई कलाकृतियां निर्धारित दिशानिर्देशों के अनुपालन में हैं।

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

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

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

 सुरक्षित तृतीय-पक्ष सॉफ़्टवेयर टूलचेन और संगतता लाइब्रेरी का उपयोग करें

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

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

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

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

अंदरूनी सूत्रों द्वारा स्रोत कोड के संशोधन या शोषण को कम करें

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

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

• संतुलित और प्रमाणित स्रोत कोड चेक-इन प्रक्रिया
• कमजोरियों के लिए स्वचालित सुरक्षा स्कैनिंग
• सुरक्षित सॉफ्टवेयर विकास प्रशिक्षण
• विकास के माहौल को सख्त बनाना
• कोड समीक्षाओं को प्राथमिकता देना

कोड या निष्पादनयोग्य को संग्रहीत करें और अनुमोदन से पहले सभी परिवर्तनों की समीक्षा करें

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

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

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

बनाए गए प्रत्येक सॉफ़्टवेयर पैकेज के लिए एक एसबीओएम बनाएं और बनाए रखें

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

सामग्री का एक सॉफ्टवेयर बिल क्रमशः लिनक्स, ओडब्ल्यूएएसपी और एनआईएसटी द्वारा परिभाषित सॉफ्टवेयर पैकेज डेटा एक्सचेंज (एसपीडीएक्स), साइक्लोनडीएक्स, और सॉफ्टवेयर आइडेंटिफिकेशन (एसडब्ल्यूआईडी) टैग जैसे मानक प्रारूपों में परिभाषित विनिर्देशों के आधार पर तैयार किया जा सकता है।

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

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

निर्माण परिवेश को कठोर बनाएं

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

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

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

सिस्टम को लॉक करें

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

बाहरी और ऑफ-लैन नेटवर्क गतिविधियों को सीमित करें

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

डेटा लीक के लिए सिस्टम की निगरानी करें

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

अपनी संस्करण नियंत्रण पाइपलाइन कॉन्फ़िगर करें

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

बहु कारक प्रमाणीकरण

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

अपने इंजीनियरिंग नेटवर्क को अलग करें

आपके बिल्ड सिस्टम को केवल आपके संगठन के बाकी नेटवर्क से अलग एक अलग इंजीनियरिंग नेटवर्क के माध्यम से एक्सेस किया जाना चाहिए। जब संभव हो, इंजीनियरिंग नेटवर्क ऑफ़लाइन होना चाहिए।

इसके निवारण की योजना बनाने के लिए पर्याप्त जानकारी इकट्ठा करने के लिए प्रत्येक भेद्यता का विश्लेषण करें

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

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

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

घटक रखरखाव

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

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

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