स्ट्राइकिंग बैलेंस: 'शिफ्ट लेफ्ट' और एसडीएलसी रेलिंग के साथ सॉफ्टवेयर सुरक्षा को फिर से परिभाषित करना

सभी पद

TL, डॉ

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

मेरा पनीर किसने छोड़ा?

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

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

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

सीआई/सीडी रेलिंग दर्ज करें

यहीं पर सतत एकीकरण/निरंतर परिनियोजन (सीआई/सीडी) पाइपलाइन में सुरक्षा "रेलिंग" लागू करने की आवश्यकता स्पष्ट हो जाती है। रेलिंग विकास पाइपलाइन के भीतर अंतर्निहित स्वचालित चौकियों के रूप में कार्य करती है, यह सुनिश्चित करती है कि सुरक्षा उपाय केवल मैन्युअल हस्तक्षेप या व्यक्तिगत डेवलपर विशेषज्ञता या प्रेरणा पर निर्भर नहीं हैं।

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

नीति-ए-कोड अवधारणाओं का उपयोग करके, कोई भी लगभग कोई भी नियम बना सकता है जिसे वे रेलिंग के रूप में लागू करने की कल्पना कर सकते हैं। यहां रेलिंग नियमों के अनुरूप कुछ उदाहरण दिए गए हैं एनआईएसटी 800-204डी:

रेलिंग उदाहरण

अनुकरणीय रेलिंग नियम:

  1. डेवलपर वर्कस्टेशन
    • डेवलपर वर्कस्टेशन के एंडपॉइंट सुरक्षा सूट को सत्यापित करें
  2. SCM
    • शाखा-सुरक्षा-नियम सत्यापित करें: एकाधिक\विशिष्ट समीक्षाएँ लागू करें
    • सत्यापित करें कि सीआई फ़ाइलें केवल अनुमत कर्मियों द्वारा संशोधित की जाती हैं
    •  सत्यापित करें कि गुप्त स्कैनिंग चल रही है और रहस्यों का पता नहीं चला है।
  3. CI
    • सत्यापित करें कि कोड स्कैनिंग मौजूद है.
    • सत्यापित करें कि कोड स्कैनिंग परिणाम पूर्व-निर्धारित बार के अंतर्गत हैं
  4. निर्भरता
    • ओपन-सोर्स लाइसेंसिंग सत्यापित करें।
    • सत्यापित करें कि ओपन-सोर्स कमजोरियाँ संगठन नीति के अनुरूप हैं
  5. कलाकृतियों
    • सत्यापित करें कि सही पहचान कलाकृतियों पर हस्ताक्षर करती है।
    • अंतिम आर्टिफैक्ट कमजोरियों को सत्यापित करें।

रेलिंग, रेलिंग नहीं

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

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

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

लपेटकर

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

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