एनपीएम सुरक्षा ऑडिटिंग और आपूर्ति-श्रृंखला हमलों के लिए गहन मार्गदर्शिका

होम » अजगर » एनपीएम सुरक्षा ऑडिटिंग और आपूर्ति-श्रृंखला हमलों के लिए गहन मार्गदर्शिका

यदि आप आज Node.js या TypeScript के साथ कुछ भी बनाते हैं, तो आप npm निर्भरताओं के एक विशाल ढेर के ऊपर खड़े हैं, जिन्हें आपने नहीं लिखा है और संभवतः कभी पूरी तरह से नहीं पढ़ेंगे। यह सुविधाओं को तेजी से पहुंचाने के लिए अविश्वसनीय रूप से सुविधाजनक है, लेकिन यह आपूर्ति-श्रृंखला खतरों, क्रेडेंशियल चोरी और आपके ऐप्स या CI/CD पाइपलाइनों में घुसपैठ करने वाले सूक्ष्म बैकडोर के लिए एक विशाल हमले की सतह भी खोल देता है।

आधुनिक एनपीएम सुरक्षा अब केवल इस बारे में नहीं है कि "क्या मेरे पैकेज में ज्ञात सीवीई हैं?" - यह इस बारे में है रखरखावकर्ता खातों को हाईजैक करने वाले फ़िशिंग अभियानों से बचाव करना, कीड़े जो संक्रमित संस्करणों को स्वचालित रूप से प्रकाशित करते हैं, और दुर्भावनापूर्ण लाइब्रेरी जो डेवलपर के डेटा को मिटाने का प्रयास करती हैं home डायरेक्टरी में सेंध लगाएँ या क्लाउड क्रेडेंशियल्स चुराएँ। इस गाइड में हम जानेंगे कि कैसे एनपीएम सुरक्षा ऑडिटिंग काम करता है, जैसे उपकरणों के साथ अपने वर्कफ़्लो को कैसे कठोर करें npm audit, डिपेंडाबोट, एसएएसटी/एससीए स्कैनर और सीआई/सीडी चेक, और एक डेवलपर के रूप में आप वास्तव में क्या कर सकते हैं जब आप चिंतित हों कि "यह छोटी सी लाइब्रेरी मैलवेयर हो सकती है"।

एनपीएम निर्भरता सुरक्षा इतनी बड़ी बात क्यों है?

हर बार जब आप दौड़ते हैं npm install, आप अपने प्रोजेक्ट में तृतीय-पक्ष कोड आयात कर रहे हैं और प्रभावी रूप से इसके लेखकों पर भरोसा करना आपके आक्रमण सतह के एक हिस्से के साथ। Node.js में यह विश्वास श्रृंखला आश्चर्यजनक रूप से गहरी हो सकती है: एक शीर्ष-स्तरीय निर्भरता सैकड़ों ट्रांज़िटिव पैकेजों को खींच सकती है जिन्हें आपने कभी सीधे तौर पर नहीं चुना।

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

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

निर्भरताओं को ऑडिट करके अद्यतन रखना इसलिए, यह कोई आसान स्वच्छता कार्य नहीं है, बल्कि किसी भी गंभीर Node.js या TypeScript प्रोजेक्ट के रखरखाव का एक मुख्य हिस्सा है। नियमित सुरक्षा ऑडिट, स्वचालित और मैन्युअल दोनों, तृतीय-पक्ष कोड से होने वाले जोखिम को स्वीकार्य स्तर पर बनाए रखने का एकमात्र तरीका है।

एनपीएम ऑडिट को समझना और यह वास्तव में क्या जाँचता है

npm audit यह एक अंतर्निहित कमांड है जो आपके प्रोजेक्ट के डिपेंडेंसी ट्री को ज्ञात कमज़ोरियों के डेटाबेस के विरुद्ध स्कैन करता है और एक सुरक्षा रिपोर्ट तैयार करता है। जब आप इसे अपने प्रोजेक्ट के रूट में चलाते हैं, तो npm आपकी package.json और लॉक फ़ाइल, पूर्ण निर्भरता ग्राफ बनाता है और सलाह के विरुद्ध प्रत्येक संस्करण का मिलान करता है।

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

