Red Hat Cloud Services में दुर्भावनापूर्ण npm पैकेजों का पता चला

मूल लेख ↗ Hacker News चर्चा ↗

घटना का दायरा

  • दुर्भावनापूर्ण npm पैकेज Red Hat Cloud Services के JavaScript client repos में डाले गए, apparently एक compromised CI/CD pipeline (GitHub Actions + OIDC) के जरिए, न कि चोरी की गई static credentials के जरिए।
  • प्रभावित पैकेज frontend libraries हैं जो कुछ Red Hat container images में compile की जाती हैं; प्रभाव मुख्यतः उन images के consumers पर दिखता है, सीधे npm users पर नहीं।
  • थ्रेड में जुड़े कई analyses shared pipelines की सूची बनाते हैं और इसे व्यापक “mini‑Shai-Hulud” / TrapDoor‑style npm worms का हिस्सा वर्गीकृत करते हैं।

क्या यह npm की समस्या है या ecosystem की समस्या?

  • कई लोगों का तर्क है कि सभी modern language package managers (npm, PyPI, crates.io, Composer, NuGet, RubyGems, आदि) में वही मूल जोखिम साझा है: कोई भी publish कर सकता है, code व्यापक authority के साथ चलता है, और maintainers अक्सर individual होते हैं।
  • दूसरों का कहना है कि npm और भी खराब है क्योंकि:
    • Lifecycle/postinstall scripts जो install के समय default रूप से arbitrary code चलाते हैं।
    • बहुत बड़े, गहराई तक nested dependency graphs और बहुत छोटे packages की संस्कृति।
    • तेज़ी से बदलती “हमेशा latest पर update करो” की norms।
  • Counterpoint: lifecycle hooks और similar features कई systems में मौजूद हैं (dpkg/rpm, RubyGems, Pip, NuGet), इसलिए blame केवल npm पर केंद्रित करना कुछ लोगों को unfair या biased लगता है।

प्रस्तावित Mitigations

  • Dependency cooldowns (1–7 days) ताकि अभी-अभी प्रकाशित versions install न हों, और उस window में scanners तथा maintainers malware पकड़ सकें। pnpm, Yarn 4, npm 11, pip, uv, और third-party tools के माध्यम से supported।
    • समर्थक: सस्ता, और हालिया attacks में प्रभावी जो घंटों/दिनों के भीतर पकड़े गए।
    • संशयवादी: यदि सभी delay करें, तो attackers time bombs जोड़ सकते हैं; urgent CVEs को फिर भी संभालना होगा।
  • CI/CD को harden करना:
    • “build/test” को “sign/release” jobs से अलग रखें ताकि worms automatically republish न कर सकें।
    • trusted publishers, MFA, staged publishing का उपयोग करें; लेकिन यदि CI itself compromised हो, तो ये मदद नहीं करते।
  • Blast radius कम करना:
    • installs/tests को containers, sandboxes, या कम-privileged environments में चलाएँ।
    • ऐसे dev machines का उपयोग न करें जिनमें sensitive keys या wallets भी हों।
  • Governance और packaging models:
    • Linux distros की तरह emulate करने की calls: curated maintainers, review layers, slower channels (testing/unstable)।
    • dependencies को vendor करने, exact versions pin करने, अनावश्यक libraries से बचने, और flatter, smaller dependency graphs वाले ecosystems को prefer करने के सुझाव।

सांस्कृतिक आलोचनाएँ

  • कई टिप्पणियाँ JavaScript/Web culture को दोष देती हैं: tiny packages, rapid change, deep transitive deps, और automated updates पर भारी निर्भरता।
  • अन्य लोग ज़ोर देते हैं कि users सुविधा को security से ऊपर रखते हैं जब तक कुछ टूट न जाए; security को एक invisible requirement माना जाता है जिसे अक्सर बाद में जोड़ा जाता है।