क्या आपकी लॉकफ़ाइल भेद्यताएँ छिपा रही है?
लॉकफ़ाइल आपके रिपॉज़िटरी का सबसे ईमानदार दस्तावेज़ है: यह उन सटीक संस्करणों को सूचीबद्ध करती है जिन्हें आपका बिल्ड वास्तव में इंस्टॉल करता है, बिना रेंज, बिना “latest”, बिना आश्चर्य के। यह चुपचाप हमले की सतह की सूची भी है — हर पिन किया गया संस्करण एक ऐसा संस्करण है जिसमें आपने उसे पिन करने के बाद से किसी को कोई छेद मिल सकता है। यह लेख बताता है कि स्कैनर उस सूची को उत्तरों में कैसे बदलता है: OSV डेटाबेस संस्करणों को ज्ञात भेद्यताओं से कैसे मिलाता है, CISA KEV फ़्लैग CVSS स्कोर से ज़्यादा क्यों मायने रखता है, और “कोई भेद्यता नहीं मिली” डेटाबेस के बारे में बयान क्यों है, आपके कोड के बारे में नहीं। आप जाँच स्वयं SBOM Vulnerability Scanner में चला सकते हैं, जो आपकी लॉकफ़ाइल को ब्राउज़र में पार्स करता है और कभी अपलोड नहीं करता।
लॉकफ़ाइल क्या पिन करती है — और वह हमले की सतह क्यों है
आधुनिक सॉफ़्टवेयर ज़्यादातर दूसरों का कोड होता है। एक सामान्य वेब एप्लिकेशन सैकड़ों पैकेज खींचता है, और उनमें से प्रत्येक और भी खींचता है: वेब फ़्रेमवर्क पर सीधी निर्भरता आसानी से दो सौ ट्रांज़िटिव पैकेज बन सकती है जिन्हें आपने कभी चुना नहीं और कभी समीक्षा नहीं की। लॉकफ़ाइल उस ट्री का रिकॉर्ड है — npm के लिए package-lock.json, Python के लिए पूरी तरह पिन की गई requirements.txt, Go के लिए go.mod और go.sum — इस तरह लिखा जाता है कि हर मशीन पर हर इंस्टॉल से वही ट्री बने। इसके बिना, “मेरी मशीन पर काम करता है” एक आशा है, तथ्य नहीं।
वही सटीकता लॉकफ़ाइल को ज्ञात भेद्यताओं को खोजने के लिए सही जगह बनाती है। भेद्यता डेटाबेस पैकेज नाम, इकोसिस्टम और सटीक संस्करण से जुड़ा होता है: lodash 4.17.20 भेद्य है, lodash 4.17.21 नहीं है, और अंतर एक ही लुकअप से पता चलता है। तैरती रेंज का इस तरह मूल्यांकन नहीं किया जा सकता — स्कैनर को यह अनुमान लगाना होगा कि आपने वास्तव में कौन-सा संस्करण इंस्टॉल किया है, और अनुमान लगाना सुरक्षा अभ्यास नहीं है। इसलिए लॉकफ़ाइल स्वच्छता का पहला नियम सीधा और अटल है: लॉकफ़ाइल को कमिट करें, उसे पिन करके रखें, और अपने मैनिफ़ेस्ट की इच्छा-सूची के बजाय पिन किए गए ट्री को स्कैन करें।
OSV संस्करणों को ज्ञात भेद्यताओं से कैसे मिलाता है
OSV.dev एक सार्वजनिक भेद्यता डेटाबेस है जो GitHub, NVD और भाषा इकोसिस्टम से एडवाइज़री को एक क्वेरी योग्य इंडेक्स में एकत्र करता है। स्कैनर उसे नाम, इकोसिस्टम और संस्करण के त्रिक का बैच भेजता है — lodash, npm, 4.17.20 — और बदले में उन भेद्यता आईडी को पाता है जो ठीक उसी संस्करण को प्रभावित करती हैं। फिर आईडी पूरी तरह लाए जाते हैं: सारांश, ठीक किए गए संस्करणों सहित प्रभावित रेंज, CVSS वेक्टर के रूप में गंभीरता, और CVE उपनाम। क्वेरी के साथ आपके प्रोजेक्ट के बारे में कुछ नहीं जाता — केवल सार्वजनिक पैकेजों के सार्वजनिक निर्देशांक।
मिलान जानबूझकर सीधा है, और यही उसकी ताकत है। यह आपका कोड नहीं पढ़ता, यह नहीं आँकता कि आप भेद्य फ़ंक्शन को कॉल करते हैं या नहीं, और उसे इस बात से कोई फ़र्क नहीं पड़ता कि पैकेज का उपयोग कैसे होता है। यदि एडवाइज़री कहती है कि 4.17.21 से पहले के संस्करण प्रभावित हैं और आप 4.17.20 पिन करते हैं, तो आपका मिलान होता है — भले ही आपका कोड कभी भेद्य फ़ंक्शन को छुए नहीं। यह अति-रिपोर्टिंग एक विशेषता है: पहुँच विश्लेषण एक कठिन, धीमा प्रश्न है, और सस्ता प्रश्न (“क्या यह संस्करण ज्ञात-बुरा है?”) पहले से ही उस निर्भरता को पकड़ लेता है जिसे आप तीन साल पहले अपग्रेड करना भूल गए थे।
स्कैनर क्या नहीं देख सकता
संस्करण-मिलान वाली जाँच की एक कठोर सीमा है, और उसे सीधे बताना उचित है: यह केवल उन भेद्यताओं को पा सकती है जिनकी किसी ने पहले ही सूचना दी है, उस संस्करण के लिए जिसे डेटाबेस जानता है। कल खोजी गई और अभी तक प्रकाशित नहीं हुई भेद्यता अदृश्य है। कोई पैकेज जो कभी भेद्य नहीं था लेकिन दुर्भावनापूर्ण है — लोकप्रिय नाम का टाइपोस्क्वैट, समझौता किया गया रिलीज़, घर फोन करने वाली निर्भरता — उसका कोई CVE ही नहीं है, और इस तरह का कोई स्कैनर उसे फ़्लैग नहीं करेगा। यही बात आपके अपने कोड पर भी लागू होती है: स्कैनर उन पैकेजों का मूल्यांकन करता है जिन्हें आप इंस्टॉल करते हैं, उस कोड का नहीं जो आप लिखते हैं।
इसी सीमा के कारण “कोई भेद्यता नहीं मिली” परिणाम को ध्यान से पढ़ना चाहिए। इसका अर्थ है: इन सटीक संस्करणों के लिए, इस डेटाबेस में, इस क्षण, कुछ भी दर्ज नहीं है। यह एक उपयोगी नकारात्मक है — ताज़ा लॉकफ़ाइल का साफ़ स्कैन वास्तव में अच्छी खबर है — लेकिन यह प्रमाणपत्र नहीं है। स्कैनर जो नहीं देख सकता, उसके लिए बचाव अलग उपकरण हैं: नई निर्भरताओं को ट्री में आने से पहले पिन करना और उनकी समीक्षा करना, तिमाही के बजाय लगातार नई एडवाइज़री पर नज़र रखना, और शांत पैकेज के अचानक नए रिलीज़ को संदेह से देखना। स्कैनर धुआँ अलार्म है, दमकल दल नहीं।
KEV फ़्लैग उच्च CVSS स्कोर से ऊपर क्यों है
CVSS स्कोर एक काल्पनिक प्रश्न का उत्तर देता है: यदि कोई इस भेद्यता का शोषण करे तो यह कितनी बुरी होगी? CISA ज्ञात शोषित भेद्यताओं का कैटलॉग एक तथ्य का उत्तर देता है: क्या कोई इसका शोषण कर रहा है, वास्तविक दुनिया में, अभी? ये दो उत्तर नियमित रूप से असहमत होते हैं। 9.8 स्कोर वाली भेद्यता जिसे किसी ने हथियार नहीं बनाया है, अगले नियोजित अपग्रेड तक इंतज़ार कर सकती है; 5.3 स्कोर वाली भेद्यता जो KEV सूची में है — CISA द्वारा निर्धारित सुधार की नियत तिथि के साथ — इस सप्ताह पैच की हकदार है, क्योंकि शोषण पहले से मौजूद है और पहले से उपयोग में है।
यही उलटफेर कारण है कि स्कैनर KEV पंक्तियों को गंभीरता क्रम में मिलाने के बजाय अलग से बैज देता है। क्रम आपको बताता है कि क्या बुरा है; KEV बैज आपको बताता है कि क्या तत्काल है। व्यवहार में ट्राइएज छोटा है: पहले KEV आइटम पैच करें, फिर प्रकाशित ठीक किए गए संस्करण वाले गंभीर आइटम, फिर बाकी को अगले अपग्रेड चक्र के साथ शेड्यूल करें। इस साइट पर Bulk CVE Triage डेस्क उन्हीं CVE को शोषण संदर्भ में रखता है — KEV स्थिति, EPSS संभावना और CVSS एक साथ — जब एक बैज टीम को काम का औचित्य बताने के लिए पर्याप्त नहीं होता।
लॉकफ़ाइल कमिट करें, उसे CI में स्कैन करें — तिमाही में एक बार नहीं
लॉकफ़ाइल जो कमिट नहीं की गई है, वह लॉकफ़ाइल है ही नहीं। यदि वह केवल एक डेवलपर की मशीन पर रहती है, तो हर दूसरी मशीन वही इंस्टॉल करती है जो उस दिन “latest” से हल होता है, और जो ट्री आपने स्कैन किया है वह वह ट्री नहीं है जिसे आप शिप करते हैं। उसे कमिट करना सबसे सस्ता आपूर्ति-शृंखला नियंत्रण है: यह इंस्टॉल को पुनरुत्पादनीय बनाता है, स्कैनर के उत्तरों को सभी के लिए सही बनाता है, और निर्भरता अपग्रेड को चुपचाप बहाव के बजाय समीक्षा योग्य diff में बदल देता है।
दूसरा आधा हिस्सा ताल है। भेद्यताएँ हर दिन प्रकाशित होती हैं, इसलिए तिमाही में एक बार चलाया गया स्कैन एक स्नैपशॉट है जो दिनों में पुराना हो जाता है। उपयोगी आकार हर पुल रिक्वेस्ट पर स्कैन है जो लॉकफ़ाइल को छूता है, साथ ही मुख्य शाखा का निर्धारित स्कैन — टेस्ट सूट जैसा ही चक्र, उसी गुण के साथ: नई एडवाइज़री जिस दिन प्रकाशित होती है, उसी दिन हरे बिल्ड को लाल कर देती है, जब समाधान संस्करण बढ़ाना होता है, घटना के बाद की समीक्षा नहीं। इस साइट पर ब्राउज़र स्कैनर उसी चक्र का मैनुअल संस्करण है: dependabot बंप के बाद, या रिलीज़ से पहले, लॉकफ़ाइल पेस्ट करें और उस ट्री की पुष्टि करें जिसे आप शिप करने वाले हैं।
ठीक किए गए संस्करण, ब्रेकिंग बदलाव, और कब पैच करें बनाम पिन करें
स्कैन में हर मिलान में एक ठीक किया गया संस्करण होता है — पहला रिलीज़ जिसमें भेद्यता समाप्त हो जाती है — या ईमानदार “कोई प्रकाशित नहीं है”। सामान्य मामला पैच या माइनर रिलीज़ है, और अपग्रेड लॉकफ़ाइल में एक पंक्ति का बदलाव है। लेकिन ठीक किया गया संस्करण हमेशा लेने के लिए सुरक्षित संस्करण नहीं होता: मेजर-संस्करण छलाँग उस व्यवहार को बदल सकती है जिस पर आपका कोड निर्भर है, और कल जारी किया गया समाधान वास्तविक दुनिया में केवल एक दिन का परीक्षण पा चुका है। निर्णय वही है जो किसी भी निर्भरता अपग्रेड का होता है: चेंजलॉग पढ़ें, टेस्ट चलाएँ, और पहले उन पैकेजों को अपग्रेड करें जिन्हें आप वास्तव में इंपोर्ट करते हैं।
जब कोई ठीक किया गया संस्करण नहीं है, तो विकल्प तीन तक सिमट जाते हैं: निर्भरता हटाएँ यदि किसी को उसकी ज़रूरत नहीं है, उसे बनाए रखे गए विकल्प से बदलें, या भेद्य कोड पथ को कम करें — प्रभावित फ़ंक्शन को अविश्वसनीय इनपुट देना बंद करें, या कॉल को उस जाँच के पीछे रखें जिसका एडवाइज़री वर्णन करती है — और अपडेट के लिए एडवाइज़री पर नज़र रखें। आपको जो नहीं करना चाहिए वह है भेद्य संस्करण को पिन करके भूल जाना: पिन एक निर्णय है, और वह लॉकफ़ाइल या इश्यू ट्रैकर में एक टिप्पणी का हकदार है जिसमें बताया गया हो कि क्यों, और उसे फिर से देखने की तारीख हो। किसी भी बदलाव के बाद फिर से स्कैन करें; स्कैनर को सेकंड लगते हैं, और दूसरा स्कैन ही एकमात्र प्रमाण है कि पहले स्कैन के निष्कर्ष समाप्त हो गए हैं।