सॉफ़्टवेयर आपूर्ति श्रृंखला के जोखिमों में से एक रहस्य लीक होना है। सॉफ़्टवेयर आपूर्ति शृंखला के चारों ओर रहस्य हैं; डेवलपर्स और सीआई\सीडी पाइपलाइनों को एससीएम, पाइपलाइन, आर्टिफैक्ट रजिस्ट्रियों, क्लाउड वातावरण और बाहरी सेवाओं तक पहुंचने के लिए रहस्यों का उपयोग करने की आवश्यकता है। और जब रहस्य हर जगह हों, तो उनके लीक होने में समय लगता है।
इस जोखिम को अच्छी तरह से पहचाना गया है, और कई सॉफ्टवेयर-आपूर्ति-श्रृंखला ढांचे गुप्त-स्कैनिंग और गुप्त-स्व-समाप्ति की आवश्यकता के द्वारा इसका समाधान करते हैं।
तो, यदि आपने, एक सुरक्षा व्यवसायी के रूप में, इन रेलिंगों को जगह पर लगा दिया है तो क्या गलत हो सकता है?
इस सप्ताह, गुप्त स्कैनिंग टूल पर शोध करते समय, मुझे एक उत्तर मिला। यह उत्तर सरल है: चूंकि गुप्त स्कैनर रहस्यों के पैटर्न की खोज करते हैं, जब गुप्त प्रारूप बदलता है, तो पता लगाना विफल हो सकता है। और ठीक ऐसा ही हुआ जब GitHub ने एक नई सुरक्षा सुविधा पेश की - सुक्ष्म-दानेदार-टोकन. यह बीटा सुविधा गुप्त-लीक जोखिमों को कम करने के लिए GitHub के तरीकों में से एक है; व्यक्तिगत पहुंच टोकन की अनुमतियों को सीमित करने से जोखिम भी सीमित हो जाते हैं यदि इन रहस्यों से समझौता किया गया हो।
इससे पता चलता है कि नए टोकन का प्रारूप थोड़ा अलग है, जबकि पुराने टोकन का प्रारूप कुछ इस प्रकार था:
ghp_123456789012345678901234567890123456
नया टोकन प्रारूप इस प्रकार है:
github_pat_123456789012345678901234567890123456789012345678901234567890…
रहस्य का उपसर्ग और लंबाई दोनों अलग-अलग हैं।
और वास्तव में, कुछ गुप्त स्कैनर नए प्रारूप का पता लगाने में विफल रहते हैं;
प्रयोग करने के लिए, मैंने एक डॉकरफ़ाइल के साथ एक गुप्त और एक वर्कफ़्लो के साथ एक रेपो बनाया जो ट्रिवी एक्शन चलाता है। प्रयोग की शुरुआत में डॉकरफ़ाइल इस प्रकार दिखती है:
निम्नलिखित GitHub सीक्रेट स्कैनर का एक स्नैपशॉट है, जो नए स्वरूपित रहस्य का पता लगाता है:
जैसा कि हम देख सकते हैं, GitHub का गुप्त स्कैनर रहस्य का पता लगाता है, लेकिन कोड स्कैनिंग अनुभाग में कोई अलर्ट दिखाई नहीं देता है।
यह सत्यापित करने के लिए कि टूलींग सही ढंग से सेट है, मैं अब डॉकरफाइल में एक शास्त्रीय रहस्य जोड़ूंगा (नीचे देखें) और स्कैनिंग फिर से चलाऊंगा। अब हमें एक कोड स्कैनिंग अलर्ट मिलता है (केवल क्लासिक सीक्रेट पर!)
दूसरी ओर, जीथब का स्कैनर अब दो रहस्यों का पता लगाता है:
मैंने ट्रिवी के लिए एक सुरक्षा मुद्दा खोला है; ट्रिवी की टीम ने जवाब दिया कि यह कोई भेद्यता नहीं है और न ही कोई सुरक्षा मुद्दा है। एक मुद्दा खोलना बाकी रह गया था।
यह प्रयोग कई चिंताएँ पैदा करता है;
- GitHub उपयोगकर्ता को यह संदेह क्यों होना चाहिए कि एक नई सुविधा के कारण टोकन प्रारूप को संशोधित किया जाएगा?
- यह देखते हुए कि रहस्यों को यादृच्छिक तारों की तरह दिखना चाहिए, एक GitHub उपयोगकर्ता को रहस्यों के प्रारूप की परवाह क्यों करनी चाहिए?
- क्या GitHub को ऐसे बदलाव पर अपने ग्राहकों को अपडेट करने के लिए ज़िम्मेदार होना चाहिए?
- क्या यह गुप्त-पहचान विफलता GitHub के बारीक रहस्यों की भेद्यता है, ट्रिवी की भेद्यता है, या, जैसा कि एक्वा सिक्योरिटी इसे देखती है, बिल्कुल भी भेद्यता नहीं है?
- क्या ट्रिवी के पीछे की कंपनी एक्वा सिक्योरिटी को इसे अद्यतन करने के लिए ज़िम्मेदार होना चाहिए?
- चूंकि ट्रिवी एक ओपन सोर्स प्रोजेक्ट है, जिसकी आपूर्ति वैसे ही की जाती है, क्या ट्रिवी द्वारा संरक्षित पाइपलाइन से रहस्य लीक होने पर कोई उत्तरदायी होगा? यह कौन होगा? गिटहब? एक्वा सुरक्षा? ट्रिवी उपयोगकर्ता?
- सॉफ़्टवेयर आपूर्ति श्रृंखलाओं की सुरक्षा के लिए स्थापित सुरक्षा उपकरणों पर भरोसा करने के बारे में यह प्रयोग हमें क्या सिखाता है?
मैं इन प्रश्नों को खुला छोड़ दूँगा।
हालाँकि, एक बात स्पष्ट है; सॉफ़्टवेयर आपूर्ति श्रृंखला की सुरक्षा करना जटिल है और इस कार्य में स्थायी रूप से सफल होने के लिए हमें एक उच्च पेशेवर समुदाय की आवश्यकता है।
इस पोस्ट का सह-लेखक था एवी वैक्समैन, स्क्राइब सिक्योरिटी में प्रशिक्षु
यह सामग्री आपके लिए स्क्राइब सिक्योरिटी द्वारा लाई गई है, जो एक अग्रणी एंड-टू-एंड सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा समाधान प्रदाता है - जो संपूर्ण सॉफ्टवेयर आपूर्ति श्रृंखलाओं में कोड कलाकृतियों और कोड विकास और वितरण प्रक्रियाओं के लिए अत्याधुनिक सुरक्षा प्रदान करता है। और अधिक जानें.
संबंधित पोस्ट
