सबको dependency cooldown का उपयोग क्यों करना चाहिए
(blog.yossarian.net)- dependency cooldown ओपन source supply chain हमलों के अधिकांश हिस्से को कम कर सकने वाली एक सरल और प्रभावी सुरक्षा तकनीक है
- हमलावर आमतौर पर लोकप्रिय open source प्रोजेक्ट्स पर कब्ज़ा करके malicious code वितरित करते हैं, लेकिन अधिकांश हमलों की exposure अवधि एक हफ्ते से कम होती है
- नया version जारी होने के बाद एक तय अवधि (जैसे 7 दिन) का cooldown सेट करने पर, automatic updates से होने वाले infection जोखिम को काफ़ी हद तक घटाया जा सकता है
- Dependabot, Renovate, pnpm आदि पहले से ही cooldown फीचर को डिफ़ॉल्ट रूप से support करते हैं, और इसे सेट करना आसान है तथा कोई अतिरिक्त लागत नहीं है
- अगर package manager स्तर पर cooldown डिफ़ॉल्ट रूप से उपलब्ध हो, तो supply chain security मज़बूत करने और अनावश्यक alerts कम करने में मदद मिल सकती है
सप्लाई चेन हमलों की संरचना और समस्या
- अधिकांश supply chain attack एक ही पैटर्न का पालन करते हैं
- हमलावर लोकप्रिय open source प्रोजेक्ट्स के credentials की चोरी या CI/CD कमजोरियों का इस्तेमाल करके पहुँच हासिल करते हैं
- malicious बदलावों को distribution channels (PyPI, npm आदि) पर अपलोड करते हैं
- automatic updates या version pinning की कमी के कारण उपयोगकर्ता संक्रमित version इंस्टॉल कर लेते हैं
- security vendors इसे detect करके चेतावनी देते हैं, फिर package repository उस version को हटा देती है
- चरण (1)~(2) के बीच का अंतराल लंबा हो सकता है, लेकिन (2)~(5) चरण आमतौर पर कुछ घंटों से कुछ दिनों के भीतर पूरे हो जाते हैं, इसलिए हमलावर की सक्रिय अवधि छोटी होती है
- पिछले 18 महीनों के प्रमुख मामलों में हमले के संभव होने की अवधि (window of opportunity)
- xz-utils: लगभग 5 हफ्ते
- Ultralytics: 12 घंटे (चरण 1), 1 घंटा (चरण 2)
- tj-actions: 3 दिन
- chalk: 12 घंटे से कम
- Nx: 4 घंटे
- rspack: 1 घंटा
- num2words: 12 घंटे से कम
- Kong Ingress Controller: लगभग 10 दिन
- web3.js: 5 घंटे
- इनमें से 8 मामलों में हमले की अवधि 1 हफ्ते से कम थी, इसलिए अधिकांश को cooldown से रोका जा सकता था
cooldown की अवधारणा और प्रभाव
- cooldown का मतलब है कि नई dependency प्रकाशित होने के बाद एक तय अवधि तक उसके उपयोग को टाल दिया जाए
- इस दौरान security vendors यह पता लगा सकते हैं कि वह malicious है या नहीं
- फायदे
- यह व्यावहारिक रूप से प्रभावी है और बड़े पैमाने के अधिकांश हमलों को रोक सकता है
- इसे लागू करना बहुत आसान है और अधिकांश tools में मुफ़्त में configure किया जा सकता है
- Dependabot उदाहरण
version: 2 - package-ecosystem: github-actions directory: / schedule: interval: weekly cooldown: default-days: 7 - security vendors के सकारात्मक व्यवहार को प्रोत्साहित करता है: ज़रूरत से ज़्यादा alerts या प्रचार के बजाय तेज़ detection पर ध्यान केंद्रित करने में मदद करता है
निष्कर्ष और सुझाव
- 10 में से 8 हमलों की अवधि 1 हफ्ते या उससे कम थी, और 7 दिन के cooldown से अधिकांश को रोका जा सकता है
- 14 दिन का cooldown लागू करने पर xz-utils को छोड़कर सभी मामलों से बचाव संभव है
- cooldown कोई परफेक्ट समाधान नहीं है, लेकिन exposure risk को 80~90% तक कम करने का एक सरल तरीका है
- Dependabot, Renovate के अलावा package managers में भी cooldown का डिफ़ॉल्ट समर्थन जोड़ा जाना चाहिए
- supply chain security केवल तकनीकी समस्या नहीं, बल्कि सामाजिक भरोसे की संरचना का भी मुद्दा है, फिर भी cooldown एक व्यावहारिक mitigation के रूप में उपयोगी है
3 टिप्पणियां
असल में, अगर कोई समस्या नहीं है तो शायद अपडेट न करना ही बेहतर लगता है.
क्या पिछले वर्ज़न से बहुत अलग न होने वाले नए वर्ज़न को जोखिम उठाकर ज़रूर लागू करना चाहिए?
Hacker News राय
लोग चिंता करते हैं कि अगर तुरंत अपडेट नहीं किया गया तो वे गंभीर vulnerabilities के संपर्क में आ जाएंगे, लेकिन वास्तव में ज़्यादातर मामलों में ऐसा नहीं होता
बहुत-सा software continuous deployment से नहीं, बल्कि इस तरह चलता है कि ग्राहक खुद नया version install करते हैं, इसलिए updates हफ्तों या महीनों के अंतराल पर होते हैं
असली बात है dependency monitoring और सार्वजनिक vulnerabilities की जाँच। पहले यह आकलन करना चाहिए कि product वास्तव में प्रभावित है या नहीं, और तभी उस dependency को तुरंत अपडेट करना चाहिए
नया version आते ही आज ही update करना चाहिए, ऐसी सोच फैल चुकी है
वास्तविक बदलावों की समीक्षा किए बिना, “बाद में और मुश्किल होगा, इसलिए अभी कर लेते हैं” वाला तरीका अप्रभावी है
version number की सबसे आगे की लाइन में बने रहना सुरक्षा के लिहाज़ से उल्टा असर भी डाल सकता है
हमारी कंपनी में अगर scanner कोई critical vulnerability पकड़ ले, तो 7 दिनों के भीतर update करना पड़ता है
समयसीमा पार होते ही compliance violation के कारण जटिल प्रक्रिया शुरू हो जाती है, इसलिए ज़्यादातर लोग बस सब कुछ तुरंत update कर देते हैं
browser जैसे apps, जिनमें external input बहुत होता है, उन्हें बार-बार update करना चाहिए, लेकिन weather app जैसे सीमित input वाले मामलों में यह तुलनात्मक रूप से सुरक्षित है
इसके बजाय नियमित रूप से update करना और साथ में supply chain attack defense measures अपनाना अधिक कुशल हो सकता है
Debian stable model की तरह, जहाँ distribution shared dependencies को manage करता है और कुछ वर्षों में एक बार पूरा upgrade किया जाता है, वह तरीका अब ज़्यादा तर्कसंगत लगने लगा है
कुछ ecosystems बहुत तेज़ी से चलते हैं या अलग-अलग distributions के packaging systems पर्याप्त नहीं हैं
उदाहरण के लिए, Node.js libraries को apt से install करके project में इस्तेमाल करना अब भी मुश्किल है
बुनियादी बदलाव के बिना तेज़ी से चलने वाला ecosystem स्वस्थ नहीं कहा जा सकता
JS में पिछले 3 वर्षों में वास्तविक प्रगति लगभग नहीं हुई, लेकिन 3 साल पुराने project को फिर से build करना हो तो rewrite-स्तर की पीड़ा झेलनी पड़ती है
Arch जैसे distributions में तो कई बार कुछ भी नहीं होता
एक धारणा यह है कि supply chain attacks को रोकने के लिए dependency updates पर cooldown period रखना, 0-day रोकने के लिए तुरंत latest version अपनाने से बेहतर है
सवाल यह है कि update से नई vulnerability आने की संभावना ज़्यादा है या पुरानी vulnerability ठीक होने की
SemVer के हिसाब से patch versions तुलनात्मक रूप से सुरक्षित माने जा सकते हैं, इसलिए उनके लिए छोटा cooldown रखना जैसा तरीका अपनाया जा सकता है
उदाहरण के लिए, अगर 2.3.4 से 2.4.0 आया है, तो जब तक कोई ज़रूरी feature न हो, 2.4.1 आने तक इंतज़ार करना बेहतर हो सकता है
ज़्यादातर vulnerabilities जानबूझकर किए गए हमलों से नहीं, बल्कि सामान्य bugs से पैदा होती हैं
dependencies की संख्या और जटिलता सीमित रखने की policy एक और मज़बूत तरीका है
“सब कुछ करने वाली library” की बजाय, केवल छोटी और स्पष्ट उद्देश्य वाली dependencies जोड़नी चाहिए
साथ ही libraries अगर LTS versions दें, जिनमें सिर्फ security patches हों, तो management आसान हो जाता है
हर चीज़ दोबारा खुद implement करना बर्बादी हो सकता है। समस्या पैदा करने वाली “everything library” के ठोस उदाहरण जानने की इच्छा है
अगर आप कई libraries में एक ही developer पर भरोसा कर रहे हैं, तो package count से ज़्यादा trust relationship मायने रखती है
complexity का vulnerabilities से संबंध हो सकता है, लेकिन वही सीधा कारण नहीं है
अब short-term speed की जगह long-term maintenance को ध्यान में रखकर फैसले लेना संभव है
C++ दुनिया में यह कभी-कभी प्रतिस्पर्धी बढ़त का बिंदु भी बन जाता है
हर बार latest version में update करने का दबाव इस गलत विश्वास से आता है कि software हमेशा बेहतर होता जाता है
वास्तव में, यह ज्ञात bugs को नए अज्ञात bugs से बदलना भी हो सकता है
सार्वजनिक issues पर नज़र रखना और ज़रूरत होने पर ही patch करना अधिक तर्कसंगत है
यानी यह ऐसा मामला था जहाँ पुराना version उल्टा ज़्यादा सुरक्षित निकला
शायद इसलिए भी कि हम पहले से ही काफ़ी stable software इस्तेमाल कर रहे हैं
अगर सभी “थोड़ा इंतज़ार करें” कहें, तो अंत में tragedy of the commons जैसी स्थिति बन सकती है जहाँ कोई भी पहले validation नहीं करेगा
इंतज़ार बढ़ने पर technical debt जमा होती जाती है, इसलिए gradual updates और zero trust·monitoring जैसे mitigation measures की ज़रूरत है
इस बीच security scanners पहले ही vulnerabilities detect कर लेते हैं
अगर attacker unauthorized release डाल दे, तो कई बार तुरंत पता चल जाता है
cooldown का विचार अच्छा है, लेकिन यह जोखिम भी है कि attacker इसका दुरुपयोग कर झूठी आपातकालीन स्थिति बना दे
“urgent security patch” कहकर जल्दी install करने के लिए उकसाया जा सकता है, जबकि वह version वास्तव में malicious हो
ऐसे मनोवैज्ञानिक दबाव वाले हमलों के लिए तैयारी होनी चाहिए
cooldown का एक और कारण यह है कि maintainer को खुद breach समझने का समय मिले
attacker ऐसे समय निशाना बनाते हैं जब maintainer अनुपस्थित हो, जैसे vacation, conference, public holiday आदि
कई projects एक या दो लोगों द्वारा manage किए जाते हैं, इसलिए ऐसा time gap बहुत महत्वपूर्ण होता है
यह project की प्रकृति और attack surface पर निर्भर करता है
केवल “best practices” का पालन करने वाला दौर अब खत्म होना चाहिए
security एक contact sport की तरह है, जिसमें हर दिन बारीकियों पर आलोचनात्मक रूप से सोचना पड़ता है
cooldown की यह सीमा भी है कि सिर्फ समय बीतने से चीज़ें सुरक्षित नहीं हो जातीं
अगर कोई code देख ही नहीं रहा, तो एक हफ्ते बाद भी जोखिम वैसा ही रहेगा
इसके बजाय gradual rollout प्रभावी हो सकता है
हर consumer अपना delay factor सेट करे, ताकि ज़्यादा risk लेने वाले पहले समस्या का सामना करें,
और इस दौरान बाकी लोग सुरक्षित रहें
खतरनाक updates queue से हटा दिए जाएँ, ताकि delayed consumers उन्हें देखें ही नहीं
हाल के समय में कभी-कभी यह समझना मुश्किल हो जाता है कि सीधे पहिया फिर से बना लेना ज़्यादा संभालने लायक है या dependency tetris संभालने की कोशिश।
अगर कुछ समय के लिए कुछ गड़बड़ हो जाए तो अपने कोड को ठीक कर लेना आसान है, लेकिन dependency tetris में कौन-सा पहिया अचानक टेढ़ा हो गया, यह debug करना भी मुश्किल होता है।