कार्यप्रवाह के दृष्टिकोण से, npm audit इंटरैक्टिव रूप से इस्तेमाल किया जा सकता है डेवलपर्स द्वारा और CI/CD पाइपलाइनों में गैर-इंटरैक्टिव रूप से। पाइपलाइनों में, आप बिल्ड को केवल तभी विफल कर सकते हैं जब कमज़ोरियाँ एक निश्चित गंभीरता सीमा से ऊपर हों, जैसे फ़्लैग का उपयोग करके --audit-level.

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

एनपीएम ऑडिट कैसे चलाएं और परिणामों की व्याख्या कैसे करें

बुनियादी सुरक्षा ऑडिट करने के लिए, अपने प्रोजेक्ट रूट में एक टर्मिनल खोलें (जहाँ package.json रहता है) और भागो npm auditएक संक्षिप्त निर्भरता विश्लेषण के बाद, एनपीएम गंभीरता के आधार पर समूहीकृत समस्याओं की एक तालिका, साथ ही पैच किए गए संस्करण में अपग्रेड करने जैसे सुझाए गए उपचार चरणों का आउटपुट देगा।

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

यदि आप परिणामों को अन्य उपकरणों में शामिल करना चाहते हैं या उन्हें बाद के लिए संग्रहीत करना चाहते हैं, तो आप JSON आउटपुट के लिए पूछ सकते हैं npm audit --jsonयह विशेष रूप से तब उपयोगी होता है जब आप कस्टम डैशबोर्ड, टिकटिंग सिस्टम या सुरक्षा ऑर्केस्ट्रेशन प्लेटफॉर्म के साथ एकीकृत करते हैं।

CI/CD पाइपलाइनों में, कई टीमें पाइपलाइन को चलाने के लिए कॉन्फ़िगर करती हैं npm audit --json निर्भरताएँ स्थापित होने के तुरंत बाद, परिणाम को पार्स करें और यदि चुनी गई गंभीरता से ऊपर कोई भेद्यता मौजूद है, तो बिल्ड को विफल करें। बाहरी सहायक जैसे audit-ci आपके लिए इस तर्क को लपेट सकता है और थ्रेसहोल्ड पार होने पर बिल्ड को तोड़ने के लिए सुविधाजनक विकल्प प्रदान कर सकता है।

एनपीएम ऑडिट फिक्स के साथ कमजोरियों को ठीक करना

एक बार npm audit समस्याओं को चिन्हित करने पर, आपकी रक्षा की पहली पंक्ति है npm audit fix, जो कमजोर निर्भरताओं को स्वचालित रूप से निकटतम सुरक्षित संस्करणों में अपग्रेड करने का प्रयास करता है। इसके पीछे यह पुनर्लेखन करता है package-lock.json (और package.json जहां लागू हो) पैकेजों को संगत संस्करण श्रेणियों के भीतर लाने के लिए।

यह स्वचालित सुधार कई कम और मध्यम समस्याओं के लिए, और यहाँ तक कि कुछ उच्च गंभीरता वाली समस्याओं के लिए भी कारगर है, जहाँ समाधान एक मामूली या पैच रिलीज़ होता है। यह एक त्वरित समाधान है जो अक्सर न्यूनतम मानवीय प्रयास से आपके बैकलॉग के एक बड़े हिस्से को साफ़ कर देता है।

हर कमज़ोरी को स्वचालित अपग्रेड द्वारा सुरक्षित रूप से ठीक नहीं किया जा सकता; कुछ के लिए बड़े संस्करण परिवर्तनों की आवश्यकता होती है जो आपके कोड या अन्य निर्भरताओं को नुकसान पहुँचा सकते हैं। यहीं पर npm audit fix --force इसमें आता है: यह ब्रेकिंग परिवर्तनों के बावजूद अपग्रेड को बाध्य करता है, लेकिन आपको इसका उपयोग सावधानीपूर्वक करना चाहिए और बाद में हमेशा अच्छी तरह से परीक्षण करना चाहिए।

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

