यो तेस्रो एपिसोड हो लेखहरूको श्रृंखला सबैभन्दा प्रचलित प्रकारको सफ्टवेयर आपूर्ति श्रृंखला आक्रमणहरूको बारेमा: ती जसले सार्वजनिक रजिस्ट्रीको दुरुपयोग गर्छन् खुला-स्रोत सफ्टवेयर कम्पोनेन्टहरू। अघिल्लो एपिसोडमा विश्लेषण गरेपछि “दुर्भावनापूर्ण प्याकेजहरूको शरीर रचना: प्रवृत्तिहरू के हुन्?"नयाँ वा अवस्थित प्रकाशित कम्पोनेन्टहरूमा खराब व्यवहार कसरी घुसाउँछन् भन्ने कुरालाई ध्यानमा राख्दै, हामी हाम्रो अग्नि नियन्त्रक ज्याकेट लगाउन र यस तरिकाले डेलिभर गरिएको खराब सफ्टवेयरलाई कसरी सफलतापूर्वक ब्लक गर्न सक्छौं, वा वैकल्पिक रूपमा, हामीले गलत दृष्टिकोण अपनाएको कारणले सम्भावित गम्भीर साइबर घटनालाई कसरी सम्बोधन गर्न सक्छौं भनेर जाँच गर्न तयार छौं।"
धेरैजसो सुरक्षा-सचेत पेशेवरहरूसँग यो खतरालाई कसरी सम्हाल्ने भन्ने बारे विचारहरू छन्। हामीले सुरक्षा प्रबन्धकहरूलाई बिना हिचकिचाहट भन्दै सुनेका छौं कि SCA प्याकेज संस्करण मालवेयर कहिले हो भनेर उपकरणहरूले पहिले नै तपाईंलाई बताउँछन्। वा तिनीहरू प्रख्यात, उच्च समीक्षा गरिएका सफ्टवेयर कम्पोनेन्टहरूमा निर्भर हुन्छन्, जहाँ कुनै पनि मालवेयर तुरुन्तै पत्ता लगाइनेछ र हटाइनेछ। तिनीहरूले स्वचालित रूपमा जोखिम समाधानहरू प्राप्त गर्न खुला माइनर/प्याच संस्करणहरू प्रयोग गर्छन्, र त्यो खुला स्रोत निर्भरताहरूमा जोखिम कम गर्ने उचित, सिफारिस गरिएको तरिका हो, "चाँडै प्याच गर्नुहोस्, बारम्बार प्याच गर्नुहोस्"सिद्धान्त।
यस एपिसोडमा, हामी यी विचारहरू किन गलत छन् र त्यस्ता गलत धारणाहरूले यस आक्रमण संयन्त्रको लोकप्रियतामा कसरी योगदान पुर्याइरहेको छ र संस्थाहरूले अनुभव गरिरहेको अत्यधिक जोखिममा कसरी योगदान पुर्याइरहेको छ भनेर समीक्षा गर्नेछौं। हामी के काम गर्छ, र यसमा के प्रयास र स्रोतहरू समावेश छन् भन्ने कुराबाट अन्त्य गर्नेछौं।
सामान्य गलत धारणा
सफ्टवेयर सुरक्षाको हाम्रो यात्राको क्रममा, हामीले आक्रमण प्रविधिहरू विकसित हुँदै गएको र सुरक्षा-सचेत व्यक्तिहरूबाट विचारहरूको विस्तृत दायरा देख्यौं। संस्थाहरूले प्रायः यस खतरा विरुद्ध के काम गर्छ भनेर गलत बुझ्छन्, त्यसैले पहिले हामी के काम गर्दैन भनेर जाँच गर्नेछौं, निम्नमा संक्षिप्त, पूर्ण होइन, गलत धारणाहरूको सूची।
गलत धारणा #1: SCA उपकरणहरूले पहिले नै खराब कम्पोनेन्टहरू रिपोर्ट गर्छन्
वास्तवमा! तर तथ्य पछि… जब सम्भवतः धेरै ढिलो भइसकेको हुन्छ यदि तत्व सफ्टवेयर निर्माणमा प्रयोग गरिएको थियो, र खराब अभिनेताहरूले पहिले नै विकासकर्तामा पाइला राखिसकेका हुन्छन् वा CI/CD होस्ट। गोप्य कुराहरू हटाइएको हुन सक्छ, थप मालवेयर डाउनलोड र स्थापना गरिएको हुन सक्छ, र सायद प्रतिद्वन्द्वी पार्श्वतिर सरेको हुन सक्छ र पहिले नै अन्यत्र पहुँच प्राप्त गरेको हुन सक्छ।
सफ्टवेयर संरचना विश्लेषण (SCA) उपकरणहरू सम्भावित ज्ञात कमजोरीहरू पहिचान गर्न डिजाइन गरिएको थियो। आधुनिक उपकरणहरूले सिग्नल-शोर अनुपात बढाएर, कमजोरी वास्तवमा पहुँचयोग्य छ वा शोषणयोग्य छ कि छैन भनेर निर्धारण गरेर उत्कृष्ट काम गर्छन्। तर नयाँ मालवेयरको विरुद्धमा तिनीहरू बेकार छन्। दुर्भावनापूर्ण घटकलाई शून्य-दिनको कमजोरीको रूपमा सोच्नुहोस्: जब यसको दुर्भावनापूर्ण व्यवहार पत्ता लाग्छ, तब मात्र घटक होल्डिंग रजिस्ट्रीमा रिपोर्ट गरिन्छ, जुन सुरक्षा टोलीद्वारा समीक्षा पछि दुर्भावनापूर्ण रूपमा पुष्टि हुन्छ र रजिस्ट्रीबाट हटाइन्छ। [1].
त्यस समयमा, संसार (सहित SCAs) लाई थाहा छ कि कम्पोनेन्ट (वा अवस्थित कम्पोनेन्टको केही संस्करण(हरू) स्थापना गर्नु वा प्रयोग गर्नु राम्रो कुरा होइन। तर यो तब हुन्छ जब कम्पोनेन्ट रजिस्ट्रीबाट उपलब्ध हुँदैन।। तेस्रो-पक्ष कम्पोनेन्टहरूमा वा रजिस्ट्रीद्वारा दुर्भावनापूर्ण रूपमा वर्गीकृत गरिएका कम्पोनेन्टहरूमा पनि मेरो कमजोरीहरू छन् भन्ने थाहा पाउनु राम्रो हो, तर दुर्भाग्यवश SCA वा सामान्य लेखापरीक्षण उपकरणहरूले यस सन्दर्भमा मद्दत गर्दैनन्। जब सम्म SCA/audit उपकरणले तपाईंको संस्थामा प्रयोग गर्नु अघि नै कुनै कम्पोनेन्ट खराब छ भनेर पहिले नै थाहा पाउन सक्छ।.
सम्झनुहोस्, दुर्भावनापूर्ण खुला-स्रोत कम्पोनेन्टहरू विरुद्धको कुनै पनि समाधानले तिनीहरूलाई पत्ता लगाउनु पर्छ। उडानमा, रजिस्ट्रीमा कम्पोनेन्ट प्रकाशित हुँदा र तपाईंको संस्थामा कम्पोनेन्ट (संस्करण) पहिलो पटक प्रयोग हुँदाको बीचमा। र त्यसमा ट्रान्जिटिभ कम्पोनेन्टहरू समावेश छन्।
गलत धारणा #२: निर्माण समयमा स्थापना स्क्रिप्टहरू नियन्त्रण गर्नाले खुला-स्रोत कम्पोनेन्टहरूबाट हुने दुर्भावनापूर्ण व्यवहारलाई रोक्छ।
विभिन्न प्याकेज प्रबन्धकहरूले स्क्रिप्टहरू चलाउने क्षमता प्रदान गर्छन् (कम्पोनेन्ट टार्बलमा समावेश गरिएको) [2]), वैध कारणहरूका लागि, जस्तै विभिन्न प्लेटफर्महरूमा आवश्यक वस्तुहरू संकलन गर्ने, कोड उत्पन्न गर्ने, वा परीक्षणहरू चलाउने, र हामी सबैलाई थाहा हुनुपर्छ कि यदि दुर्भावनापूर्ण स्क्रिप्टहरू टार्बलमा समावेश गरिएका छन् भने, वा आक्रमणकारीले राम्रोको सट्टा दुर्भावनापूर्ण स्क्रिप्ट चलाउन सक्छ भने तिनीहरू खराब अभिनेताहरूद्वारा दुरुपयोग हुन सक्छन्।
यो थाहा पाएर, हामी प्याकेज प्रबन्धकलाई स्क्रिप्टहरूलाई बेवास्ता गर्न कन्फिगर गर्न सक्छौं। उदाहरणका लागि, NPM सँग -स्क्रिप्टहरूलाई बेवास्ता गर्नुहोस् झण्डा (वा कन्फिगरेसन गुण .npmrc फाइल) स्थापनाको समयमा स्क्रिप्टहरू छोड्छ। यसले केही समस्याहरू उत्पन्न गर्न सक्छ किनभने धेरै इकोसिस्टमहरूमा स्क्रिप्टहरू चलाउनु सामान्य छ: केही प्याकेज प्रबन्धकहरूले स्क्रिप्ट कार्यान्वयन असक्षम पार्न पनि अनुमति दिँदैनन् (संकेत: प्रम्प्ट "कुन प्याकेज प्रबन्धकहरूले स्थापना स्क्रिप्टहरूको कार्यान्वयन असक्षम पार्न अनुमति दिँदैनन्?"तपाईंको मनपर्ने AI मा)। तर यसले सामान्य रूपमा सुरक्षा गर्दैन (हामीले स्किप असक्षम कन्फिगरेसन जताततै लागू गर्न आवश्यक छ)।
र जब दुर्भावनापूर्ण व्यवहार स्थापना स्क्रिप्टहरूमा नभई रनटाइममा कार्यान्वयन गर्न सफ्टवेयरमा अवस्थित हुन्छ, यो विकल्पले मात्र हामीलाई सुरक्षित गर्दैन।
गलत धारणा #३: संस्करण पिनिङले खराब कम्पोनेन्टहरू स्थापना हुनबाट रोक्छ
प्रारम्भिक प्याचिङ र प्रायः प्याचिङ बीच एक सम्झौता छ खुला संस्करणहरू (सुरक्षा समाधानको लागि उपलब्ध हुँदा प्याकेज प्रबन्धकलाई स्वचालित रूपमा नयाँ अपडेटहरू स्थापना गर्न अनुमति दिँदै) र संस्करण पिनिङ (एक निश्चित संस्करणमा सफ्टवेयरको लागि सबै प्रत्यक्ष र ट्रान्जिटिभ निर्भरताहरू भएको)। सुरक्षा सिद्धान्तहरू जिद्दी र कहिलेकाहीं विरोधाभासी छन्, जस्तै "प्याच प्रारम्भिक, प्याच प्रायः" र "स्तरवृद्धिलाई हल्का रूपमा लिनु हुँदैन"। केही प्याकेज प्रबन्धकहरूले सिफारिस गरिएको तरिकाले सर्भर दायराहरूसँग स्वचालित अद्यावधिकहरू गर्छन्। यदि तपाईं पनि दुर्भावनापूर्ण अद्यावधिकहरू प्राप्त गर्न चाहनुहुन्छ भने राम्रो! हो, सुरक्षा समाधानहरू प्राप्त गर्न कम्पोनेन्टहरू अद्यावधिक हुनुपर्छ जसले कमजोरीहरूलाई सकेसम्म चाँडो बन्द गर्दछ, तर ... प्याकेज प्रबन्धकलाई कहिल्यै स्वचालित रूपमा यो गर्न नदिनुहोस्।
गलत धारणा #४: विश्वसनीय कम्पोनेन्टहरू प्रयोग गर्नु सुरक्षित छ। कुनै पनि दुर्भावनापूर्ण संस्करण तुरुन्तै फेला पारिनेछ, खुलासा गरिनेछ र हटाइनेछ।
कुनै कम्पोनेन्टलाई किन विश्वास गरिन्छ? सम्भवतः किनभने यो अत्यधिक लोकप्रिय छ, धेरै आँखाहरूले कमजोरीहरू खोजिरहेका छन्, मर्मतसम्भारको लागि योगदानकर्ताहरूको ठूलो संख्या छ, धेरै मुख्य मर्मतकर्ताहरू छन् जसले सबैलाई लगनशीलतापूर्वक समीक्षा गर्छन्। pull requests। वास्तविकता एकदमै फरक छ। केही आवश्यक घटकहरू एकल, भुक्तानी नगरिएको विकासकर्ताद्वारा मर्मत गरिन्छ। व्यापक रूपमा प्रयोग हुने फ्रेमवर्कहरूमा केही नियमित योगदानकर्ताहरू, द्रुत गतिमा घट्दो संख्याको साथ commitप्रति मर्मतकर्ता (लोकप्रिय परियोजनाहरूमा योगदानकर्ताहरूको लामो पुच्छर हुन्छ जसले केही ड्राइभ-बाई प्रदर्शन गर्दछ) commit र कहिल्यै फर्केर आउँदैनन्)। र एउटै मर्मतकर्ता भएका लोकप्रिय परियोजनाहरू प्रशस्त छन्।
कल्पना गर्नुहोस्, आफैँ भन्नुहुन्छ "ओह, हामी स्प्रिंग बुट / एङ्गुलर / रियाक्ट / पाइटोर्च / आधिकारिक आधार डकर छविहरू प्रयोग गर्दैछौं, त्यसैले तपाईंले कुरा गरिरहनुभएको जोखिम एकदम कम छ।" सायद यो सत्य हो, हामी सुरक्षा विक्रेताहरू सधैं डराउने काम गर्छौं, र बहसयोग्य जोखिम कम गर्न विकास टोलीहरूमा हस्तक्षेप गर्नु मूर्खता हो। तपाईं जोखिम स्वीकृति अनुच्छेद (अर्को खण्डमा) मा जान प्रलोभनमा पर्न सक्नुहुन्छ र सबै सकियो। दुर्भाग्यवश, सबैभन्दा लोकप्रिय घटकहरू खराब अभिनेताहरूको लागि लक्षित हुन्, र उदाहरणका लागि, लोकप्रिय पाइटोर्च पुस्तकालयमा आक्रमण भयो विगतमा।
"तुरुन्तै फेला पारियो, खुलासा गरियो, र हटाइयो"। सार्वजनिक रजिस्ट्रीबाट नयाँ दुर्भावनापूर्ण कम्पोनेन्ट हटाउन दिन लाग्छ। रजिस्ट्रीहरू राम्रोको लागि कम्पोनेन्ट संस्करण हटाउन सावधान रहन्छन्। हाम्रो अनुभव यो छ कि हाम्रो तर्फबाट रिपोर्ट गरिसकेपछि, प्रभावित संस्करण हटाउन रजिस्ट्रीको लागि औसत समय ३९ घण्टा हुन्छ, डेढ दिन भन्दा बढी। त्यहाँ दुर्भावनापूर्ण कम्पोनेन्टहरू छन् जुन हटाउनु अघि रजिस्ट्रीमा हाम्रो प्रारम्भिक रिपोर्टिङ पछि एक हप्ता हुन्छ। र केही अवस्थामा, पीडित वा घटना प्रतिक्रिया कम्पनीले कम्पोनेन्टसँग सम्बन्धित घटना रिपोर्ट गरेपछि मात्र कम्पोनेन्ट हटाइन्छ।
दुर्भावनापूर्ण कम्पोनेन्टहरू विरुद्ध के काम गर्दैन
कुनै पनि अस्पष्ट दृष्टिकोण नराम्ररी असफल हुनेछ। यो निश्चित छ, तपाईंले यस खतरासँग सम्बन्धित जोखिमको लागि प्रभावकारी प्रतिरोधात्मक उपायहरू प्रदान गरिरहनुभएको छैन।
परम्परागत SCA उपकरणहरूले तपाईंलाई ज्ञात मालवेयरको बारेमा बताउँछन् तर तिनीहरूसँग ठूलो एक्सपोजर विन्डो हुन्छ। जबसम्म तिनीहरूले मालवेयर पत्ता लगाउन सक्रिय रूपमा मालवेयर कम्पोनेन्टहरूको जबरजस्ती ब्लकिङ गर्दैनन्, तिनीहरू यो खतरा विरुद्ध काम गर्दैनन्।
स्थापना स्क्रिप्टहरू असक्षम पार्नाले मद्दत गर्न सक्छ तर कम्पोनेन्ट स्थापना गर्न आवश्यक पर्ने सबै ठाउँमा लागू गर्न आवश्यक छ। संस्करण पिनिङको साथ पनि त्यस्तै हो, किनकि संस्करणहरूलाई सुरक्षित प्रारम्भिक अवस्थाबाट सधैंभरि पिन गर्न सकिँदैन।
आपूर्ति शृङ्खला आक्रमणमा कुनै पनि क्षति रोक्नको लागि लगभग तुरुन्तै पत्ता नलागेर लोकप्रिय कम्पोनेन्टहरूले पर्याप्त ध्यान पाउँछन् र तिनीहरूलाई अनावश्यक व्यवहारको साथ इंजेक्ट गर्न सकिँदैन भन्ने अनुमान गर्नु मूर्खतापूर्ण र जोखिमपूर्ण छ। तपाईं किनारमा बस्न चाहनुहुन्न, हैन?
यदि तपाईं यस बिन्दुमा रोकिनुभयो भने, त्यसपछि जोखिम स्वीकृति तपाईंले गर्न सक्ने एक मात्र कुरा हो: यो एउटा डे होcisजोखिम स्वीकार गर्ने औचित्य र यसको सम्भावित प्रभावहरू सहित, तपाईंको खतरा मोडेल/जोखिम मूल्याङ्कनमा दस्तावेजीकरण गर्न आवश्यक पर्ने आयन। व्यवस्थापन र अन्य सम्बन्धित पक्षहरूलाई यो जानकारी गराएर जागरूकता बढाउनुहोस्। केही आकस्मिकता तपाईंको सफ्टवेयरमा कुनै दुर्भावनापूर्ण कम्पोनेन्ट स्थापना वा समावेश गर्दा योजना बनाउन सकिन्छ, तर यो गाह्रो छ किनभने आक्रमणकारीहरूले धेरै बाटोहरू पछ्याउन सक्छन्। दुर्भावनापूर्ण कम्पोनेन्टको प्रयोगमा आधारित आपूर्ति श्रृंखला आक्रमणको विवरणले घटनाको सार्वजनिक खुलासामा आमूल परिवर्तन ल्याउनेछ, जुन सम्भवतः तपाईंको संस्थाको नियामक ढाँचा अन्तर्गत अनिवार्य छ। तपाईंले पनि सम्बोधन गर्न सक्नुहुन्छ क्षतिपूर्ति नियन्त्रणहरू or स्थानान्तरण जोखिम जस्तै बीमाको साथ।
यद्यपि, त्यहाँ खतरालाई सम्बोधन गर्ने नियन्त्रणहरू छन् र यदि तपाईं जोखिम स्वीकृतिसँग सन्तुष्ट हुनुहुन्न भने विचार गर्नुपर्छ। कृपया पढिरहनुहोस्।
दुर्भावनापूर्ण कम्पोनेन्टहरू प्रयोग गरेर आक्रमणहरू विरुद्ध के काम गर्छ?
ठोस संस्करण ह्यान्डलिङ
मालवेयर प्राप्त नगरी कमजोरीहरू हटाउने आवश्यकतालाई सन्तुलनमा राख्न नियन्त्रित र सूचित संस्करण बम्पहरू सहित संस्करण पिनिङ गर्नु उत्तम तरिका हो। तर गलत धारणा #३ सम्झनुहोस्: नयाँ संस्करणहरूबाट आउने दुर्भावनापूर्ण कोडलाई रोक्नको लागि संस्करण पिनिङ मात्र पर्याप्त छैन, किनकि तपाईंले भविष्यमा कुनै पनि प्रत्यक्ष वा अप्रत्यक्ष निर्भरतामा संस्करणहरू अद्यावधिक गर्न आवश्यक पर्नेछ। त्यस क्षणमा तपाईंलाई पर्याप्त बलियो प्रमाण चाहिन्छ कि सबै परिमार्जित संस्करणहरूमा मालवेयर छैन।
प्रारम्भिक चेतावनी
दुर्भावनापूर्ण कम्पोनेन्टहरूको समस्याको समाधान गर्ने एउटा तरिका भनेको प्रारम्भिक चेतावनी प्रणाली हो (यहाँ नाम दिइएको छ मालवेयर सम्बन्धी प्रारम्भिक चेतावनी वा MEW), जहाँ प्रकाशित नयाँ संस्करणहरू (नयाँ वा अवस्थित कम्पोनेन्टहरूको लागि) पत्ता लगाउने इन्जिनद्वारा विश्लेषण गरिन्छ, जसले पर्याप्त प्रमाण फेला परेपछि नयाँ संस्करणलाई सम्भावित रूपमा दुर्भावनापूर्णको रूपमा वर्गीकृत गर्न सक्छ।
स्वचालन यहाँ आवश्यक छ, किनकि हालको प्रकाशन दरमा सबै नयाँ कम्पोनेन्टहरूको म्यानुअल रूपमा समीक्षा गर्न असम्भव छ। त्यसैले पत्ता लगाउने इन्जिनले विभिन्न प्रविधिहरू संयोजन गर्न आवश्यक छ, जसमा सम्भवतः स्थिर, गतिशील, र क्षमता विश्लेषण, प्रयोगकर्ता प्रतिष्ठा, र कम्पोनेन्ट मेटाडेटा र टार्बल सामग्रीहरू बीचको भिन्नताबाट आउने प्रमाणहरू, वा टार्बल र स्रोत भण्डार बीचको भिन्नताहरू समावेश छन् जहाँ कम्पोनेन्ट अनुमानित रूपमा आउँछ।
त्यहाँ एउटा अँध्यारो क्षेत्र प्रकाशन समय र इन्जिनले कम्पोनेन्ट सामग्रीहरूको विश्लेषण गर्ने समय बीचको समय, तर यो केही मिनेटभन्दा बढी हुनुहुँदैन। योजना परिमार्जन गर्न सकिन्छ, उदाहरणका लागि, नयाँ कम्पोनेन्टहरूको विश्लेषणको लागि पर्खेर तिनीहरूलाई स्थापना गर्न र सफ्टवेयर निर्माणमा प्रयोग गर्न अनुमति दिनु अघि। pipelines, वा आवश्यकता अनुसार विश्लेषण गर्नुहोस्। दिइएको संस्करणमा कम्पोनेन्ट अपरिवर्तनीय हुन्छ [3], त्यसैले यसलाई एक पटक मात्र विश्लेषण गर्न आवश्यक छ।
पूर्ण स्वचालन सम्भव छैन, र सम्भावित रूपमा खराब कम्पोनेन्टहरूको लागि सुरक्षा समीक्षा आवश्यक छ। डिजिटल रामबाण औषधिका समर्थकहरूबाट सावधान रहनुहोस्: एआई र मेसिन लर्निङ पर्याप्त रूपमा विकसित भएका छैनन् कि शंकास्पद कम्पोनेन्टमा मालवेयर छ कि छैन भनेर पुष्टि गर्ने कुरामा अन्तिम शब्द लिने। पक्कै पनि, कब्जा गरिएका कच्चा प्रमाणहरूबाट इनपुट कम्पोनेन्ट वर्गीकरण गर्न पत्ता लगाउने इन्जिनमा मेसिन लर्निङले महत्त्वपूर्ण भूमिका खेल्छ, तर एक पटक कम्पोनेन्ट "क्वारेन्टाइन" भएपछि अन्तिम शब्द दुर्भावनापूर्ण कम्पोनेन्टहरूमा अनुभव भएको सुरक्षा टोलीद्वारा म्यानुअल समीक्षामा हुन्छ। यसले कुनै पनि सम्भावित मालवेयर पुष्टि गर्छ वा यसलाई सुरक्षितको रूपमा पुन: वर्गीकृत गर्छ। र समय अवधि घण्टा दायरामा छ।
रजिस्ट्रीले दुर्भावनापूर्ण संस्करण/घटकको बारेमा रिपोर्ट गर्छ; त्यसपछि रजिस्ट्रीले पुष्टि गर्न यसको समीक्षा गर्छ र सार्वजनिक खुलासा र रजिस्ट्रीबाट हटाउन अगाडि बढ्छ। केही रजिस्ट्रीहरूले सुरक्षा होल्डिङ प्याकेज राख्छन्। यहाँ समय दायरा प्रकाशन पछिका दिनहरू वा हप्ताहरू हुन्, जुन 'बस्ने समय'or'एक्सपोजर विन्डो' धेरैजसो दुर्भावनापूर्ण घटकहरूको लागि।
के कम्पोनेन्ट संस्करण दुर्भावनापूर्ण छ कि छैन भनेर जान्न सम्भव छ?
त्यसैले प्रारम्भिक चेतावनीको लागि, हामीले यो प्रश्नको सन्तोषजनक उत्तर दिन आवश्यक छ: म कसरी थाहा पाउन सक्छु कि पुस्तकालय वा प्याकेज (दुर्भावनापूर्ण) छ (छैन)? दुर्भावनापूर्ण व्यवहारको पर्याप्त प्रमाण कसरी जम्मा गर्ने? सम्भव छ, तर गाह्रो छ, किनकि विरोधीहरूले पत्ता लगाउनबाट बच्न धेरै चतुरता प्रयोग गर्छन्। त्यहाँ फरक दृष्टिकोणहरू छन्, प्रत्येकको फाइदा र बेफाइदाहरू छन्।
स्थिर विश्लेषण सबै कार्यान्वयन मार्गहरूको जाँच गर्न सक्छ कम्पोनेन्ट नचलाइकन आक्रमणकारीहरूले प्रयोग गर्ने प्रविधिहरूको जाँच गर्न सक्छ, र डि-अस्पष्टीकरण वा डिसिफरिङ जस्ता पूर्व-प्रोसेसिङ कार्यहरू गर्न सक्छ। आक्रमणकारीहरूले आफ्नो दुष्कर्म लुकाउन खोज्दा, अस्पष्टीकरण प्रयासहरू वास्तवमा मालवेयरको प्रमाण हुन् (तर ध्यान दिनुहोस् कि वैध घटकहरूले बौद्धिक सम्पत्ति संरक्षणको लागि कोडलाई अस्पष्ट बनाउँछन्, "" को विरोधाभास गर्दछन्।खुला स्रोत")। बलियो अस्पष्टता भएका अति परिष्कृत आक्रमणहरूको अल्पसंख्यकलाई मात्र स्यान्डबक्सिङ आवश्यक पर्दछ, तर यस्तो बलियो अस्पष्टता दुर्भावनापूर्णताको संकेत हो। कृपया ध्यान दिनुहोस् कि परम्परागत SAST उपकरणहरू अनजानमा हुने कमजोरीहरूका लागि डिजाइन गरिएका थिए, पछाडिको ढोका जस्ता दुर्भावनापूर्ण उद्देश्यका लागि होइन।
गतिशील विश्लेषण कम्पोनेन्ट चलाउँछ र रनटाइम इन्स्ट्रुमेन्ट गरेर प्रतिक्रियाको जाँच गर्छ, सामान्यतया स्यान्डबक्स गरिएको वातावरण प्रदान गरेर। केही अवस्थाहरूमा सुरु भएको दुर्भावनापूर्ण व्यवहार पत्ता नलागेर जान सक्छ: कृपया ध्यान दिनुहोस् कि मालवेयरले चोरी गर्ने तरिकाहरू प्रयोग गर्न सक्छ जस्तै भर्चुअलाइजेसन/स्यान्डबक्स चोरी छानबिनमा नभएको बेला मात्र सक्रिय गर्न, र कुनै पनि स्थिर विश्लेषण इन्जिनको लागि दुर्भावनापूर्ण गतिविधिको संकेत पनि।
क्षमता विश्लेषण कम्पोनेन्टले के गर्छ भन्ने कुरा विचार गर्छ: यो कहाँ जडान हुन्छ, कुन फाइलहरूमा पहुँच गर्छ, कुन आदेशहरू वा कार्यक्रमहरू चलाइन्छ, टर्मिनल वा उपकरण I/O प्रदर्शन गरिन्छ, वा कुन प्रणाली कलहरू आह्वान गरिन्छ। व्यवहारको यो फिंगरप्रिन्टिङलाई संस्करणहरूमा (अवस्थित कम्पोनेन्टको लागि) तुलना गर्न सकिन्छ, त्यसैले जब अप्रत्याशित व्यवहार पत्ता लाग्छ, त्यो प्रमाणले नयाँ संस्करणमा इन्जेक्ट गरिएको सम्भावित दुर्भावनापूर्ण गतिविधिको शंका बढाउन सक्छ। यो दृष्टिकोणले सम्भावित मालवेयरको सामना गर्दा सुरक्षा विश्लेषकहरूले पालना गर्ने ट्राइज चरणहरू पछ्याउँछ: प्रयोग गरेर निरीक्षण तार वा यस्तै उपकरणहरू। यो दृष्टिकोणले ट्रिगर गर्ने अवस्थाहरूको पर्वाह नगरी दुर्भावनापूर्ण व्यवहार पत्ता लगाउँछ र कुनै स्रोत कोड उपलब्ध नभएको बेला काम गर्छ।
सन्दर्भ विश्लेषण कम्पोनेन्ट कसरी प्रकाशित भयो र कसले प्रकाशित गर्यो भन्ने बारे जानकारी सङ्कलन गर्दछ। खराब अभिनेताहरूको अभियानले प्रायः नयाँ प्रयोगकर्ता खाता(हरू) प्रयोग गर्दछ जुन कुनै कडा जाँच प्रक्रियाको अधीनमा हुँदैन। विगतको गतिविधि ट्र्याक गर्नाले अन्तर्निहित प्रयोगकर्तामा अन्तर्दृष्टि दिन सक्छ, प्रायः सम्भावित सम्झौतामा संकेत गर्ने विसंगतिहरूको लागि। प्रतिष्ठा कमाउन धेरै गाह्रो छ र गुमाउन धेरै सजिलो छ! विगतको गतिविधि नभएको प्रयोगकर्ता तटस्थ हुन्छ, तर कर्मले दुष्टलाई पछ्याउँछ। ह्याक्टिभिस्टहरू, वा सामान्य प्रयोगकर्ताहरू जसको प्रकाशन प्रमाणहरू चोरी भएका छन् तिनीहरूलाई सावधानीपूर्वक ट्र्याक गर्नुपर्छ।
अर्को प्रासंगिक जानकारी भनेको कम्पोनेन्ट टार्बल सिर्जना गर्न प्रयोग गरिएको स्रोत भण्डार र टार्बलको सामग्रीहरू बीचको कुनै पनि भिन्नता हो। र सार्वजनिक रजिस्ट्रीमा प्रकाशित कम्पोनेन्टको संस्करणहरूसँग मिल्ने स्रोत भण्डारमा ट्यागहरू वा रिलीजहरू सिर्जना गर्ने जस्ता राम्रा अभ्यासहरू पनि पालना गर्नु हो। जब कुनै विशेषमा स्रोत भण्डार commit रिलिजको साथ ट्याग गरिएको छ, र त्यसपछि अचानक एउटा संस्करणले यसलाई पछ्याउन असफल हुन्छ, त्यो मात्र बलियो प्रमाण हो कि कम्पोनेन्ट दूषित हुन सक्छ: खराब अभिनेताले कम्पोनेन्ट प्रकाशित गर्न प्रयोग गरिएको खातासँग सम्झौता गरेको हुन सक्छ, तर स्रोत कोड भण्डारमा कुनै लेखन अनुमति छैन)। धेरै आक्रमणहरू नियमित रूपमा यी नियमहरू प्रयोग गरेर पत्ता लगाइन्छ: उदाहरणका लागि, लेजर आक्रमण यी लाइनहरूमा सजिलै पत्ता लगाउन सकिन्छ। त्यसकारण, सन्दर्भ विश्लेषणले प्रकाशन प्रक्रियामा त्यस्ता विसंगतिहरू पहिचान गर्दछ।
निर्भरता फायरवालिङ
एउटा फरक दृष्टिकोण भनेको तपाईंको सफ्टवेयरमा प्रयोग हुने सबै निर्भरता ग्राफहरूको लागि कम्पोनेन्टहरूको विस्तृत श्वेतसूची राख्नु हो, त्यसैले कुनै पनि निर्माणमा pipeline तपाईंको संस्थामा चलाउन अनुमोदित कम्पोनेन्ट संस्करणहरू मात्र स्थापना र प्रयोग गर्न सकिन्छ। “फायरवाल"" लाई आन्तरिक रजिस्ट्री प्रयोग गरेर लागू गरिन्छ जहाँ अनुमति दिइएको कम्पोनेन्ट संस्करणहरूको लागि टार्बलहरू सेवा गरिन्छ (क्यास वा प्रोक्सी गरिएको)। कृपया ध्यान दिनुहोस् कि कुनै पनि श्वेतसूचीले काम गर्ने छैन जबसम्म तपाईंसँग कुनै पनि नयाँ संस्करणलाई उचित रूपमा सुरक्षितको रूपमा वर्गीकरण गर्ने प्रविधि छैन ताकि यसलाई श्वेतसूचीमा थप्न सकियोस्।
कृपया ध्यान दिनुहोस् कि प्रारम्भिक चेतावनी (नयाँ संस्करण प्रकाशन पछि सकेसम्म चाँडो पत्ता लगाउने) लाई निर्माणलाई असर गर्ने घटकलाई रोक्नको लागि त्यो जानकारीलाई सक्रिय रूपमा प्रयोग गर्ने कुनै तरिकासँग जोड्न आवश्यक छ। pipelines वा विकासकर्ताहरूको मेसिनहरू [4]। हामी यसलाई "निर्भरता फायरवालिङ": स्वचालित निर्माणहरूलाई दुर्भावनापूर्ण प्याकेजहरूबाट जोगाउनको लागि क्वारेन्टाइन संयन्त्र। आन्तरिक प्याकेजहरू र छवि रजिस्ट्रीहरू बाह्य दुष्टताबाट संस्थाहरूलाई अलग गर्न राम्रो हुन्छन्, तर क्वारेन्टाइनलाई प्रभावकारी बनाउन पर्याप्त बलियो प्रमाण आवश्यक पर्दछ।"
रनटाइम स्यान्डबक्सिङ
प्रकाशन समयमा पत्ता लगाउने एउटा वैकल्पिक दृष्टिकोण भनेको रनटाइममा व्यवहारको विश्लेषण गर्नु हो। यसको विचार भनेको सफ्टवेयरबाट अपेक्षित व्यवहार खिच्नु र फेला परेका कुनै पनि विसंगतिहरू पत्ता लगाउनु (वा ब्लक) हो। यस कार्य लाइनमा निगरानी वा ब्लक गर्न रनटाइमलाई उपकरण बनाउनु पर्ने समस्या छ, र यो एक आशाजनक विचार हो जुन दुर्भावनापूर्ण घटक कीट विरुद्ध सुरक्षा संयन्त्रको शस्त्रागारमा थपिनेछ।
बृहत् रणनीति तय गर्ने
सिफारिस गरिएको रणनीतिले सफ्टवेयर विकास प्रक्रियामा विभिन्न प्रविधिहरू संयोजन गर्न आवश्यक छ, आगमन दुर्भावनापूर्ण कम्पोनेन्टहरूलाई रोक्न संस्करण अद्यावधिकहरूको नियन्त्रण लिनु आवश्यक छ। महत्त्वपूर्ण कमजोरीहरूको समाधान प्राप्त गर्न संस्करणहरू अद्यावधिक गर्दा स्वचालित संक्रमणबाट बच्न हामीले संस्करण पिनिङलाई समायोजन गर्नुपर्छ; संस्करण अद्यावधिकहरूको समयमा प्रत्यक्ष र अप्रत्यक्ष निर्भरताहरूको द्रुत र कुशल मूल्याङ्कन गर्नाले तिनीहरू मालवेयर-ग्रस्त छैनन् भन्ने पर्याप्त प्रमाण हुन्छ। ज्ञात दुर्भावनापूर्ण कम्पोनेन्टहरूमा निर्भर सफ्टवेयरको निर्माणहरू अवरुद्ध हुनुपर्छ। र सबै लागू गर्नुपर्छ।
सम्भव भएसम्म संस्करण पिनिङ प्रयोग गर्नुहोस्, किनकि यसले निर्माणहरूलाई अझ पुनरुत्पादनयोग्य बनाउँछ। नियन्त्रित, म्यानुअल रूपमा अनुमोदित संस्करण बम्पहरू सहित संस्करण पिनिङ, र सहायक प्रविधिद्वारा सहयोग गरिएको, ले अपडेटले मालवेयर ल्याउँछ वा सफ्टवेयर बिगार्छ कि भनेर मूल्याङ्कन गर्नुपर्छ, र मालवेयर संक्रमणबाट बच्न कमजोरीहरू समाधान गर्न अद्यावधिकलाई मिलाउनु पर्छ। टूलिङले यहाँ मद्दत गर्न सक्छ, (१) कुन कमजोरीहरू वास्तवमा महत्त्वपूर्ण छन् भनेर प्राथमिकता दिएर (पहुँचयोग्य र शोषणयोग्य, आक्रमणकारीहरूद्वारा लक्षित हुने उच्च जोखिमको साथ), (२) हालको कम्पोनेन्ट प्रयोगहरूसँग मिल्दो र सफ्टवेयर बिगार्ने लक्षित संस्करणहरू छनौट गरेर, (३) दुर्भावनापूर्ण व्यवहार नभएको लक्षित संस्करणहरू छनौट गरेर, र (४) प्रत्यक्ष र अप्रत्यक्ष निर्भरताहरूको लागि संस्करण अपडेटलाई स्न्याप बनाएर, म्यानिफेस्ट फाइलहरूमा परिवर्तनहरू सुझाव दिएर जुन छिटो स्वीकृत हुन सक्छ। चरण (३) लाई सम्भव भएसम्म तिनीहरूको प्रकाशन समयको नजिक दुर्भावनापूर्ण कम्पोनेन्टहरूको बारेमा विशेष जानकारी चाहिन्छ।
निर्भरताहरू अद्यावधिक गर्ने यो प्रक्रिया हुनुपर्छ लागू भयो र प्रमाणित सबै ठाउँमा। प्रक्रियालाई दस्तावेजीकरण गरिनुपर्छ, र संलग्न सबै पक्षहरूलाई तालिम दिइनुपर्छ, किनकि प्रायः विकास र सफ्टवेयर निर्माण/तैनाती बाह्यीकृत गरिन्छ। CI/CD pipelines लाई तदनुसार परिमार्जन गरिनुपर्छ, ताकि स्वचालनले दुर्भावनापूर्ण अप्रत्यक्ष निर्भरतालाई निर्माणमा चिप्लन अनुमति नदिओस्: guardrails यदि कुनै निर्भरतामा सम्भावित मालवेयरको पर्याप्त प्रमाण छ भने निर्माणलाई रोक्नु सिफारिस गरिएको तरिका हो।
यदि तपाईंको संस्थासँग अनुमति दिइएको कम्पोनेन्ट संस्करणहरू राख्नको लागि सुरक्षा प्रोक्सीको रूपमा काम गर्ने आन्तरिक रजिस्ट्री छ भने, तपाईंले अनुरोध गरिएको कम्पोनेन्टलाई भत्ता सूचीमा थप्नु अघि जाँच गर्नको लागि दुर्भावनापूर्ण कम्पोनेन्टहरू (अन्य मापदण्डहरू बाहेक) बारे जानकारी प्राप्त गर्नुपर्छ।
सुरक्षित रूपमा खुला स्रोत सफ्टवेयर उपभोग गर्नु सजिलो छैन, र मालवेयर कारकलाई पूर्ण रूपमा ध्यानमा राख्नुपर्छ, जोखिम व्यवस्थापनमा पनि त्यस्तै प्रयास गर्नुपर्छ।
एउटा अन्तिम नोट: स्रोत उत्पत्ति, कम्पोनेन्टको निर्माण समयमा उत्पन्न हुने सफ्टवेयर प्रमाणीकरणको रूपमा, स्रोतहरू र निर्माण प्रक्रियासँग कलाकृति (कम्पोनेन्ट टार्बल) ट्रेस गर्ने प्रयासमा अर्को प्रमुख अंश हो। ध्यान दिनुहोस् कि स्रोत स्न्यापसट + निर्माण वातावरण र सम्बन्धित सफ्टवेयर कलाकृति (विश्वसनीय निर्माण प्रणालीद्वारा हस्ताक्षर गरिएको) बीचको यो लिङ्कले कम्पोनेन्टमा दुर्भावनापूर्ण व्यवहार नभएको कुरालाई रोक्दैन, तर खराब मानिसहरूलाई मालवेयर इन्जेक्ट गर्न गाह्रो बनाउँछ। र खुला स्रोत कम्पोनेन्टहरू उपभोग गर्नको लागि प्रोभेन्सन्स प्रमाणीकरणलाई सामान्य आवश्यकता बनाउन लामो समय लाग्नेछ, र केवल हालसालै NPM मा थपिएको। ती विश्वसनीय निर्माण र तैनाथ प्रणालीहरूलाई छेडछाड-प्रुफ बनाउनु, वा निर्माणमा कुनै पनि छेडछाड पत्ता लगाउन सक्षम पार्नु यो पोस्टको दायरा बाहिरको फरक कथा हो।
थप पढ्ने
अर्को एपिसोड खुला स्रोत दुर्भावनापूर्ण प्याकेजहरू: Xygeni दृष्टिकोण हाम्रो लागि Xygeni मा हामीले पालना गर्ने रणनीति प्रस्तुत गर्नेछौं मालवेयर सम्बन्धी प्रारम्भिक चेतावनी (MEW) प्रणाली। सार्वजनिक प्याकेज र छवि रजिस्ट्रीहरूमा नयाँ प्याकेज संस्करणहरू स्क्यान गरिन्छन् र स्थिर, गतिशील, क्षमताहरू, र प्रासंगिक विश्लेषणको संयोजन प्रयोग गरेर प्रमाण प्राप्त गरिन्छ। प्रयोगकर्ता प्रतिष्ठा र स्रोत कोड भण्डारहरूमा परिवर्तनहरूको इतिहाससँग मिल्दो प्रमाणले उच्च-जोखिम र सम्भवतः दुर्भावनापूर्ण कोटीहरूमा घटकको पूर्ण-स्वचालित वर्गीकरणको लागि अनुमति दिन्छ। प्रणालीले प्याकेजहरूबाट सङ्कलन गरिएका विगतका प्रमाणहरूबाट सिक्छ ताकि गलत सकारात्मकताहरूलाई न्यूनतममा कम गर्न सकियोस्।
सदस्यता लिएका संस्थाहरूले प्रत्यक्ष वा अप्रत्यक्ष रूपमा प्रयोग गरिरहेका कम्पोनेन्टहरूको लागि चेतावनी सूचना प्राप्त गर्छन्, जब कुनै दुर्भावनापूर्ण संस्करण वर्गीकृत गरिन्छ। त्यसपछि हाम्रा विश्लेषकहरूद्वारा म्यानुअल विश्लेषण गरिन्छ, जसले वर्गीकरणलाई पुष्टि वा अस्वीकार गर्दछ। पुष्टि गरिएको मालवेयरको लागि, सार्वजनिक रजिस्ट्रीलाई सूचित गरिन्छ ताकि यसले आफ्नै विश्लेषण गर्न सकोस् र सामान्यतया दुर्भावनापूर्ण संस्करण हटाउन वा प्रश्नमा रहेको प्रयोगकर्ता खातालाई ब्लक गर्ने वा हटाउने जस्ता थप कार्यहरू गर्न सकोस्।
हामी कसरी खुला स्रोत इकोसिस्टममा NPM, PyPI, GitHub, र अन्य प्रमुख पूर्वाधारहरूलाई मालवेयर पुष्टि नभएसम्म र रजिस्ट्रीबाट नहटाएसम्म प्रकाशित नयाँ दुर्भावनापूर्ण कम्पोनेन्ट सक्रिय रहन्छ भन्ने समय घटाउन मद्दत गरिरहेका छौं भनेर व्याख्या गर्नेछौं। र कसरी संस्थाहरूले MEW प्रणालीबाट लाभ उठाउन सक्छन् जसले गर्दा खुला स्रोत कम्पोनेन्टहरू समावेश गर्ने सफ्टवेयर आपूर्ति श्रृंखला आक्रमणहरू विरुद्ध धेरै राम्रो सुरक्षा प्राप्त गर्न सकिन्छ।
- [1] जे भए पनि, कम्पोनेन्टका प्रयोगकर्ताहरूले कम्पोनेन्ट टार्बल कतै क्यास गरिएको छ वा दर्ता गरिएको छ कि छैन भनेर जाँच गर्नुपर्छ, उदाहरणका लागि आन्तरिक रजिस्ट्रीमा, ताकि रोग निर्मूल होस्।
- [2] प्याकेज गरिएको कम्पोनेन्टमा एउटा म्यानिफेस्ट समावेश हुन्छ जसले यसको सामग्री र मेटाडेटा, स्रोत वा कम्पाइल गरिएको कोड, स्थापना स्क्रिप्टहरू, र परीक्षण सुइटहरू जस्ता अतिरिक्त वस्तुहरू, प्याकेजिङ ढाँचा अनुसार र सामान्यतया संकुचित रूपमा घोषणा गर्दछ। यसलाई "कम्पोनेन्ट टार्बल" भनिन्छ।
- [3] यदि दुर्भावनापूर्ण व्यक्तिले रजिस्ट्रीमा नै उल्लंघनको कारणले प्रकाशित कम्पोनेन्ट परिमार्जन गर्न सक्छ भने पनि, विश्लेषण गरिसकेपछि एउटा सादा-पुरानो क्रिप्टोग्राफिक डाइजेस्टले टार्बलमा भएको कुनै पनि परिवर्तन पत्ता लगाउन सक्छ।
- [4] याद राख्नुहोस् कि केही मालिसियस कम्पोनेन्टहरू स्थापनाको समयमा चल्छन्, त्यसैले यसले विकासकर्ता नोडहरूलाई असर गर्न सक्छ जसले अनजानमा "npm install X" लाई मालिसियस कम्पोनेन्ट X सँग चलाउँछन्।
