सॉफ्टवेयर विकास एक ऐसा अभ्यास है जिसमें दुनिया भर में अधिक से अधिक लोग लगे हुए हैं। सॉफ्टवेयर बनाने वाली कंपनियां और व्यक्ति दोनों हैं, इसमें से कुछ मालिकाना है, कुछ मुफ्त या ओपन-सोर्स है, और कुछ इन दोनों का एक समामेलन है। चूँकि उपयोगकर्ताओं या उनके सॉफ़्टवेयर की सुरक्षा के लिए ख़तरा ईथर से बाहर नहीं निकलता है जैसे ही किसी चीज़ को पूर्ण घोषित किया जाता है और उत्पादन के लिए भेज दिया जाता है, यह सुरक्षा प्रथाओं के बारे में बात करने का सही समय लगता है जो सुरक्षा जोखिमों को प्रबंधित करने में मदद करेगा जो कि सामने आ सकते हैं विकास प्रक्रिया के दौरान आपका सॉफ़्टवेयर। कई SSDLC (सिक्योर सॉफ्टवेयर डेवलपमेंट लाइफ साइकल) फ्रेमवर्क हैं, जिनमें ये भी शामिल हैं OWASP, सीआईएसए, तथा NIST (एसएसडीएफ)। इस लेख में, हम सॉफ्टवेयर विकास में निहित जोखिम को प्रबंधित करने में आपकी मदद करने के उद्देश्य से कुछ प्रथाओं पर प्रकाश डालने के लिए उन सभी से कुछ उधार लेंगे। यह सोचकर झूठी सुरक्षा की भावना के साथ न रहें कि यह आपके साथ नहीं हो सकता। चेक प्वाइंट 2023 मध्य-वर्ष साइबर सुरक्षा रिपोर्ट से वैश्विक साइबर हमलों में 8% की वृद्धि का पता चलता है 2022 से अधिक, और प्रवृत्ति उलटती नहीं दिख रही है।
सॉफ्टवेयर विकास जीवन चक्र क्या है?
सॉफ़्टवेयर डेवलपर्स का लक्ष्य तेज़, सटीक और सुरक्षित रूप से सॉफ़्टवेयर बनाना है। बेशक, आपको हमेशा ये तीनों नहीं मिल सकते। समय के साथ, विकास प्रक्रिया को कई अलग-अलग चरणों में विभाजित किया गया जो किसी भी सॉफ्टवेयर विकास में फिट हो सकते हैं। इन चरणों को इस प्रकार विभाजित किया जा सकता है:
- आवश्यकता विश्लेषण - हम क्या बनाने जा रहे हैं और क्यों
- प्लानिंग - हम इसे सामान्य शब्दों में कैसे बनाने जा रहे हैं
- सॉफ्टवेर डिज़ाइन - हम इसे वास्तुशिल्प डिजाइन जैसे विशिष्ट संदर्भों में कैसे बनाने जा रहे हैं
- सॉफ्टवेयर विकास - सॉफ्टवेयर लिखना और संकलित करना
- परीक्षण - सुनिश्चित करें कि यह योजना के अनुसार काम करता है
- तैनाती - इसे शिप करें या प्रकाशित करें ताकि अंतिम उपयोगकर्ता इसका उपयोग कर सके
इस चक्र के कुछ अन्य संस्करण भी हैं लेकिन कुल मिलाकर वे बहुत समान हैं। यह याद रखना महत्वपूर्ण है कि चक्र एक बार की चीज़ नहीं है - यह आमतौर पर क्लाइंट को भेजने या क्लाउड पर प्रकाशित करने के बाद समाप्त नहीं होता है। लगभग हमेशा ऐसी समस्याएं होती हैं जिनसे आपको निपटने की आवश्यकता होती है जिसके लिए पुन: डिज़ाइन (एक वर्ग में वापस) की आवश्यकता हो सकती है, बग जिन्हें आपको ठीक करने की आवश्यकता होती है, जिन सुविधाओं को आप जोड़ना चाहते हैं, इत्यादि। आप खुद को कुछ चरणों पर समानांतर रूप से काम करते हुए या बीच में रुककर दोबारा वापस लौटते हुए भी पा सकते हैं। चूँकि कोई भी कदम स्वाभाविक रूप से सुरक्षा-केंद्रित नहीं है, जो सुरक्षा को लगातार विकास प्रक्रिया के साथ जोड़ने के लिए छोड़ देता है और आज की व्यस्त विकास गति में यह पर्याप्त नहीं है।
आपके एसडीएलसी को सुरक्षित करने का महत्व
सुरक्षित सॉफ़्टवेयर विकास का उद्देश्य प्रक्रिया के सभी चरणों में सुरक्षा संबंधी विचारों को शामिल करना है, न कि सुरक्षा को प्रक्रिया में ऐड-ऑन के रूप में मानना। इस तरह सुरक्षा हमेशा एक विचार होनी चाहिए, चाहे आप प्रक्रिया के किसी भी चरण में लगे हों - परियोजना की आवश्यकताओं के बारे में सोचना, वास्तुकला की योजना बनाना, आवश्यक बिल्डिंग ब्लॉक्स और बुनियादी ढांचे पर विचार करना, और कोड विकसित करने के लिए बैठना। इस दृष्टिकोण को कभी-कभी कहा जाता है शिफ्ट-बाएँ सुरक्षा दृष्टिकोण.
यहां, शिफ्ट-लेफ्ट का तात्पर्य विकास प्रक्रिया के दौरान सुरक्षा चिंताओं को वितरित करना और सुरक्षा डिजाइन, कार्यान्वयन और परीक्षण में डेवलपर्स को शामिल करना है।
यह उन डेवलपर्स के लिए डराने वाला हो सकता है जिन्होंने कभी भी सुरक्षा मुद्दों के बारे में नहीं सोचा है कि उन्हें अचानक इससे निपटना पड़े। यदि आवश्यकताओं को कई अच्छी तरह से परिभाषित सर्वोत्तम प्रथाओं में विभाजित किया गया है तो इसे संभालना काफी आसान है। आप इसे एक नई आईडीई चुनने जैसा सोच सकते हैं।
जितनी अधिक अच्छी तरह से परिभाषित आवश्यकताएं और जितने अधिक स्वचालन और व्यापक उपकरण आप नियोजित कर सकते हैं, कार्य उतना ही आसान हो जाएगा।
एसडीएलसी सुरक्षा सर्वोत्तम प्रथाएँ
आपकी विकास प्रक्रिया को किसी विशेष क्रम में सुरक्षित रखने में मदद के लिए यहां कुछ सर्वोत्तम प्रथाएं दी गई हैं:
प्रशिक्षण - कई डेवलपर्स अपने द्वारा लिखे जा रहे कोड पर सुरक्षा संबंधी विचारों को लागू करने और परीक्षण करने के कार्य में असमान महसूस करेंगे। अधिकांश डेवलपर्स जानते हैं कि आपके बैकएंड में दूषित इनपुट डेटा देने से रिमोट कोड सक्रियण हो सकता है, जो कि प्रसिद्ध "ड्रॉप टेबल" की तरह है। हालाँकि, कम ही लोग तृतीयक (या आगे) निर्भरता के लिए बफर ओवरफ्लो परीक्षण या भेद्यता स्कैनिंग से परिचित होंगे। डेवलपर्स प्रशिक्षण के उपयोग से इन ज्ञान अंतरालों को बंद कर सकते हैं। जब डेवलपर्स को सुरक्षा चुनौतियों और संभावित कमजोरियों की गहरी समझ होती है, तो वे अपने दैनिक कोडिंग और परीक्षण में सुरक्षा चिंताओं को शामिल करने के लिए बेहतर ढंग से सुसज्जित होते हैं। यह उस डेवलपर के लिए भी अधिक मायने रखता है जिसने कोड लिखा है और जो इसके कार्य से भली-भांति परिचित है, इसके सुरक्षा अंतरालों पर विचार करना और तदनुसार परीक्षण की योजना बनाना।
स्कैनिंग - आप अपने कोड को समग्र रूप से अधिक सुरक्षित बनाने के लिए कई प्रकार की स्कैनिंग का उपयोग कर सकते हैं। स्थैतिक, गतिशील और इंटरैक्टिव विश्लेषण उनमें से कुछ हैं। स्थैतिक विश्लेषण स्रोत कोड में स्पष्ट कोडिंग खामियों या संभावित सुरक्षा कमजोरियों की तलाश करता है। इसका उपयोग संभावित कमजोरियों, असुरक्षित कोड प्रथाओं और कोडिंग मानकों के उल्लंघन को देखने के लिए किया जा सकता है। यह रन-टाइम इवेंट पर विचार नहीं करता क्योंकि यह केवल कोड सिंटैक्स की जांच करता है। डायनामिक विश्लेषण एप्लिकेशन के चलने के दौरान किसी भी सुरक्षा खामी, कोडिंग दोष और अन्य समस्याओं का पता लगाता है। इसका उपयोग मेमोरी लीक, सबपर ऑपरेशंस और संभवतः अस्थिर इनपुट या प्रक्रियाओं की पहचान करने के लिए किया जा सकता है। ध्यान रखें कि चूंकि इस प्रकार का परीक्षण विशिष्ट इनपुट का उपयोग करके एक निश्चित समय पर किया जाता है, इसलिए परीक्षणों की गुणवत्ता पूरी तरह से उन व्यक्तियों पर निर्भर करती है जिन्होंने उन्हें तैयार किया है। इसका उद्देश्य आपके उपयोगकर्ताओं से पहले ही समस्याओं का पता लगाना है। इंटरएक्टिव विश्लेषण किसी भी संभावित सुरक्षा खामियों और अन्य ब्रेकिंग मुद्दों का पता लगाने के लिए एप्लिकेशन की जांच करता है। यह संभावित कमजोरियों, प्रयोज्य समस्याओं और उपयोगकर्ता इंटरफ़ेस के साथ समस्याओं की तलाश कर सकता है। आप जितने अधिक व्यापक स्कैनिंग टूल का उपयोग करेंगे, आप उतने ही बेहतर सुरक्षित रहेंगे, लेकिन निस्संदेह, विकास की गति में समझौता होता है। चूंकि प्रत्येक एप्लिकेशन अद्वितीय है, इसलिए स्कैनिंग की सही मात्रा और विकास की वांछित गति के बीच संतुलन ढूंढना आप पर निर्भर है। इसके अतिरिक्त, हम आपके एप्लिकेशन का एक संपूर्ण एसबीओएम बनाने और डेटा के उस स्रोत पर विभिन्न स्कैन और रिपोर्ट लागू करने की भी अनुशंसा करते हैं। आपके ऐप की एसबीओएम विरासत होना बहुत विस्तृत घटक और पैकेज जानकारी रखने का एक अच्छा तरीका है जो कई सुरक्षा कारणों से अमूल्य हो सकता है।
कोड समीक्षा - सक्रिय विकास शाखा के साथ संयोजित होने से पहले किसी भी सुरक्षा खामी, कोडिंग गलतियों और अन्य सॉफ़्टवेयर खामियों का पता लगाने के लिए स्रोत कोड की जांच करना कोड समीक्षा के रूप में जाना जाता है। आमतौर पर, कोड लिखने वाले से अधिक विशेषज्ञता वाला एक डेवलपर इस समीक्षा का संचालन करता है। ऐसी समीक्षाएँ यह गारंटी देने में सहायता कर सकती हैं कि कोड अच्छी तरह से लिखा गया है और एप्लिकेशन सुरक्षित है। इसके अतिरिक्त, वे पूरे कोड बेस में एकल मानक और कोडिंग सम्मेलनों (जैसे फ़ंक्शन और चर नाम) के रखरखाव का समर्थन करते हैं।
कम से कम दो जोड़ी आँखों की समीक्षा के बाद मुख्य शाखा में कोड के एकीकरण की अनुमति देना सर्वोत्तम अभ्यास माना जाता है। बेशक, कोड लिखने वाला डेवलपर आंखों की पहली जोड़ी है। यहां तक कि टीम लीडर जैसे उच्च कुशल इंजीनियरों के लिए भी यह फायदेमंद हो सकता है कि कोई और उनके कोड का मूल्यांकन करे। कम से कम यह सुनिश्चित करता है कि एक से अधिक व्यक्ति कोड के प्रत्येक अनुभाग से परिचित हैं। ध्यान रखें कि अत्यधिक तनाव के समय या समय की कमी के समय लोग इस तत्व को त्यागने पर विचार कर सकते हैं। यदि संभव हो, तो इस नियम को अपने सीआई/सीडी के हार्ड-कोडित तत्व के रूप में जोड़ने पर विचार करें ताकि इसे बाईपास न किया जा सके।
परीक्षण - हमें आपको यह बताने की ज़रूरत नहीं है कि समस्या बनने से पहले सुरक्षा खामियों का पता लगाने के लिए आपके कोड का परीक्षण करना कितना महत्वपूर्ण है। अधिकांश कोड परियोजनाएं जटिल और परस्पर जुड़ी हुई हैं, इसलिए यह अनुमान लगाना असंभव है कि एक छोटा सा अंतर अंततः पूरे कोड आधार की सुरक्षा को कैसे प्रभावित कर सकता है।
स्वचालित परीक्षण लिखते समय, हाल ही में उत्पादित कोड की कार्यक्षमता के साथ-साथ कोड बेस के अन्य हिस्सों के साथ किसी भी महत्वपूर्ण बैक-एंड और फ्रंट-एंड इंटरैक्शन को ध्यान में रखें।
SQL इंजेक्शन, क्रॉस-साइट स्क्रिप्टिंग, असुरक्षित डेटा स्टोरेज और अपर्याप्त मेमोरी आवंटन (जिसके परिणामस्वरूप बफर ओवरफ्लो हो सकता है) जैसी कमजोरियाँ सुरक्षा समस्याओं के उदाहरण हैं जिन्हें आम तौर पर परीक्षण में संबोधित किया जाता है। परीक्षण में मेमोरी लीक, सुस्त या अविश्वसनीय प्रदर्शन और प्रयोज्यता का समाधान होना चाहिए। परीक्षण स्वचालित होना चाहिए और सीआई/सीडी पाइपलाइन में एकीकृत होना चाहिए ताकि यूनिट और एकीकरण दोनों परीक्षणों से गुजरे बिना कोई नया संस्करण या अपडेट प्रकाशित न किया जा सके।
स्वतंत्र कलम परीक्षण - कोई भी हर चीज के बारे में नहीं सोच सकता है और डेवलपर्स के रूप में, हम कभी-कभी अपने द्वारा लिखे गए कोड के संबंध में ब्लाइंड स्पॉट विकसित कर लेते हैं। कोड समीक्षा के समान, स्वतंत्र पेन परीक्षण एक नए दृष्टिकोण और आंखों के एक और सेट की आलोचनात्मक जांच करने की अनुमति देता है कि हमने अपने ऐप और हमारे उपयोगकर्ताओं को सुरक्षित करने के लिए क्या किया और क्या सावधानियां बरतीं। इस तरह के परीक्षणों की सिफारिश वर्ष में कम से कम एक बार की जाती है और इसमें बुनियादी ढांचे के मूल्यांकन के साथ-साथ ऐप की कमजोरियां भी शामिल होनी चाहिए।
ओपन-सोर्स का सुरक्षित रूप से उपयोग करें - आज विकास में लगभग सभी सॉफ़्टवेयर में कम या ज्यादा हद तक ओपन-सोर्स सॉफ़्टवेयर शामिल है। ओपन-सोर्स घटक आपके एप्लिकेशन में सीधे या क्षणिक निर्भरता के माध्यम से आयातित कमजोरियों के कुछ प्रमुख कारण हैं। इसके अतिरिक्त, यह न केवल आपके द्वारा उपयोग की जाने वाली लाइब्रेरी है जो आपको खतरे में डाल सकती है - बल्कि यह पुरानी लाइब्रेरी को अपडेट करने या नवीनतम प्रकाशित सीवीई के साथ अद्यतित रहने में भी विफल हो रही है जो आपको प्रभावित कर सकती है। हम संगठन द्वारा उपयोग के लिए अनुमोदित ओपन-सोर्स पैकेजों की एक सूची बनाने और इसे लगातार जांचने और अपडेट करने की सलाह देते हैं। डेवलपर्स को कोई भी पैकेज जोड़ने से रोकना जो वे चाहते हैं, भले ही केवल एक परीक्षण के रूप में, आपको उन कमजोरियों की संख्या में कटौती करने में मदद मिल सकती है जिनसे आपको निपटना पड़ता है।
सुनिश्चित करें कि कमज़ोरियाँ कारनामे में न बदल जाएँ - लगभग कोई भी कोड आधार कमजोरियों से रहित नहीं है। कोई भी अच्छा स्कैन सैकड़ों से लेकर हजारों तक कहीं भी दिखाई देगा। उन सभी को ख़त्म करना असंभव है. यह याद रखना भी महत्वपूर्ण है कि कमज़ोरियाँ शोषण नहीं हैं। सुनिश्चित करें कि आपके पास यह सुनिश्चित करने के लिए एक फ़िल्टरिंग प्रक्रिया है कि आपके द्वारा खोजी गई कोई भी भेद्यता शोषण योग्य खतरा नहीं है और इस सूची को लगातार अद्यतन रखें। इस तरह, आप नवीनतम सीवीई के बारे में चिंतित किसी तीसरे पक्ष या उपयोगकर्ताओं को आश्वस्त कर सकते हैं कि इसका आपके एप्लिकेशन पर कोई प्रभाव नहीं पड़ेगा।
सुरक्षा आपकी मानसिकता से शुरू होती है
सॉफ़्टवेयर विकसित करने के संभवतः उतने ही अलग-अलग तरीके हैं जितने डेवलपर, फ़्रेमवर्क और कोडिंग भाषाएँ हैं। कहने का तात्पर्य यह है कि, अपनी विकास प्रक्रिया को सुरक्षित करने के लिए सर्वोत्तम अभ्यास ढूंढना आसान नहीं है जो प्रासंगिक हो, चाहे आप किसी भी भाषा, क्षेत्र या आईडीई में काम कर रहे हों। उपकरणों की अधिकता से परे, कुछ मालिकाना और कुछ मुफ़्त, सभी 'अगले अपूरणीय सुरक्षा उपकरण' के रूप में आपका ध्यान आकर्षित करने के लिए, सबसे महत्वपूर्ण सुरक्षा उपकरण जिसे आप नियोजित कर सकते हैं वह है आपकी मानसिकता।
अपने डिज़ाइन विकल्पों, वास्तुकला और भंडारण के बारे में सोचें। क्या आपने अपने उपयोगकर्ता आधार में तेजी से वृद्धि के विकल्प पर विचार किया है? क्या आपने अपने कोडबेस और बुनियादी ढांचे के विभिन्न हिस्सों के लिए एक्सेस विशेषाधिकारों को उचित रूप से विभाजित किया है? क्या आपने अपने डेटा या रहस्यों के विरुद्ध लक्षित हमले और सॉफ़्टवेयर आपूर्ति श्रृंखला 'अप्रत्यक्ष' हमले दोनों पर विचार किया?
इससे पहले कि आप अपने आवेदन की योजना बनाएं, इन सभी प्रश्नों और अन्य पर विचार किया जाना चाहिए और जैसे-जैसे कोडबेस और ऐप बढ़ते और विकसित होते हैं, उनका नियमित रूप से पुन: निरीक्षण किया जाना चाहिए।
यह एक सिद्धांत माना जाता है कि किसी भी सॉफ़्टवेयर का सबसे कमजोर हिस्सा उसे चलाने वाला (या लिखने वाला) मानव होता है। अपने एप्लिकेशन, सॉफ़्टवेयर या कोड लाइब्रेरी को साइबर हमलों की एक नई लहर के बढ़ते आंकड़ों का हिस्सा न बनने दें। उचित योजना, उपकरण और स्वचालन के साथ आप साइबर जोखिम के प्रबंधन, अपने विकास जीवन चक्र को सुरक्षित करने और अच्छी तरह से प्रलेखित, व्यापक, कुशल कोड तैयार करने के बीच सही संतुलन पा सकते हैं।