Google ओपन सोर्स सिक्योरिटी में सुधार के लिए नए नियम स्थापित करने का प्रस्ताव रखता है

ओपन सोर्स सॉफ़्टवेयर सुरक्षा ने उद्योग का ध्यान आकर्षित किया हैलेकिन समाधान के लिए चुनौतियों पर आम सहमति और कार्यान्वयन में सहयोग की आवश्यकता होती है।

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

Google इसके कारण बताता है:

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

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

Google द्वारा प्रस्तावित ढांचे के भीतर, इस कठिनाई को तीन बड़े पैमाने पर स्वतंत्र समस्या क्षेत्रों में विभाजित करने का सुझाव दिया गया है, जिनमें से प्रत्येक के विशिष्ट उद्देश्य हैं:

अपने सॉफ़्टवेयर की कमज़ोरियों को जानें

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

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

नई कमजोरियाँ जोड़ने से बचें

कमजोरियाँ पैदा करने से बचना आदर्श होगा और जबकि परीक्षण और विश्लेषण उपकरण मदद कर सकते हैं, रोकथाम हमेशा एक कठिन विषय रहेगा।

यहाँ, Google दो विशिष्ट पहलुओं पर ध्यान केंद्रित करने का प्रस्ताव करता है:

• नई निर्भरता पर निर्णय लेते समय जोखिमों को समझें
• महत्वपूर्ण सॉफ़्टवेयर विकास प्रक्रियाओं में सुधार करें

कमजोरियों को ठीक करें या हटाएँ

Google स्वीकार करता है कि मरम्मत की सामान्य समस्या उसके दायरे से बाहर है, लेकिन प्रकाशक का मानना ​​है कि अभिनेता समस्या के समाधान के लिए और भी बहुत कुछ कर सकते हैं निर्भरता में कमजोरियों के प्रबंधन के लिए विशिष्ट।

इसमें यह भी उल्लेख है: 

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

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

Fuente: https://security.googleblog.com