Ing. Calogero Bono
GitHub ने 20 अक्टूबर 2026 को package firewall पेश किया, एक ऐसा फ़िल्टर जो उन कंप्यूटरों और सार्वजनिक रजिस्ट्री के बीच बैठता है जहाँ से पैकेज डाउनलोड होते हैं। यह अभी GitHub Enterprise Cloud के सभी ग्राहकों के लिए पब्लिक प्रीव्यू में है और सिर्फ npm को सपोर्ट करता है। इसका लक्ष्य इंस्टॉलेशन के समय हमला करने वाले मैलवेयर को रोकना है, एक ऐसा जोखिम जो AI एजेंट और बिल्ड सिस्टम के लिए ज़्यादा बड़ा है, क्योंकि वे बिना किसी की निगरानी के डिपेंडेंसी इंस्टॉल करते हैं। अगर आप सॉफ़्टवेयर बनाते हैं या ऐसे लोगों को संभालते हैं, तो यह संकेत है कि सप्लाई चेन की सुरक्षा किस दिशा में जा रही है।
तथ्यों में जाने से पहले कुछ शब्द। एक रजिस्ट्री (registry) वह ऑनलाइन भंडार है जहाँ से पैकेज डाउनलोड होते हैं, जैसे JavaScript के लिए npm। एक डिपेंडेंसी दूसरों के लिखे कोड का वह हिस्सा है जिसे आपका प्रोजेक्ट इस्तेमाल करता है। CI/CD वे स्वचालित प्रक्रियाएँ हैं जो सॉफ़्टवेयर को बिल्ड और प्रकाशित करती हैं। एक SLSA attestation एक जाँचने योग्य घोषणा है कि पैकेज कैसे और किसने बनाया। मेटाडेटा पैकेज की जानकारी है, जैसे उपलब्ध संस्करणों की सूची।
यह package firewall क्या है?
जैसा कि GitHub के आधिकारिक changelog में लिखा है, हाल के समय में ऐसे मैलवेयर हमलों की लहर आई है जो पैकेज इंस्टॉल होने के पल का फ़ायदा उठाते हैं। एजेंट और CI runner खास निशाने पर हैं, क्योंकि वे किसी इंसान के बिना कोई काम या बिल्ड पूरा करने के लिए डिपेंडेंसी इंस्टॉल करते हैं।
यह firewall endpoints, यानी आपके डिवाइस, या आंतरिक रजिस्ट्री और ऊपरी स्तर के पैकेज रिपॉज़िटरी के बीच काम करता है। जैसा कि The Hacker News बताता है, GitHub इसे इस तरह समझाता है। «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate,» यानी इंस्टॉलेशन के समय लागू होने वाले नियमों का एक दरवाज़ा।
यह मामला सिर्फ़ सिद्धांत का नहीं है। The Register ने एक अभियान पर रिपोर्ट किया है जिसमें हमलावरों ने GitHub issues को एक घंटे से कम में 61 सार्वजनिक repository के खिलाफ सप्लाई चेन हमले में बदल दिया। हमारे पास जो पेज है उसमें और जानकारी नहीं है, इसलिए हम नहीं कह सकते कि दोनों ख़बरें आपस में जुड़ी हैं या नहीं।
यह कैसे काम करता है और कौन से नियंत्रण देता है?
प्रक्रिया दो चरणों में होती है। पहले एडमिन अपनी enterprise के लिए नियम तय करते हैं। फिर कोडिंग एजेंट और CI/CD होस्ट सीधे सार्वजनिक रजिस्ट्री की जगह firewall की ओर इशारा करते हैं। मेटाडेटा के अनुरोध और डाउनलोड, दोनों firewall से होकर गुज़रते हैं, जो नीति के आधार पर उन्हें जाँचता है।
उपलब्ध नियंत्रण
The Hacker News की सूची के अनुसार ये नियंत्रण उपलब्ध हैं।
- ज्ञात मैलवेयर को ब्लॉक करना, जो GitHub Advisory Database की सक्रिय चेतावनियों की जाँच करके होता है।
- गंभीरता के आधार पर कमज़ोरियों को ब्लॉक करना, वह भी उसी database से। डिफ़ॉल्ट रूप से सिर्फ़ «Critical only» स्तर ब्लॉक होता है, लेकिन «High or higher», «Medium or higher» या «Any severity» भी चुने जा सकते हैं।
- attestation में गिरावट को ब्लॉक करना। firewall माँगे गए संस्करण के attestation की तुलना पिछले संस्करणों से करता है और SLSA attestation न मिलने पर डाउनलोड रोक देता है।
- नए इंस्टॉल स्क्रिप्ट को ब्लॉक करना, यानी वे स्क्रिप्ट जो preinstall या postinstall hook के साथ चलती हैं और संवेदनशील डेटा चुराने में इस्तेमाल हो सकती हैं।
- इंतज़ार की अवधि (cooldown), जो कॉन्फ़िगर की गई न्यूनतम आयु से नए संस्करणों को इंस्टॉल होने से रोकती है।
cooldown 1 से 365 दिन तक हो सकता है। डिफ़ॉल्ट मान 1 दिन है और इसे 0 रखकर बंद किया जा सकता है।
अगर कोई सही पैकेज ब्लॉक हो जाए तो?
अगर कोई पैकेज गलती से ब्लॉक हो जाए, तो उपयोगकर्ता अपवाद (exception) की माँग कर सकता है। GitHub के लिए यह प्रक्रिया GitHub Advanced Security की दूसरी सुविधाओं जैसी ही है। The Hacker News के अनुसार, अनुरोध को enterprise के एडमिन और सुरक्षा प्रमुख मंज़ूर कर सकते हैं।
इसकी कीमत कितनी है और इसे कौन इस्तेमाल कर सकता है?
यह सेवा पब्लिक प्रीव्यू में सभी GitHub Enterprise Cloud ग्राहकों के लिए उपलब्ध है, डेटा रेज़िडेंसी वाले संस्करण समेत। प्रीव्यू के दौरान यह मुफ़्त है। आम उपलब्धता आने पर GitHub का कहना है कि यह मापे गए उपयोग के आधार पर शुल्क लेगा, कुछ-कुछ Actions की बिलिंग जैसे तरीके से।
GitHub बताता है कि प्रीव्यू का मकसद infrastructure को मज़बूत करना और ग्राहकों के अनुरोधों के आधार पर नई सुविधाएँ जोड़ना है। कॉन्फ़िगरेशन के निर्देश के लिए वह Protecting endpoints with package firewall दस्तावेज़ की ओर इशारा करता है।
इतनी चर्चा इंतज़ार की अवधि पर क्यों है?
cooldown सबसे सीधा और शायद सबसे व्यापक नियम है। The Hacker News याद दिलाता है कि पिछले एक साल में npm, Python, Visual Studio Code, Ruby, Bun, pnpm और Yarn में ऐसी ही प्रतीक्षा अवधि लाई गई है। सिद्धांत यह है कि नया प्रकाशित और अभी तक जाँचा न गया संस्करण तुरंत किसी बिल्ड में न पहुँचे।
यह सबसे ज़्यादा उस हमले के खिलाफ मदद करता है जिसमें किसी maintainer का account हाईजैक करके लोकप्रिय पैकेज का ज़हरीला संस्करण जारी किया जाता है। यह इंतज़ार तेज़ी से फैलने को रोकता है, चाहे वह हाथ से हो या स्वचालित।
वही लेख बताता है कि Rust 1.100, जो 12 नवंबर 2026 को आएगा, crate के लिए कॉन्फ़िगर करने योग्य न्यूनतम प्रकाशन आयु जोड़ सकता है। इस विकल्प का नाम «global-min-publish-age» है और यह cargo/config.toml फ़ाइल में रहता है। अगर यह निर्दिष्ट न हो, तो सात दिन का डिफ़ॉल्ट इंतज़ार लागू होता है।
इसका दूसरा पहलू Socket ने उजागर किया है, जिसका हवाला The Hacker News देता है। «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception,» कंपनी कहती है। वह यह भी जोड़ती है कि जाँच से बचा कोई रिलीज़ बस cooldown की अवधि पार कर सकता है। Socket के अनुसार इसका असली फ़ायदा यह है कि शोधकर्ताओं, maintainers और रजिस्ट्री को कार्रवाई का समय मिलता है।
ध्यान रखने योग्य सीमाएँ
- अभी firewall सिर्फ़ npm को सपोर्ट करता है। PHP, Python या दूसरे ecosystem वाले इसमें शामिल नहीं हैं, और स्रोत दूसरे रजिस्ट्री के लिए कोई तारीख नहीं बताते।
- यह सिर्फ़ GitHub Enterprise Cloud ग्राहकों के लिए है। स्रोत छोटे प्लान के बारे में कुछ नहीं कहते।
- हम अभी प्रीव्यू में हैं। सुविधाएँ, infrastructure और कीमतें बदल सकती हैं, और उपयोग-आधारित शुल्क अभी तय नहीं हुआ है।
- प्रभावशीलता पर हमारे पास कोई स्वतंत्र आँकड़े नहीं हैं। स्रोत GitHub के बयान दोहराते हैं, असली मैलवेयर पर परीक्षण नहीं, और गलत सकारात्मक मामलों की संख्या भी नहीं बताई गई है।
- जैसा Socket याद दिलाता है, cooldown दुर्भावनापूर्ण कोड को हानिरहित नहीं बनाता। जो संस्करण पकड़ में नहीं आया, वह इंतज़ार की अवधि के बाद भी छिपा रह सकता है।
डिजिटल काम करने वालों के लिए इसका मतलब
व्यावहारिक बात यह है कि सुरक्षा अब बाद में जाँच से हटकर इंस्टॉल से पहले जाँच की ओर जा रही है। जो लोग AI एजेंट के साथ विकसित करते हैं जो खुद लिखते और इंस्टॉल करते हैं, उनके लिए इसका अर्थ है किसी एक एजेंट पर भरोसा करने के बजाय एक केंद्रीय नियम रखना। अगर आप AI की मदद से विकास टूल इस्तेमाल करते हैं, तो हमारे लेख vibe coding per la PMI में बताए गए जोखिमों को दोबारा पढ़ना उपयोगी होगा।
भारतीय पाठकों के लिए भी इसका असर अनुपालन तक जाता है। सॉफ़्टवेयर की सप्लाई चेन उस विषय का हिस्सा है जिसे हम NIS2 विक्रेता रजिस्टर की गाइड में कवर करते हैं। यह दिखा पाना कि पैकेज लिखित नियमों वाले फ़िल्टर से गुज़रते हैं, एक ठोस तर्क है, हालाँकि किसी भी स्रोत ने firewall को NIS2 से नहीं जोड़ा है।
जो लोग open source का बड़े पैमाने पर उपयोग करते हैं, उन्हें याद रखना चाहिए कि हर डिपेंडेंसी एक विक्रेता है। इस पर हमने व्यवसाय में open source वाले विस्तृत लेख में चर्चा की है। जो लोग Enterprise ग्राहक नहीं हैं, वे भी मौजूदा टूल से यही विचार अपना सकते हैं, जैसे कुछ पैकेज मैनेजर द्वारा दिए जाने वाले इंतज़ार की अवधि के विकल्प।
build और production सर्वर के लिए अपडेट और isolation भी मायने रखते हैं। अगर आप किसी और की देखरेख वाला infrastructure चाहते हैं, तो हमारी hosting और प्रबंधित सर्वर सेवा मौजूद है। और अगर आप कस्टम प्रोजेक्ट पर विचार कर रहे हैं, तो रास्ता कस्टम सॉफ़्टवेयर विकास में मिलेगा।
हमारी राय
विचार सही है। किसी पैकेज को कंप्यूटर पर चलने से पहले रोकना उसके बाद पता लगाने से ज़्यादा असरदार है, और यह काम एक केंद्रीय बिंदु पर करने से हर डेवलपर या हर एजेंट के अनुशासन पर निर्भर नहीं रहना पड़ता। GitHub का बिना निगरानी वाले एजेंटों से शुरुआत करना समस्या की एक ईमानदार पढ़ाई लगती है।
इसके बारे में दो आपत्तियाँ हैं। पहली व्यावसायिक है। इतनी उपयोगी सुरक्षा, जो फ़िलहाल Enterprise स्तर तक सीमित है और प्रीव्यू के बाद उपयोग-आधारित शुल्क पर होगी, छोटी टीमों को असुरक्षित छोड़ सकती है, जो अक्सर सबसे ज़्यादा जोखिम में होती हैं। दूसरी तकनीकी है। कई नियंत्रण GitHub के database और समय पर निर्भर हैं, और समय कोई गारंटी नहीं है, जैसा Socket खुद मानता है।
इसलिए हम इसे अंतिम ढाल नहीं मानते। यह एक अतिरिक्त परत है, जो निर्भरताओं की समीक्षा, संस्करणों को लॉक करने और एजेंटों के लिए न्यूनतम अनुमतियों के साथ सबसे ज़्यादा काम आती है। अगर आपको लगता है कि firewall चालू करना काफ़ी है, तो आप एक झूठी सुरक्षा में हैं।
अक्सर पूछे जाने वाले सवाल
क्या GitHub का package firewall मुफ़्त है?
हाँ, लेकिन सिर्फ़ प्रीव्यू के दौरान। GitHub का कहना है कि आम उपलब्धता पर मापे गए उपयोग के आधार पर शुल्क लगेगा, कुछ-कुछ Actions की तरह। कीमतें अभी तय नहीं हुई हैं।
क्या यह सिर्फ़ npm के साथ काम करता है?
हाँ, अभी यह सिर्फ़ npm पैकेज को सपोर्ट करता है। स्रोत दूसरे ecosystem के लिए कोई तारीख नहीं बताते। अगर आप दूसरी भाषाएँ इस्तेमाल करते हैं, तो फ़िलहाल आपको दूसरे बचाव के उपाय खोजने होंगे।
इसे कौन इस्तेमाल कर सकता है?
सभी GitHub Enterprise Cloud ग्राहक, डेटा रेज़िडेंसी वाले संस्करण समेत। स्रोत किसी और प्लान का ज़िक्र नहीं करते। एडमिन पूरी enterprise के लिए नियम कॉन्फ़िगर करते हैं।
अगर यह कोई सही पैकेज ब्लॉक कर दे तो क्या होगा?
उपयोगकर्ता अपवाद की माँग कर सकता है। The Hacker News के अनुसार अनुरोध को एडमिन और सुरक्षा प्रमुख मंज़ूर कर सकते हैं। GitHub के अनुसार यह प्रक्रिया Advanced Security की दूसरी सुविधाओं जैसी ही है।
क्या इंतज़ार की अवधि मैलवेयर रोकने के लिए काफ़ी है?
नहीं। यह नई जारी हुई संस्करणों के खिलाफ समय बचाने में मदद करती है, लेकिन Socket याद दिलाता है कि दुर्भावनापूर्ण कोड उम्र बढ़ने से हानिरहित नहीं होता। जो रिलीज़ पकड़ में नहीं आई, वह इंतज़ार की अवधि पार कर सकती है।
आम उपलब्धता तक क्या देखें
आने वाले महीनों में तीन चीज़ों पर नज़र रखें। GitHub द्वारा तय किया जाने वाला उपयोग-आधारित शुल्क, npm से आगे इसके विस्तार की संभावना, और 12 नवंबर 2026 को आने वाले Rust 1.100 में न्यूनतम आयु का आना। तब तक आप इन कदमों के साथ तैयारी कर सकते हैं।
- CI और एजेंट द्वारा इस्तेमाल होने वाली डिपेंडेंसी की सूची बनाएँ, और तय करें कि बिना निगरानी के कौन क्या इंस्टॉल कर सकता है।
- नए संस्करणों पर इंतज़ार की अवधि लागू करने पर विचार करें, यह जानते हुए कि इससे सही सुधार भी देर से आएँगे।
- अपवादों के लिए एक प्रक्रिया बनाएँ, जिसमें एक ज़िम्मेदार व्यक्ति जल्दी मंज़ूरी दे, लेकिन लिखित रिकॉर्ड के साथ।
