जब तीन अमेरिकी सरकारी एजेंसियां कुछ प्रथाओं को अपनाने के लिए डेवलपर्स को "दृढ़ता से प्रोत्साहित" करने के लिए एक साथ आती हैं, तो आपको ध्यान देना चाहिए। सीआईएसए, एनएसए और ओडीएनआई ने साइबर-हैकर्स के खतरे को देखते हुए और सोलरविंड्स हमले के मद्देनजर घोषणा की कि वे भविष्य में ऐसी कमजोरियों को रोकने के लिए सॉफ्टवेयर आपूर्ति श्रृंखला को सुरक्षित करने के लिए संयुक्त रूप से सिफारिशों का एक संग्रह प्रकाशित करेंगे। . घोषणा ने यह स्पष्ट कर दिया कि दस्तावेज़ का उद्देश्य डेवलपर्स को सर्वोत्तम प्रथाओं को अपनाने के लिए प्रोत्साहित करना है, जिसमें कहा गया है कि "इन सिद्धांतों में सुरक्षा आवश्यकताओं की योजना बनाना, सुरक्षा परिप्रेक्ष्य से सॉफ्टवेयर आर्किटेक्चर को डिजाइन करना, सुरक्षा सुविधाओं को जोड़ना और सॉफ्टवेयर और अंतर्निहित बुनियादी ढांचे की सुरक्षा को बनाए रखना शामिल है।"
यह मार्गदर्शन तीन-भाग की श्रृंखला के रूप में आयोजित किया गया है और इसे सॉफ़्टवेयर आपूर्ति श्रृंखला जीवनचक्र के साथ जारी किया जाएगा। श्रृंखला के भाग 1, जो सॉफ्टवेयर डेवलपर्स के लिए सिफारिशों पर केंद्रित है, अगस्त 2022 में जारी किया गया है। शेष दो भाग निकट भविष्य में जारी किए जाएंगे: भाग 2 सॉफ्टवेयर आपूर्तिकर्ताओं पर केंद्रित होगा और भाग 3 सॉफ्टवेयर प्राप्त करने वाले ग्राहकों पर केंद्रित होगा। अंतिम लक्ष्य यह है कि यह श्रृंखला इन तीन प्रमुख हितधारकों और साइबर सुरक्षा पेशेवरों के बीच संचार को बढ़ावा देने में मदद करेगी ताकि लचीलापन बढ़ाया जा सके और समग्र सुधार किया जा सके। सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा.
हालाँकि यह हमेशा स्पष्ट नहीं होता है कि सॉफ़्टवेयर सुरक्षा सुनिश्चित करना किसकी ज़िम्मेदारी है, भले ही आपके विशिष्ट संगठन में समग्र ज़िम्मेदारी कौन उठा सकता है, यह नई गाइड यह बिल्कुल स्पष्ट करता है कि सभी डेवलपर्स को इन नई सर्वोत्तम प्रथाओं से परिचित होना चाहिए और सॉफ़्टवेयर आपूर्ति श्रृंखला को सुरक्षित करने में उन सभी की भूमिका है। या, यदि मैं अधिक स्पष्ट कहूँ: डेवलपर्स, आप अपने संगठन की सॉफ़्टवेयर आपूर्ति श्रृंखला को सुरक्षित करने में महत्वपूर्ण भूमिका निभाते हैं! और इसी कारण से, हमने सोचा कि केवल आपके लिए, गाइड के इस पहले भाग का (अपेक्षाकृत) संक्षिप्त सारांश पढ़ना आपके लिए उपयोगी हो सकता है। यह आता है।
संक्षेप में मार्गदर्शिका:
डेवलपर्स के लिए इस व्यावहारिक मार्गदर्शिका में उल्लिखित संभावित खतरों की व्यापक सूचियों में से कुछ प्रमुख कमजोरियाँ हैं जिनकी पहचान की गई है और आपको उन्हें संबोधित करना और उनके लिए तैयारी करना सुनिश्चित करना चाहिए:
- ऐसी विशेषताएँ जिन्हें उचित रूप से प्रलेखित नहीं किया गया है या जो जोखिमपूर्ण कार्यक्षमता लागू करती हैं
- सुरक्षा मूल्यांकन और कोड वितरण के समय के बीच मुख्य सुरक्षा धारणाओं में अंडर-द-रडार बदलाव होता है
- आपूर्ति श्रृंखला हितधारकों के लिए कॉर्पोरेट परिवर्तन
- उप-मानक कोडिंग या सुरक्षा प्रथाएँ
प्रबंधन, वित्त और कार्यक्रम प्रबंधकों सभी की सॉफ्टवेयर आपूर्ति श्रृंखला की सुरक्षा, लेकिन अखंडता को संबोधित करने की जिम्मेदारी है सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा यह अक्सर सॉफ्टवेयर डेवलपर्स की सतर्कता और सभी आपूर्ति श्रृंखला हितधारकों के बीच जागरूकता पर निर्भर करता है। गाइड का भाग 1 डेवलपर्स की भूमिका और विकास प्रक्रिया के प्रत्येक चरण में अंतर्निहित खतरों पर केंद्रित है, और शमन रणनीतियों के लिए सिफारिशें प्रदान करता है जिन्हें मानक अभ्यास बनना चाहिए।
चरण # 1: सुरक्षित उत्पाद मानदंड और प्रबंधन
सुरक्षित विकास उत्पाद और विकास टीमों में सभी प्रमुख हितधारकों द्वारा सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के महत्व की मान्यता के साथ शुरू होता है। खतरे के परिदृश्य आम हैं और हर किसी के लिए स्पष्ट हो सकते हैं; चुनौती यह है कि जिन शमन नीतियों पर निर्णय लिया गया है, उनके संबंध में सभी को एक ही पृष्ठ पर लाना है। इन नीतियों में पूरी प्रक्रिया को शामिल किया जाना चाहिए: डिज़ाइन और वास्तुकला, खतरे का मॉडलिंग, कोडिंग, सुरक्षा परीक्षण योजना, रिलीज़ मानदंड और भविष्य में कमजोरियों का प्रबंधन कैसे करें। इसके एक भाग में टीमों की क्षमताओं का आकलन करना और यह सुनिश्चित करना भी शामिल है कि उन्हें अपने कार्यों के लिए उचित रूप से प्रशिक्षित किया गया है और फिर दस्तावेज़ीकरण प्रथाओं और समय-समय पर सुरक्षा समीक्षा और खतरे के आकलन को परिभाषित करना शामिल है।
चरण #2: सुरक्षित कोड विकास
जब कोड विकास की बात आती है, तो सुरक्षित कोडिंग के लिए सही अभ्यास पहले ही बताए जा चुके हैं एसएसडीएफ. यही कारण है कि, जिस हद तक प्रोग्रामिंग भाषा पूर्व निर्धारित नहीं की गई है, सुरक्षा संबंधी विचार भी उस निर्णय का हिस्सा होना चाहिए। पथप्रदर्शक उपयोगी मार्गदर्शन प्रदान करता है डेवलपर्स के लिए, परिदृश्यों की एक विस्तृत श्रृंखला को संबोधित करना, जैसे 'अंदरूनी सूत्रों' (उदाहरण के लिए, डेवलपर्स) द्वारा हानिकारक स्रोत कोड का सम्मिलन, ओपन-सोर्स सॉफ़्टवेयर और इससे निपटने के लिए सर्वोत्तम अभ्यास। कोडिंग के लिए एक सुरक्षित वातावरण कैसे बनाएं (सुरक्षित बिल्ड कॉन्फ़िगरेशन और तृतीय पक्ष सॉफ़्टवेयर टूल सहित) और बाद में एक एकीकृत उत्पाद की सुरक्षा का परीक्षण करें। चूंकि डिलीवरी के बाद भी कमजोरियां उत्पन्न होने की संभावना है, इसलिए रिपोर्ट की गई कमजोरियों से निपटने और यह सुनिश्चित करने के लिए भी सिफारिशें हैं कि भविष्य के बाहरी सॉफ्टवेयर एक्सटेंशन उत्पाद की सुरक्षा अखंडता से समझौता नहीं करते हैं।
चरण #3: निर्माण परिवेश को कठोर बनाएं
एक बार कोड सुरक्षित रूप से विकसित हो जाने के बाद, सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के लिए आवश्यक है कि निर्माण वातावरण को सॉफ़्टवेयर के समान मानकों के अनुसार सख्त किया जाए। बिल्ड सिस्टम से समझौता करना कोड में घुसपैठ करने का एक आकर्षक तरीका है, क्योंकि यह विकास प्रक्रिया के एक ऐसे चरण में आता है जिसकी स्वाभाविक रूप से डेवलपर्स द्वारा कम जांच की जाती है।
स्टेज # 4: कोड डिलीवरी
गाइड द्वारा संबोधित अंतिम कमजोरी सॉफ्टवेयर आपूर्ति श्रृंखला-कोड डिलीवरी के अंतिम चरण को कवर करती है। यहां तक कि जब कोड को इस बिंदु तक सभी तरह से ठीक से सुरक्षित किया गया है, तब भी दो प्रमुख आपूर्ति श्रृंखला कमजोरियां हैं जिन्हें कम किया जाना चाहिए। पहला अंतिम पैकेज सत्यापन है, जिसका फायदा उठाया जा सकता है, उदाहरण के लिए, अनजाने में मेटाडेटा, डेवलपर क्रेडेंशियल या ओपन-सोर्स इन्वेंट्री को उजागर करके। दूसरा कदम जिसकी अक्सर कमजोरियों के लिए जांच की जाती है, वह वितरण प्रणाली है, जिसे एक मध्य-मध्य हमले से समझौता किया जा सकता है जो वितरण में एक या अधिक चरणों को ले सकता है।
सॉफ़्टवेयर विकास स्तर पर इन जोखिम-शमन प्रथाओं को लागू करके, सॉफ़्टवेयर विक्रेता उन कमजोरियों से बच सकते हैं जो उदाहरण के लिए, अपडेट की घुसपैठ, कोड हस्ताक्षर हेरफेर और ओपन-सोर्स-कोड में छिपे "आश्चर्य" का कारण बन सकती हैं।
मुफ़्त लंच जैसी कोई चीज़ नहीं: तीसरे पक्ष के सॉफ़्टवेयर की छिपी हुई लागत
एक कुंजी डेवलपर वेग में योगदानकर्ता तीसरे पक्ष के सॉफ़्टवेयर को प्रभावी ढंग से शामिल करने की क्षमता बन गई है। इससे डेवलपर्स के लिए स्केलेबिलिटी या इंटरफेस के लिए तैयार घटकों का उपयोग करते समय, उदाहरण के लिए, नवाचार या फ़ंक्शन पर ध्यान केंद्रित करना संभव हो गया है। तृतीय पक्ष सॉफ़्टवेयर के बढ़ते उपयोग ने सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के लिए एक बड़ी चुनौती पैदा कर दी है। आपके स्वयं के मूल्यांकन के लिए उपयोग किए जाने वाले समान मानकों के अनुसार ऐसे कोड का मूल्यांकन करने के अलावा, गाइड किसी भी कमजोरियों के लिए बायनेरिज़ को स्कैन करने और परिणामी जोखिमों का मूल्यांकन करने का सुझाव देता है। इस मूल्यांकन के परिणामों को किसी विशिष्ट सॉफ़्टवेयर घटक का उपयोग करने या न करने के निर्णय में शामिल किया जाना चाहिए। किसी सॉफ़्टवेयर घटक के चयन में उसके स्रोत को भी ध्यान में रखना चाहिए; अपने स्रोत कोड में तीसरे पक्ष के घटकों को शामिल करना एक लंबे रिश्ते की शुरुआत है और आपको उन भागीदारों के साथ काम करने का प्रयास करना चाहिए जिन पर आप भरोसा कर सकते हैं। विश्वसनीय स्रोत का चयन करते समय कोड स्वामित्व, कोडिंग प्रथाएं और संस्करण प्रबंधन नीतियां कुछ बिंदु हैं जिन पर विचार किया जाना चाहिए। जैसे ही नए खतरों का पता चलता है, प्रत्येक घटक के लिए भविष्य के सभी अपडेट, रिलीज़ और रखरखाव कार्य के बारे में सोचें। चुनौती सभी तीसरे पक्ष के परिवर्तनों की निगरानी करना, कमजोरियों का आकलन करना और तदनुसार प्रतिक्रिया देना होगा, कभी-कभी गंभीर समय के दबाव में भी।
एसबीओएम के साथ अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा को बढ़ावा दें
आपकी सॉफ़्टवेयर आपूर्ति श्रृंखला की दीर्घकालिक अखंडता सुनिश्चित करने के लिए एक प्रमुख अभ्यास अद्यतन बनाए रखना है सामग्री का सॉफ्टवेयर बिल (एसबीओएम)। एसबीओएम सॉफ्टवेयर घटकों की एक विस्तृत सूची है जिसमें एक दिया गया समाधान शामिल होता है।
इससे आपका समय और प्रयास बचेगा, और सबसे महत्वपूर्ण बात यह है कि चल रहे खतरों के प्रति आपका जोखिम कम हो जाएगा। आपके उत्पाद में शामिल प्रत्येक सॉफ़्टवेयर घटक को अपने स्वयं के एसबीओएम के साथ आना चाहिए, जिसे सत्यापित किया जाना चाहिए और उत्पाद के लिए एकल 'मास्टर' एसबीओएम में विलय किया जाना चाहिए। यदि आप उन घटकों को शामिल करने का इरादा रखते हैं जो एसबीओएम के साथ नहीं आते हैं, तो आपको सॉफ़्टवेयर कंपोज़िशन विश्लेषण (एससीए) टूल का उपयोग करके अपना स्वयं का विश्लेषण करने की आवश्यकता होगी।
एसबीओएम जितना अधिक सटीक और वर्णनात्मक होगा, इसे बनाए रखना और संदर्भ देना उतना ही आसान होगा। सॉफ़्टवेयर घटकों को अद्यतन करने की तीव्र गति को देखते हुए, a अच्छी तरह से संरचित एसबीओएम जब हर अपडेट, पैच या रिलीज़ को ट्रैक करने और रिकॉर्ड करने का समय आएगा तो लाभांश का भुगतान करेगा। इससे भी महत्वपूर्ण बात यह है कि एक बार सुरक्षा खतरे का पता चलने पर हर क्षण महत्वपूर्ण होता है। याद: आपके सॉफ़्टवेयर आपूर्ति श्रृंखला की सुरक्षा हमेशा आपकी सबसे कमजोर कड़ी की तरह मजबूत रहेगा। जब दर्जनों सॉफ़्टवेयर घटक जोखिम में हों, तो आप उस एसबीओएम के लिए आभारी होंगे जिसके पास सभी उत्तर हैं।
एक कुशल वर्कफ़्लो के लिए, एक उपयोगी एसबीओएम में कम से कम ये तीन घटक शामिल होने चाहिए:
- डेटा फ़ील्ड - ये आपके द्वारा कार्यान्वित किए गए घटकों के विवरणकर्ता हैं। विकास पूरा होने के लंबे समय बाद भी, आसानी से पहचानने में सक्षम होने से कि किन घटकों का उपयोग किया गया है, कमजोरियों के लिए प्रभावी ढंग से निगरानी करने में मदद मिलती है।
- स्वचालन का समर्थन - एसबीओएम की स्वचालित निगरानी के लिए आवश्यक है कि उन्हें स्वीकृत मशीन-पठनीय प्रारूपों में से एक में भी पहचाना जाए।
- अभ्यास और वादे - एसबीओएम को प्रबंधित करने के लिए रखरखाव प्रथाओं की सामान्य समझ की आवश्यकता होती है, जैसे संस्करणों की आवृत्ति, निर्भरता, ज्ञात अज्ञात, वितरण और वितरण, पहुंच नियंत्रण और गलतियों को कैसे समायोजित किया जाए।
किसी विशिष्ट उत्पाद के हितधारकों (सॉफ्टवेयर डेवलपर, सॉफ्टवेयर आपूर्तिकर्ता और ग्राहक) के बीच एसबीओएम साझा करने से पारदर्शिता और संरेखण को बढ़ावा देने में मदद मिलती है, जिससे सुरक्षा खतरों के खिलाफ उत्पाद की रक्षा के लिए सॉफ्टवेयर आपूर्ति श्रृंखला की क्षमता बढ़ जाती है। यह ध्यान दिया जाना चाहिए कि, सॉफ़्टवेयर आपूर्ति श्रृंखला में सभी गतिशील भागों को देखते हुए, ऐसे एसबीओएम को लगातार बनाए रखना - जिसे आसानी से संदर्भित किया जा सकता है, निगरानी की जा सकती है और बनाए रखा जा सकता है - एक जटिल चुनौती है।
अंतिम शब्द: आप अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा को अगले स्तर पर कैसे ले जा सकते हैं?
जैसे-जैसे सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा अधिक से अधिक महत्वपूर्ण होती जा रही है, संगठनों को उनके द्वारा वितरित या उपयोग किए जाने वाले सॉफ़्टवेयर में पारदर्शी विश्वास बनाने के लिए बार-बार चुनौती दी जा रही है। चूंकि सर्वोत्तम अभ्यास के रूप में एसबीओएम को अपनाने की उम्मीद बढ़ रही है, ऐसे उपकरण का होना जो आपको इस चुनौती से निपटने में सक्षम बनाता है, सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा स्थापित करने की दिशा में एक महत्वपूर्ण कदम है। यही कारण है कि हमने हाल ही में सॉफ़्टवेयर उत्पादों के लिए पहला साक्ष्य-आधारित सुरक्षा केंद्र लॉन्च किया है, अपने उपयोगकर्ताओं को टीमों और संगठनों में अपने सॉफ़्टवेयर में विश्वास बनाने में सक्षम बनाना। यह उपयोगकर्ता-अनुकूल प्लेटफॉर्म एसबीओएम को सुलभ, उपयोग में आसान और सबसे महत्वपूर्ण बनाकर सॉफ्टवेयर आपूर्ति श्रृंखला के जोखिमों को कम करने में विकास टीमों की मदद करेगा।सॉफ़्टवेयर उत्पादों की सुरक्षा को ग्राहकों, खरीदारों और सुरक्षा टीमों के लिए पारदर्शी बनाएं.
यदि आप, एक सॉफ़्टवेयर डेवलपर के रूप में, अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के खतरों से चिंतित हैं, तो हम आपसे आग्रह करते हैं प्लेटफ़ॉर्म आज़माएं; इसका उपयोग नि:शुल्क है, इसमें कोई शर्त नहीं है। हमारे वर्कफ़्लो को लागू करके, आप अपने एसबीओएम को अपनी आपूर्ति श्रृंखला में साझा करने में सक्षम होंगे।
यह सामग्री आपके लिए स्क्राइब सिक्योरिटी द्वारा लाई गई है, जो एक अग्रणी एंड-टू-एंड सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा समाधान प्रदाता है - जो संपूर्ण सॉफ्टवेयर आपूर्ति श्रृंखलाओं में कोड कलाकृतियों और कोड विकास और वितरण प्रक्रियाओं के लिए अत्याधुनिक सुरक्षा प्रदान करता है। और अधिक जानें.
संबंधित पोस्ट