फ़ाइलें, npm ci और नियतात्मक इंस्टॉल लॉक करें

RSI package-lock.json फ़ाइल (या yarn.lock/pnpm-lock.yaml अन्य प्रबंधकों के लिए) सुरक्षा के लिए महत्वपूर्ण है क्योंकि यह आपके प्रोजेक्ट द्वारा उपयोग की जाने वाली प्रत्येक निर्भरता के सटीक संस्करणों को पिन करता है। इसके बिना, प्रत्येक npm install थोड़ा अलग संगत संस्करण खींच सकता है, जिससे निर्माण गैर-निर्धारक हो जाता है और ऑडिट करना कठिन हो जाता है।

आपको संपादन से बचना चाहिए package-lock.json जब आप निर्भरताएँ जोड़ते, हटाते या अपडेट करते हैं, तो उन्हें मैन्युअल रूप से प्रबंधित करें और इसके बजाय npm को उन्हें प्रबंधित करने दें। कोड कमिट करते समय, हमेशा दोनों को शामिल करें package.json और लॉक फ़ाइल को इस प्रकार स्थापित करें कि सभी लोग - और आपका CI/CD - समान संस्करण स्थापित करें।

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

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

डिपेंडाबॉट, रेनोवेट और एनपीएम टूलिंग के साथ अपडेट को स्वचालित करना

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

उदाहरण के लिए, GitHub का Dependabot एक के माध्यम से कॉन्फ़िगर किया गया है .github/dependabot.yml यह फ़ाइल निर्दिष्ट करती है कि किन इकोसिस्टम पर नज़र रखनी है, आवृत्ति अपडेट करनी है और लक्षित शाखाएँ। जब यह किसी असुरक्षित या पुराने NPM पैकेज का पता लगाता है, तो यह एक PR अपडेटिंग फ़ाइल बनाता है। package.json और package-lock.json, अक्सर सलाह के लिंक के साथ।

के साथ रखा npm audit, आपको एक अच्छा फीडबैक लूप मिलता है: ऑडिट समस्याओं की पहचान करता है, और डिपेंडाबॉट (या रेनोवेट) उन्हें ठीक करने के लिए लगातार अपग्रेड का प्रस्ताव देता है। आपका काम इन पुल रिक्वेस्ट की समीक्षा और परीक्षण करना होता है, बजाय इसके कि आप हर एक वर्जन बम्प को खुद से खोजें।

स्वचालन से परे, npm स्वयं सहायक कमांड प्रदान करता है जैसे npm outdated नए संस्करणों के साथ पैकेजों को सूचीबद्ध करने के लिए और npm update अनुमत संस्करण श्रेणियों के भीतर अपग्रेड करने के लिए। नियमित रूप से उपयोग करने पर, ये इस संभावना को कम करते हैं कि आप बहुत पीछे रह जाएँ और आपको एक साथ कई प्रमुख संस्करणों को छोड़ना पड़े।

CI/CD पाइपलाइनों में सुरक्षा जांच चलाना

एक सुरक्षित एनपीएम सेटअप आपके लैपटॉप तक ही सीमित नहीं है; आपकी CI/CD पाइपलाइनों को भी सुरक्षा जाँच लागू करनी चाहिए ताकि असुरक्षित या दुर्भावनापूर्ण कोड को प्रोडक्शन तक पहुँचने से रोका जा सके। हर चरण - स्रोत, निर्माण, परीक्षण, परिनियोजन - में प्रासंगिक नियंत्रण होने चाहिए।

भागना आम बात है npm audit निर्माण या पूर्व-तैनाती चरण के दौरान स्वचालित रूप से, अक्सर --json निगरानी उपकरणों के साथ आसान एकीकरण के लिए ध्वज। यदि स्कैन आपके जोखिम सीमा से ऊपर की कमज़ोरियों का पता लगाता है, तो पाइपलाइन विफल हो सकती है और रिलीज़ को अवरुद्ध कर सकती है।

