एसबीओएम कहां से आए? किसी ऐसे व्यक्ति के रूप में जो (मान लें) कुछ बार ब्लॉक के आसपास रहा है, मुझे अक्सर कुछ ‘नया’ सामना करना पड़ता है, जो कुछ ऐसा दिखता है जो मैंने पहले देखा है। प्रश्न के सीधे उत्तर के रूप में, मेरा मानना है कि यह US.gov नहीं था, जब 2021 में व्हाइट हाउस ने साइबर सुरक्षा में सुधार के लिए एक कार्यकारी आदेश जारी किया। सफेद करने के लिए, धारा (4) (ई) (vii): “इस तरह के मार्गदर्शन में मानकों, प्रक्रियाओं, या मानदंड शामिल होंगे … खरीदार को प्रत्येक उत्पाद के लिए एक सॉफ्टवेयर बिल ऑफ मैटेरियल्स (एसबीओएम) सीधे प्रदान करना या इसे सार्वजनिक वेबसाइट पर प्रकाशित करना। ।”
इस विशेष निर्देश, साइबर सुरक्षा के लिए ड्राइवर पर्याप्त रूप से स्पष्ट है, इसमें यह कहना बहुत मुश्किल हो सकता है कि इन दिनों सॉफ़्टवेयर पैकेज में क्या है, ओपन-सोर्स घटकों, सार्वजनिक रूप से उपलब्ध पुस्तकालयों, वेब साइट स्क्रिप्टिंग पैकेजों आदि के साथ क्या है। यदि आप यह नहीं कह सकते कि भीतर क्या है, तो आप निश्चित रूप से यह नहीं कह सकते कि यह सुरक्षित है; और अगर यह पता चलता है कि यह नहीं है, तो आपको भेद्यता या फिक्स के बारे में पता नहीं चलेगा।
लेकिन इससे कहीं ज्यादा। यह समझना कि आपके ऐप में क्या है मोरिया की खानों में उतरने जैसा हो सकता है: सुरंगों और इंटरकनेक्शन के स्तर पर स्तर, डेटा के चूहा रन, शून्य में उतरते हुए छेद, हवा में डिजिटल भाप के ढेर भेजने वाले सिंकहोल्स। यदि आप “हमले की सतह” शब्द के पीछे के अर्थ को समझना चाहते हैं, तो आपको केवल पीटर जैक्सन के फिल्म के दृश्य को याद करना होगा जिसमें लंबे समय से भूली हुई दरारों से अनकही भयावहता उभरती है … हाँ, यह अत्यधिक संभावना है कि आप एक समान, एक बार गौरवशाली के आधार पर सॉफ़्टवेयर चला रहे हैं लेकिन अब छोड़ दिया वास्तुकला।
यह पूरी तरह से उचित है कि अमेरिकी सरकार ने एसबीओएम के रूप में इस तरह के सूचकांक को अनिवार्य करने के लिए देखा। वास्तव में, यह वैध रूप से पूछा जा सकता है कि उन्हें इतना समय क्यों लगा; या वास्तव में, अन्य संगठन प्रस्तावों के लिए अपने अनुरोधों पर ऐसी आवश्यकता क्यों नहीं रख रहे थे? ध्यान दें कि मैं इस तरह की आवश्यकता के बारे में निंदक से बहुत दूर हूं, भले ही मैं दिन-प्रतिदिन की बोलचाल में ऐसी चीज के उभरने के बारे में स्वस्थ रूप से संदेह करता हूं, हालांकि यह हमेशा से रहा है।
चलो कुछ कदम पीछे चलते हैं। मुझे 1980 के दशक में सॉफ्टवेयर वितरण और पुस्तकालय प्रबंधन के साथ काम करना याद है। आज की तुलना में हमारे कुछ फायदे थे: सबसे पहले, सभी सॉफ्टवेयर, कम से कम ऑपरेटिंग सिस्टम के ऊपर सब कुछ हाथ से तैयार किया गया था, पास्कल, सी और सी ++ में लिखा गया था, संकलित, निर्मित और एक विलक्षण इकाई के रूप में वितरित किया गया था। ओह, वो हसीन दिन! कुछ साल बाद भी, जब मैं बर्लिन के एक विकास केंद्र से सॉफ्टवेयर पैकेज ले रहा था, तो जो वितरित किया जा रहा था उसकी सूची वितरण का एक प्रमुख तत्व था।
जो बदला वह सरल है – (समान रूप से हाथ से तैयार की गई) प्रक्रियाएँ हमारे पास नवाचार की दर को बनाए रखने के लिए बहुत धीमी थीं। 1990 के दशक के अंत तक, जब ई-कॉमर्स ने उड़ान भरना शुरू किया, तो सर्वोत्तम अभ्यास पीछे छूट गया: चीजों को तोड़ने और जीएसडी के युग में इसे सही करने के लिए कोई पुरस्कार मौजूद नहीं था। वैसे, यह कोई आलोचना नहीं है: यह पुस्तक द्वारा बहुत अच्छी तरह से काम कर रहा है, लेकिन अगर किताबों की दुकान आपके आस-पास बंद हो रही है क्योंकि यह नवप्रवर्तकों के समान गति से नवप्रवर्तन करने में विफल हो रही है।
बाधित या बाधित होना, निश्चित रूप से, लेकिन तेजी से और ढीले संचालन के परिणाम आज हमारे सामने रखे गए हैं। एक तरफ, मुझे मैनचेस्टर में 150 साल पुरानी संगीत की दुकान Forsyths से अपना पहला गिटार खरीदने की याद आ रही है। “ऐसा नहीं है कि सस्ता अनिवार्य रूप से बदतर होता है,” मुझे चुनने में मदद करने वाले लड़के ने कहा। “यह अधिक है कि गुणवत्ता आश्वासन कम अच्छा है, इसलिए इस बात की कोई गारंटी नहीं है कि आप जो खरीदेंगे वह अच्छी तरह से निर्मित होगा।” इस स्थिति में, क्यूए को एंडपॉइंट्स पर धकेल दिया गया, यानी दुकान सहायक और मुझे, जिन्हें उचित निर्माण और टोन के साथ मध्य-श्रेणी वाले को खोजने से पहले कई उपकरणों के माध्यम से काम करना पड़ा।
उकुले की तरह, इस्तेमाल की गई कारें, और वास्तव में, सॉफ्टवेयर। गुणवत्ता प्रबंधन की आवश्यकता पूर्ण नहीं है, इसमें जरूरी नहीं है कि अगर यह जगह नहीं है तो चीजें गलत नहीं होंगी। हालांकि, इसकी अनुपस्थिति सॉफ्टवेयर वितरण, संचालन और वास्तव में, सुरक्षा प्रबंधन में जोखिम के स्तर को बढ़ाती है। साइबर सुरक्षा जोखिम के बारे में है, और एसबीओएम के बिना किसी एप्लिकेशन को सुरक्षित करने का प्रयास अपने आप में एक जोखिम पैदा करता है – यह वास्तुकला योजनाओं के एक सेट के बिना किसी इमारत की चोरी-प्रूफिंग जैसा है।
लेकिन जैसा कि हम देख सकते हैं, सॉफ्टवेयर वितरण के बेहतर निरीक्षण की आवश्यकता (निरीक्षण जो एसबीओएम को लीक से हटकर प्रदान करेगा) साइबर सुरक्षा से परे है। कुछ समय पहले, मैं DeployHub में ट्रेसी रेगन से सर्विस कैटलॉग के बारे में बात कर रहा था, यानी एप्लिकेशन तत्वों की निर्देशिका और जहां प्रत्येक का उपयोग किया जाता है। जो मैं यहां लिख रहा हूं, उसके साथ बातचीत काफी हद तक मेल खाती है, वह है: जब तक सॉफ्टवेयर मॉड्यूलर रहा है, तब तक उक्त मॉड्यूल को सूचीबद्ध करने और उस सूची को किसी तरह से प्रबंधित करने की आवश्यकता है। यह “भागों की सूची” की धारणा शायद रोमनों की है, यदि पहले नहीं।
क्षमता (किसी एप्लिकेशन के संविधान को जानने के लिए) के कई प्रकार के उपयोग हैं। उदाहरण के लिए, ताकि यदि आवश्यक हो तो आवेदन को खरोंच के लिए पुनर्गठित किया जा सके। सॉफ़्टवेयर कॉन्फ़िगरेशन प्रबंधन सर्वोत्तम अभ्यास में, आपको यह कहने में सक्षम होना चाहिए, “पिछले अगस्त में हम जिस एप्लिकेशन को चला रहे थे, उसके संस्करण को स्पिन करें।” इन सॉफ़्टवेयर-परिभाषित समयों में, आप (वर्चुअलाइज़्ड) हार्डवेयर को कोड के रूप में भी दस्तावेज़ कर सकते हैं, और (GitOps में लाने के लिए) अप्रबंधित कॉन्फ़िगरेशन ट्वीक्स के मामले में वर्तमान में जो चल रहा है उसकी तुलना करें।
यह स्पष्ट रूप से एक बहीखाता में सब कुछ लॉग करने के लिए कुछ नौकरशाही की जरूरत नहीं है। इसके बजाय, और (लेजर-आधारित) ब्लॉकचैन के पीछे के सिद्धांतों से भिन्न नहीं, सब कुछ लॉग होने से आपको उत्पत्ति और उत्तरदायित्व सुनिश्चित करने, समस्याओं का बेहतर निदान करने, परिवर्तनों के शीर्ष पर रखने और सबसे ऊपर, जटिलता-आधारित सुरक्षा के स्तर को बनाने में सक्षम बनाता है। जोखिम। वर्तमान प्रौद्योगिकी चर्चा का अधिकांश भाग दृश्यता पर कार्य करने के बारे में है: उदाहरण के लिए संचालन हलकों में, हम प्रेक्षणीयता और AIOps के बारे में बात करते हैं; ग्राहक-सामना करने वाली स्थितियों में, यह एक सुसंगत दृष्टिकोण बनाने के लिए है।
यदि कभी ऐसा होता है, कि हम जो प्रदान करते हैं, उस पर नज़र रखने की आवश्यकता होती है, तो मूलभूत अंतर गति की आवश्यकता (जो पिछले कुछ दशकों में एजेंडा निर्धारित करता है) से आगे बढ़ने के परिणामों से निपटने की चुनौतियों के लिए स्थानांतरित हो गया है। चीजें तेजी से। जबकि सॉफ्टवेयर डिलीवरी के शुरुआती दिनों में जटिलता मौजूद थी- स्ट्रक्चर्ड डिज़ाइन पर योरडॉन और कॉन्सटेंटाइन का 1975 का पेपर इसे संबोधित करने के लिए मौजूद था- आज की जटिलता अलग है, जिसके लिए एक अलग तरह की प्रतिक्रिया की आवश्यकता है।
पुराने समय में, यह व्यावसायिक आवश्यकताओं को समझने और उन्हें पूरा करने के बारे में था। आवश्यकताओं को समझना अपने आप में एक चुनौती थी, गुंजाइश रेंगने की अपरिहार्य चीखों के साथ क्योंकि संगठनों ने अपने मालिकाना सिस्टम में हर संभव सुविधा का निर्माण करने की कोशिश की। बहस इस बात को लेकर थी कि अधिक कैसे डिलीवर किया जाए – आम तौर पर उपयोगकर्ता सॉफ्टवेयर टीमों पर विश्वास नहीं करते थे कि क्या आवश्यक था, और सब कुछ आशा से धीमी गति से चला। परियोजनाएं पूर्ण थीं, लंबे समय तक चलने के लिए बनाई गई थीं और प्लम पुडिंग की तरह ठोस थीं।
आज, यह संचालन, प्रबंधन और वास्तव में सुरक्षा के बारे में अधिक है। एसबीओएम की आवश्यकता हमेशा से रही है; यह जानने की आवश्यकता के लिए कि क्या दिया गया है, फिर गलत होने पर वापस रोल करें, वही रहता है। लेकिन न जानने के कारण होने वाली समस्याएं परिमाण का एक क्रम अधिक (या अधिक) हैं। यह वही है जो संगठन खोज रहे हैं क्योंकि वे विरासत के तरीकों के लिए खुद को मुक्त करते हैं और क्लाउड-नेटिव अज्ञात में जाते हैं।
आज की बहुत सी बातचीत उन समस्याओं के समाधान के बारे में है जो हमने पैदा की हैं। हम शिफ्ट-लेफ्ट टेस्टिंग, या डिजाइन द्वारा सुरक्षा के बारे में बात कर सकते हैं, जिनमें से प्रत्येक प्रक्रिया में पहले बेहतर समझ हासिल करने के बारे में है, हम छलांग लगाने से पहले देख रहे हैं। हम स्कोप क्रीप से डिलीवरी स्प्रॉल में चले गए हैं, क्योंकि सब कुछ डिलीवर हो जाता है चाहे वह वांछित हो या नहीं। कीप इधर-उधर हो गई है, या यों कहें कि यह आग की नली बन गई है।
जरूरतों को बंद करने के लिए खुद को बंद करने की बजाय अब हमें आउटपुट को बंद करने की जरूरत है। यही कारण है कि एसबीओएम इतने महत्वपूर्ण हैं- इसलिए नहीं कि हर कोई एक सूची पसंद करता है, बल्कि इसलिए कि कुशलतापूर्वक एसबीओएम बनाने की हमारी क्षमता हमारे सॉफ्टवेयर वितरण प्रथाओं की स्थिति और जोखिम के परिणामी स्तरों के लिए किसी भी तरह का लिटमस टेस्ट है।
तो चलिए एसबीओएम बनाते हैं। ऐसा करने में, आइए यह भी समझें कि हमारे सॉफ़्टवेयर स्टैक और कमजोरियों के संदर्भ में खरगोश का छेद कितना गहरा है, और आइए उस समझ का उपयोग लीवर के रूप में करें, ताकि वरिष्ठ निर्णय निर्माताओं को यह विश्वास दिलाया जा सके कि यथास्थिति को बदलने की आवश्यकता है। आइए अपने सॉफ़्टवेयर आर्किटेक्चर का आकलन करें, अपनी आँखें खोलें कि हम बाहरी पुस्तकालयों, ओपन-सोर्स मॉड्यूल और स्क्रिप्टिंग भाषाओं का उपयोग कैसे कर रहे हैं। हमारे पास क्या है, और हम इसे किस पर बना रहे हैं, यह जानने में हमारी अक्षमता के अलावा, आइए कुछ भी बुरा न देखें।
एसबीओएम प्रदान करने के लिए अनुरोध किया गया कोई भी संगठन इसे काम पूरा करने से एक सुस्त व्याकुलता के रूप में या किसी अनुरोध का जवाब देने के एक सामरिक तरीके के रूप में देख सकता है। लेकिन इस रवैये को लेने से जोखिम के साथ-साथ एक चूक का अवसर भी पैदा होता है: मैं ठोस संख्या की पेशकश नहीं कर सकता, लेकिन संभावना है कि एसबीओएम बनाने में आवश्यक प्रयास एक बार के रूप में उकसाने वाली प्रक्रियाओं से बहुत अलग नहीं होंगे जो इसे होने में सक्षम बनाते हैं। सभी सहायक लाभों के साथ बार-बार बनाया गया।
यह “चलो वापस कैसे चीजें हुआ करती थीं” याचिका नहीं है, लेकिन एक साधारण अवलोकन है। दक्षता बढ़ाने और जोखिम को कम करने के लिए सॉफ़्टवेयर गुणवत्ता प्रक्रियाएँ मौजूद हैं, जिनमें से दोनों की लागत जुड़ी हुई है। प्रक्रियाओं को ठीक करें, और SBOM एक उपोत्पाद लाभ बन जाता है। उन्हें गलत समझें, और पूरे व्यवसाय को परिणाम भुगतने होंगे।
