सबको dependency cooldown का उपयोग क्यों करना चाहिए

• 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 के रूप में उपयोगी है