उन्नत उपकरण जैसे संन्यासी निर्भरताओं को स्कैन करके और उच्च या गंभीर समस्याएँ पाए जाने पर बिल्ड को विफल करके CI/CD में सुरक्षा द्वारपाल के रूप में कार्य कर सकते हैं। इन्हें सोनारक्यूब या सोनारक्लाउड जैसे गुणवत्ता विश्लेषकों के साथ संयोजित करने से आपको कोड गुणवत्ता, सुरक्षा जोखिमों और तकनीकी ऋण की व्यापक तस्वीर मिलती है।

विकास के दौरान, ESLint जैसे स्थैतिक विश्लेषण उपकरण जैसे प्लगइन्स eslint-plugin-security और eslint-plugin-node आपके अपने कोड में असुरक्षित पैटर्न को जल्दी पकड़ने में आपकी मदद करता है। यह निर्भरता स्कैनिंग का पूरक है, जो आपके व्यावसायिक तर्क के बजाय तृतीय-पक्ष घटकों पर केंद्रित है।

एनपीएम ऑडिट से परे सीआई/सीडी पाइपलाइनों को मजबूत करना

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

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

न्यूनतम विशेषाधिकार के सिद्धांत वाला भूमिका-आधारित अभिगम नियंत्रण (RBAC) GitHub, npm और आपके द्वारा उपयोग किए जाने वाले किसी भी CI/CD प्लेटफ़ॉर्म के लिए अत्यंत महत्वपूर्ण है। डेवलपर्स और सेवा खातों के पास केवल वही अनुमतियाँ होनी चाहिए जिनकी उन्हें अत्यंत आवश्यकता है - इससे अधिक कुछ नहीं।

प्री-कमिट हुक और सीक्रेट-स्कैनिंग टूल, API कुंजियों, टोकन या पासवर्ड को आपकी रिपॉजिटरी में प्रवेश करने से रोक सकते हैं। संरचित GitOps वर्कफ़्लो और संरक्षित शाखाओं के साथ मिलकर, ये एक स्पष्ट ऑडिट ट्रेल प्रदान करते हैं और बिना समीक्षा वाले परिवर्तनों के विलय होने के जोखिम को कम करते हैं।

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

वास्तविक दुनिया में एनपीएम आपूर्ति-श्रृंखला हमले और वे हमें क्या सिखाते हैं

पिछले कुछ वर्षों में, एनपीएम ने कई हाई-प्रोफाइल सप्लाई-चेन घटनाएँ देखी हैं जहाँ हमलावरों ने व्यक्तिगत एप्लिकेशन के बजाय मेंटेनर्स या पैकेज को निशाना बनाया। ये हमले इस बात पर प्रकाश डालते हैं कि कैसे एक एकल हैक किया गया अकाउंट लाखों डाउनस्ट्रीम इंस्टॉलेशन पर असर डाल सकता है।

एक अभियान में, एक जाने-माने एनपीएम मेंटेनर को एक ऐसे डोमेन से एक सावधानीपूर्वक तैयार किया गया फ़िशिंग ईमेल मिला, जो आधिकारिक एनपीएम साइट से लगभग अप्रभेद्य लग रहा था। संदेश में धमकी दी गई थी कि अगर दो-कारक प्रमाणीकरण "अपडेट" नहीं किया गया, तो अकाउंट लॉक कर दिया जाएगा, और पीड़ित को एक नकली लॉगिन पेज पर ले जाया गया, जिसने क्रेडेंशियल्स हासिल कर लिए थे।

एक बार जब हमलावर ने मेंटेनर के एनपीएम खाते पर नियंत्रण पा लिया, तो उसने अरबों साप्ताहिक डाउनलोड वाले 18 बेहद लोकप्रिय पैकेजों के दुर्भावनापूर्ण संस्करण अपलोड कर दिए। चूँकि ये पैकेज जावास्क्रिप्ट इकोसिस्टम के निर्भरता ग्राफ में गहराई से अंतर्निहित थे, इसलिए संभावित विस्फोट का दायरा बहुत बड़ा था।

इंजेक्ट किया गया कोड क्रिप्टोकरेंसी और वेब3 गतिविधि पर लक्षित ब्राउज़र-साइड इंटरसेप्टर की तरह व्यवहार करता था: यह ब्राउज़र एपीआई को इस तरह से जोड़ता था fetch, XMLHttpRequest और वॉलेट इंटरफेस जैसे window.ethereum या सोलाना वॉलेट एपीआई। यह नेटवर्क प्रतिक्रियाओं और लेनदेन पेलोड को किसी भी ऐसी चीज़ के लिए स्कैन करता था जो क्रिप्टो एड्रेस या ट्रांसफर जैसी दिखती हो।

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

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

उस ब्राउज़र-इंटरसेप्टर घटना से मार्गदर्शन

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

का गहन निरीक्षण package.json और package-lock.json (या yarn.lock) यह सत्यापित करने के लिए ज़रूरी है कि क्या आपके प्रोजेक्ट में कभी दुर्भावनापूर्ण संस्करण शामिल किए गए थे। यहीं पर निर्धारक इंस्टॉलेशन और संस्करण-पिन की गई लॉक फ़ाइलें फ़ोरेंसिक कार्य को और अधिक प्रबंधनीय बनाती हैं।

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

दो-कारक प्रमाणीकरण के साथ खाता सुरक्षा को मज़बूत करना, खासकर हार्डवेयर कुंजियों के ज़रिए, npm और GitHub खातों के लिए बेहद ज़रूरी है – खासकर लोकप्रिय पैकेजों के रखरखावकर्ताओं के लिए। फिर भी, ऐसे ईमेल से हमेशा सावधान रहें जो आपको क्रेडेंशियल "अपडेट" करने के लिए किसी लिंक पर क्लिक करने के लिए कहते हैं; इसके बजाय, सीधे आधिकारिक साइट पर जाएँ और वहाँ अलर्ट देखें।

वाणिज्यिक SCA और SBOM टूल का उपयोग करने वाले संगठन अक्सर पैकेज नाम और संस्करण के आधार पर अपनी इन्वेंट्री की जाँच करके उन सभी सिस्टम और एप्लिकेशन का पता लगा सकते हैं जो किसी क्षतिग्रस्त लाइब्रेरी पर निर्भर हैं। यह दृश्यता आपूर्ति-श्रृंखला संबंधी घटनाओं के समय प्रतिक्रिया समय को नाटकीय रूप से कम कर देती है।

शाई-हुलुद वर्म: स्व-प्रतिकृति एनपीएम मैलवेयर

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

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

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

कई मामलों में, चुराए गए सीक्रेट्स को पीड़ित के अपने अकाउंट के तहत नए बनाए गए सार्वजनिक GitHub रिपॉजिटरी में डाल दिया जाता था, और उनके नाम या विवरण में Shai‑Hulud का ज़िक्र होता था। इससे समस्या और भी बदतर हो जाती थी क्योंकि उन रिपॉजिटरी में आने वाले किसी भी व्यक्ति के लिए संवेदनशील डेटा उजागर हो जाता था।

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

शाई-हुलुद 2.0: पूर्व-स्थापित तोड़फोड़ और विनाशकारी फ़ॉलबैक

बाद की लहर, जिसे शाई-हुलुद 2.0 कहा गया, ने स्थापना के बाद के चरण के बजाय पूर्व-स्थापना चरण के दौरान निष्पादन की रणनीति बदल दी, जिससे डेवलपर मशीनों और CI/CD सर्वरों तक इसकी पहुँच का व्यापक विस्तार हुआ। पूर्व-स्थापना स्क्रिप्ट जीवनचक्र में और भी पहले चलती हैं और अधिक सिस्टम पर ट्रिगर हो सकती हैं।

इस संस्करण का सबसे खतरनाक पहलू इसकी वापसी प्रणाली थी: यदि मैलवेयर उपयोगी क्रेडेंशियल्स चुराने या संचार चैनल स्थापित करने में विफल रहा, तो उसने विनाशकारी व्यवहार का प्रयास किया जैसे कि पीड़ित के शरीर को पोंछना home डायरेक्टरी. ऐसा उसने उस निर्देशिका के अंतर्गत वर्तमान उपयोगकर्ता के स्वामित्व वाली किसी भी लिखने योग्य फ़ाइल को अधिलेखित और सुरक्षित रूप से हटाकर किया।

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

इस अभियान द्वारा एकत्र किए गए क्रेडेंशियल्स और रहस्यों को फिर से GitHub पर भेज दिया गया, इस बार "Sha1‑Hulud: The Second Coming" के रूप में वर्णित रिपॉजिटरी में, और मैलवेयर ने GitHub Actions वर्कफ़्लोज़ जैसे बनाकर दृढ़ता हासिल करने की कोशिश की discussion.yamlउन वर्कफ़्लोज़ ने संक्रमित मशीनों को स्व-होस्टेड रनर के रूप में पंजीकृत किया, जिससे हमलावरों को चर्चा शुरू करके मनमाने आदेशों को ट्रिगर करने की अनुमति मिली।

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

एनपीएम सप्लाई-चेन वर्म्स के विरुद्ध तत्काल रक्षात्मक कार्रवाई

शाई-हुलुद जैसे अभियानों का सामना करते समय, घटना प्रत्युत्तरकर्ता सभी डेवलपर-स्तरीय क्रेडेंशियल्स को तुरंत बदलने की सलाह देते हैं - एनपीएम टोकन, गिटहब पीएटी, एसएसएच कुंजी, और डेवलपर मशीनों या बिल्ड सर्वर पर उपयोग की जाने वाली कोई भी क्लाउड एपीआई कुंजी। मान लें कि किसी समझौता किए गए वर्कस्टेशन पर मौजूद कोई भी चीज़ लीक हो गई होगी.

सभी परियोजनाओं में पूर्ण निर्भरता ऑडिट आवश्यक है, जिसमें निम्नलिखित उपकरणों का उपयोग किया जा सकता है: npm auditप्रभावित पैकेज नामों और संस्करणों के किसी भी उपयोग का पता लगाने के लिए, SBOM इन्वेंटरी या वाणिज्यिक SCA प्लेटफ़ॉर्म पर जाएँ। फ़ाइलें लॉक करें (package-lock.json, yarn.lock) वास्तव में क्या स्थापित किया गया था, इसके बारे में जमीनी सच्चाई बताएं।

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

सभी डेवलपर खातों में बहु-कारक प्रमाणीकरण लागू करना – जहाँ तक संभव हो, फ़िशिंग-रोधी तरीकों के साथ – एक और अपरिहार्य कदम है। यह जोखिम को समाप्त नहीं करता, लेकिन क्रेडेंशियल-चोरी अभियानों का दुरुपयोग करने की कोशिश करने वाले हमलावरों के लिए जोखिम बढ़ा देता है।

उन्नत खतरा-शिकार प्लेटफार्मों का उपयोग करने वाले संगठन भी ज्ञात संकेतकों की तलाश करने के लिए कस्टम क्वेरी का लाभ उठा सकते हैं जैसे कि विशिष्ट कॉल webhook.site यूआरएल, जैसी फ़ाइलों की उपस्थिति shai-hulud-workflow.yml या संदिग्ध रूप से बड़ा bun_environment.js डेवलपर मशीनों पर लिखी गई फ़ाइलें। टेलीमेट्री से प्रारंभिक पहचान नाटकीय रूप से ठहराव समय को कम कर सकती है।

विक्रेता कैसे प्रतिक्रिया दे रहे हैं: पता लगाने और रोकथाम की क्षमताएं

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

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

उन्नत ख़तरा रोकथाम और URL फ़िल्टरिंग के साथ अगली पीढ़ी के फ़ायरवॉल फ़िशिंग या एक्सफ़िल्टरेशन में उपयोग किए जाने वाले दुर्भावनापूर्ण डोमेन तक पहुँच को अवरुद्ध करके मदद कर सकते हैं - उदाहरण के लिए, नकली npm समर्थन डोमेन या विशिष्ट webhook.site मैलवेयर में हार्ड-कोड किए गए एंडपॉइंट्स। इन URL को दुर्भावनापूर्ण के रूप में वर्गीकृत करने से पेलोड को चोरी किए गए डेटा को सफलतापूर्वक भेजने से रोका जा सकता है.

एंडपॉइंट डिटेक्शन और रिस्पांस (EDR/XDR) एजेंट प्रक्रिया व्यवहार, स्क्रिप्ट निष्पादन, असामान्य फ़ाइल निर्माण (जैसे विशाल) की निगरानी करके योगदान करते हैं bun_environment.js फ़ाइलें) और संदिग्ध कमांड लाइन। वे व्यवहार संबंधी नियमों के आधार पर ज्ञात हैश और पहले न देखे गए वेरिएंट, दोनों को रोक सकते हैं।

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

दुर्भावनापूर्ण एनपीएम पैकेजों के बारे में चिंतित डेवलपर्स के लिए व्यावहारिक आदतें

अगर आप JS/TS में नए हैं और हर बार npm पैकेज इंस्टॉल करते समय असहज महसूस करते हैं, तो आप अकेले नहीं हैं - लेकिन कुछ ठोस आदतें हैं जिन्हें अपनाकर आप अपनी उत्पादकता को प्रभावित किए बिना जोखिम कम कर सकते हैं। इन्हें एक व्यक्तिगत सुरक्षा चेकलिस्ट की तरह समझें।

सबसे पहले, पसंद करें स्वस्थ रखरखाव इतिहास के साथ अच्छी तरह से स्थापित पैकेज, सक्रिय समस्या ट्रैकर और व्यापक उपयोग, खासकर HTTP क्लाइंट, लॉगिंग या क्रिप्टो जैसे कोर इंफ्रास्ट्रक्चर के लिए। यह सुरक्षा की गारंटी नहीं देता, लेकिन इसका मतलब आमतौर पर कोड पर ज़्यादा नज़र रखना और कुछ गड़बड़ होने पर तेज़ी से पता लगाना होता है।

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

जहाँ तक संभव हो, प्रकाशित पैकेज टारबॉल की जाँच करें, न कि केवल स्रोत रिपॉजिटरी की, क्योंकि हमलावर GitHub पर दिखाई देने वाले बिल्ड से अलग बिल्ड npm पर भेज सकते हैं। npm pack मैन्युअल समीक्षा के साथ संयुक्त (भले ही कोड ट्रांसपाइल या मिनिफाई किया गया हो) स्पष्ट लाल झंडे प्रकट कर सकता है जैसे अजीब इंस्टॉल स्क्रिप्ट, अस्पष्ट ब्लॉब्स या अप्रत्याशित नेटवर्क कॉल।

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

एनपीएम सुरक्षा को अग्नि-अभ्यास के बजाय एक नियमित प्रक्रिया बनाएं: चलाएं npm audit नियमित रूप से, अप्रयुक्त निर्भरताओं को साफ़ करें, अपनी लॉक फ़ाइलों को प्रतिबद्ध रखें, और अपने CI/CD में SCA/SAST जाँचों को एकीकृत करें। मज़बूत खाता स्वच्छता और गुप्त प्रबंधन के साथ, ये अभ्यास आपको अभेद्य नहीं बनाते, लेकिन ये इस संभावना को काफ़ी कम कर देते हैं कि कोई यादृच्छिक npm इंस्टॉलेशन चुपचाप आपके सिस्टम को खतरे में डाल देगा।