การวิเคราะห์หลังเหตุการณ์โจมตีซัพพลายเชนของ Tinycolor

 (sigh.dev)
3 คะแนน โดย GN⁺ 2025-09-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีเหตุการณ์ที่แพ็กเกจ npm จำนวนมากซึ่งมี @ctrl/tinycolor แบบโอเพนซอร์สรวมอยู่ ถูกติดมัลแวร์เวอร์ชันอันตราย โดยสาเหตุมาจากการ ขโมย npm token ผ่าน GitHub Actions workflow ในรีโพซิทอรีที่ใช้ทำงานร่วมกัน
  • ผู้โจมตีใช้ npm token ที่มีสิทธิ์กว้างในการเผยแพร่โค้ดอันตรายไปยังประมาณ 20 แพ็กเกจ และในนั้น @ctrl/tinycolor มีจำนวนดาวน์โหลดรายสัปดาห์สูงถึง 2 ล้านครั้ง จึงมีผลกระทบสูง
  • เวอร์ชันที่ติดมัลแวร์จะรันเพย์โหลดอันตรายในขั้นตอน postinstall และทีมความปลอดภัยของ GitHub กับ npm ได้ตอบสนองอย่างรวดเร็วด้วยการลบและจัดการกู้คืน
  • ผู้เขียนได้จัดทำแผนยกระดับความปลอดภัยเพื่อป้องกันการเกิดซ้ำ เช่น การย้ายไปใช้ Trusted Publishing(OIDC), การลดสิทธิ์ของโทเค็นให้เหลือน้อยที่สุด, การบังคับใช้ 2FA และการใช้ความสามารถของ pnpm
  • เหตุการณ์ครั้งนี้แสดงให้เห็นถึง ความเปราะบางของความปลอดภัยซัพพลายเชนซอฟต์แวร์ และเป็นกรณีตัวอย่างที่ชี้ถึงความจำเป็นในการปรับปรุงฟีเจอร์ด้านความปลอดภัยและแนวปฏิบัติด้านความปลอดภัยของระบบนิเวศ npm โดยรวม

TL;DR

  • เกิดเหตุ GitHub Actions workflow อันตรายถูกพุชเข้าไปยังรีโพซิทอรีที่ใช้ร่วมกันเพื่อ ขโมย npm token
  • ผู้โจมตีใช้โทเค็นดังกล่าวเผยแพร่ เวอร์ชันอันตรายของ 20 แพ็กเกจ และในนั้น @ctrl/tinycolor มีจำนวนดาวน์โหลดสูงจึงมีผลกระทบในวงกว้าง
  • ไม่มีการเจาะบัญชีส่วนตัวหรือรีโพซิทอรีโดยตรง และไม่มีการฟิชชิงหรือการติดตั้งมัลแวร์ในเครื่องของผู้เขียน
  • ด้วยการตอบสนองอย่างรวดเร็วของทีมความปลอดภัย GitHub/npm เวอร์ชันอันตรายจึงถูกลบออก และหลังจากนั้นได้เผยแพร่เวอร์ชันสะอาดใหม่อีกครั้งเพื่อจัดการแคช

ลำดับการค้นพบเหตุการณ์ (How I Found Out)

  • ช่วงบ่ายของวันที่ 15 กันยายน สมาชิกชุมชน Wes Todd แจ้งปัญหาผ่าน Bluesky DM
  • ตอนนั้นทีมความปลอดภัยของ GitHub/npm ได้เริ่มรวบรวมรายชื่อแพ็กเกจที่ได้รับผลกระทบและดำเนินการลบแล้ว
  • เบาะแสแรกที่ถูกแชร์คือชื่อแบรนช์อันตรายว่า 'Shai-Hulud' ซึ่งเป็นชื่อ sandworm จากจักรวาล Dune

สิ่งที่เกิดขึ้นจริง (What Actually Happened)

  • มีผู้ร่วมงานจากรีโพซิทอรี angulartics2 ที่เคยทำงานร่วมกันมานานแล้วและยังคงมีสิทธิ์ระดับแอดมินอยู่
  • npm token ที่เก็บไว้ในรีโพซิทอรีนั้นถูกขโมยโดย GitHub Actions workflow อันตราย
  • ผู้โจมตีใช้โทเค็นนี้เผยแพร่แพ็กเกจประมาณ 20 รายการ รวมถึง @ctrl/tinycolor
  • ทีมความปลอดภัย GitHub/npm ลบเวอร์ชันอันตรายอย่างรวดเร็ว และผู้เขียนก็เผยแพร่เวอร์ชันใหม่ที่เชื่อถือได้อีกครั้ง

ผลกระทบ (Impact)

  • เมื่อติดตั้งเวอร์ชันอันตราย สคริปต์ postinstall จะถูกรันและก่อให้เกิดความเสี่ยงด้านความปลอดภัย
  • แนะนำให้ผู้ใช้ที่ได้รับผลกระทบอ้างอิง แนวทางตอบสนองทันที ของ StepSecurity

สภาพแวดล้อมการเผยแพร่และแผนรับมือ (Publishing Setup & Interim Plan)

  • เดิมใช้การเผยแพร่อัตโนมัติด้วยชุด semantic-release + GitHub Actions
  • แม้จะใช้ฟีเจอร์ npm provenance แต่ก็ไม่สามารถหยุดผู้โจมตีที่มีโทเค็นถูกต้องได้
  • ต่อจากนี้มีแผนจะนำ Trusted Publishing(OIDC) มาใช้เพื่อตัด static token ออก
  • ขณะนี้ได้เพิกถอนโทเค็นทั้งหมดแล้ว และกำลังใช้มาตรการความปลอดภัยเพิ่มเติม เช่น บังคับ 2FA, อนุญาตเฉพาะโทเค็นสิทธิ์แบบ granular และพิจารณาฟีเจอร์ minimumReleaseAge ของ pnpm

แนวทางปรับปรุงที่อยากเห็น (Publishing Wishlist)

  • ควรมีตัวเลือกบังคับใช้ OIDC-based Trusted Publishing ในระดับบัญชี npm
  • ต้องมีความสามารถในการบล็อกการเผยแพร่เมื่อไม่มี provenance และรองรับการผสาน semantic-release กับ OIDC อย่างสมบูรณ์
  • อยากให้ GitHub UI มีฟีเจอร์ การอนุมัติการเผยแพร่แบบแมนนวลด้วย 2FA
  • ควรสามารถใช้การป้องกันระดับ GitHub Environments ได้แม้ไม่มีการสมัคร Pro
  • ในหน้าของแพ็กเกจ npm ควรมี การแสดงว่ามีสคริปต์ postinstall หรือไม่ และเปิดเผยเหตุผลของเวอร์ชันที่ถูกลบ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-20
ความคิดเห็นจาก Hacker News

  • ใน repository นั้นยังคงมี GitHub Actions secret อยู่ ซึ่งก็คือ npm token ที่มีสิทธิ์ publish อย่างกว้างขวาง
    ข้อดีอย่างหนึ่งของ Trusted Publishing คือไม่จำเป็นต้องใช้ publish token ที่มีอายุยาวอีกต่อไป
    ตอนนี้จะใช้เฉพาะ token ที่ถูกสร้างขึ้นชั่วคราวบน CI VM และ token จะมีอายุเพียง 15 นาที
    ตอนนี้มีการใช้งานแล้วในหลาย ecosystem เช่น PyPI, npm, Cargo, Homebrew
    และกระบวนการ publish ก็ง่ายขึ้นจริงด้วย จึงอยากแนะนำให้ทุกคนลองใช้
    ถ้ายังรู้สึกว่าเอกสารไม่ชัดเจน ก็ขอความช่วยเหลือได้เสมอ
    ฝั่งผู้ดูแล ecosystem เองก็อยากให้ฟีเจอร์นี้ถูกใช้อย่างแพร่หลาย
    ดู เอกสารทางการของ Trusted Publishing

    • เพิ่งรู้ครั้งนี้เองว่าตอนนี้ npm รองรับ Trusted Publishing แล้ว
      ข่าวที่เกี่ยวข้อง
      สุดสัปดาห์นี้ตั้งใจจะลองเซ็ตอัปทันที

    • ตอนนี้อยากให้มี flag ใน repository ที่แสดงว่าเป็นโปรเจ็กต์ที่ใช้ฟีเจอร์แบบนี้
      จะได้บล็อก dependency package ที่ไม่ใช้มันได้ง่าย

  • ดูเหมือนประเด็นเรื่องการใส่ MFA (การยืนยันตัวตนหลายปัจจัย) เข้าไปในกระบวนการ deploy อัตโนมัติจะยังไม่ได้รับความสนใจมากพอ
    การ publish ผ่าน CI workflow แล้วให้ยืนยันการ publish ด้วย MFA prompt นั้นไม่ได้มีปัญหาอะไร แต่ตอนที่เคยดูครั้งก่อน มันซับซ้อนเพราะต้องเปิด HTTPS tunnel เพื่อส่งโค้ด
    อยากให้ npm หรือ GitHub มีวิธีให้ส่งหรือยืนยัน MFA code ระหว่าง CI ได้ง่าย ๆ ในตัวเลย

    • การ publish package มี 2 ขั้น: ขั้นแรกคืออัปโหลด package ไปยัง npmjs และอีกขั้นคือเปิดให้ผู้ใช้ใช้งานจริง
      ตอนนี้สองขั้นตอนนี้ถูกมัดรวมเป็นงานเดียวกัน
      ผมคิดว่าควรแยกมันออกจากกัน โดยให้ระบบ CI ทำการ build และอัปโหลดแบบอัตโนมัติอย่างเดียว
      ส่วนการนำ package ที่อัปโหลดแล้วออกสู่การใช้งานจริง ควรให้มนุษย์ล็อกอินเข้าเว็บไซต์ npmjs แล้ว publish แบบ manual พร้อม MFA เอง

    • จริง ๆ แล้วก็อดคิดไม่ได้ว่าแนวคิดเรื่อง package publishing อาจไม่จำเป็นตั้งแต่แรกหรือเปล่า
      ถ้า VCS คือ “source ที่แท้จริง” ก็น่าจะใช้งานได้ตรง ๆ โดยไม่ต้องมีขั้นตอน publish แยก
      ภาษา Go ก็ทำแบบนี้จริง ๆ
      import package ตรงจาก URL และจัดการ versioning ด้วย tag
      แบบนี้แค่เชื่อถือ VCS ก็พอ จึงลดพื้นผิวการโจมตีเพิ่มเติมได้
      ไม่ต้อง diff ไฟล์ archive แยกต่างหาก แค่ตรวจสอบในระดับ commit ก็พอ
      ปัญหาคือถ้าย้าย repository แล้ว import path จะเปลี่ยน แต่ก็มองได้ว่าเป็นข้อดีอย่างหนึ่งเหมือนกัน
      นอกเหนือจากนั้นก็ไม่ค่อยเข้าใจว่าการมีขั้นตอน publish แยกต่างหากให้อะไรเพิ่ม
      มันดูเหมือนของตกค้างจากยุคที่อัปโหลด tar archive ผ่าน FTP

  • เมื่อก่อนเคยทำงานกับ shared repository ชื่อ angulartics2
    ที่นั่นยังมี GitHub Actions secret ที่เก็บ npm token ซึ่งมีสิทธิ์ publish อย่างกว้างขวางอยู่จนถึงตอนนี้
    มีผู้ร่วมงานคนหนึ่งที่มีสิทธิ์กับหลายโปรเจ็กต์ด้วย และคาดว่านั่นคือเหตุผลที่ทำให้หลาย package ได้รับผลกระทบพร้อมกัน
    มีการ force push branch ใหม่ชื่อ Shai-Hulud พร้อม malicious github action workflow
    เพราะเป็นผู้ร่วมงานที่มีสิทธิ์ระดับแอดมิน workflow จึงรันได้ทันทีโดยไม่ต้อง review และ npm token ก็รั่วไหล
    token ที่รั่วถูกนำไปใช้ publish เวอร์ชันอันตรายให้กับ 20 package
    ส่วนใหญ่เป็น package ที่ไม่ได้ถูกใช้อย่างแพร่หลาย แต่ @ctrl/tinycolor เป็น package ยอดนิยมที่มียอดดาวน์โหลดราว 2 ล้านครั้งต่อสัปดาห์
    สิ่งที่ยังไม่เข้าใจคือ npm token ของ repository angulartics2 สามารถใช้ publish tinycolor ได้อย่างไร

    • ผมเองก็มีสิทธิ์ระดับแอดมินใน npm repository ของคนอื่น และช่วงหลัง ๆ release เกือบทั้งหมดก็เป็นผมทำ
      พอได้เป็นแอดมินแล้ว ก็ยิ่งอยากถือโอกาสแก้ปัญหาที่ค้างมานาน จน commit ในนามผมมีมากขึ้นเรื่อย ๆ
      เกือบจะตัดสินใจแล้วว่าจะใช้ Github action สำหรับ publish package แต่ก็กลัวมาตลอดว่าถ้า deploy ตรงด้วย 2FA จะเผลอ publish สถานะที่ไม่ใช่ master
      เพราะปัญหานี้เลยผัดการคุยกับแอดมินคนอื่นมาตลอด แต่พอเห็นว่ากลายเป็นแบบนี้แล้ว ก็รู้สึกว่าที่เลื่อนเอาไว้คงถูกแล้ว
      ไม่รู้ว่าคำตอบที่ถูกคืออะไร แต่การฝาก credential ไว้กับบุคคลที่สามคงไม่ใช่คำตอบที่ดีแน่

    • ทำไม npm token ของ angulartics2 ถึงมีสิทธิ์ deploy tinycolor ได้?
      นี่ดูเป็นเส้นทางการแฮ็กองค์กรแบบดั้งเดิมมาก
      “บาปเก่า” ที่เขียนทิ้งไว้เมื่อก่อนมักย้อนกลับมาหลอกหลอนเสมอ
      เมื่อหลายปีก่อนองค์กรของเราก็เคยเจอแบบนี้
      ช่องโหว่ที่ค้างอยู่ใน editor เก่าที่เปลี่ยนมาแล้วถึงสามรุ่น ยังเปิดทางให้อัปโหลดขึ้นเซิร์ฟเวอร์ได้
      ไม่ได้เจอตอน build time แต่สุดท้ายเจอจากการสแกน URL

    • ขอโทษถ้าอธิบายไม่ชัด
      token นี้มีสิทธิ์ publish แบบ global สำหรับ npm package ทั้งหมดของผม

  • ตลอด 10 ปีที่ผ่านมา ผมยืนกรานเรื่อง manual release มาโดยตลอด
    มักโดนคัดค้านเยอะเสมอ แต่ตอนนี้ดูเหมือนจะไม่ใช่แนวคิดที่ประหลาดอะไรแล้ว
    ผมรู้ว่า CI/CD มันดูเท่ แต่พอเห็นกรณีนี้กับประเด็น CF ช่วงหลัง ๆ ก็ยิ่งมีหลักฐานว่าระบบอัตโนมัติอาจทำให้เกิดปัญหาร้ายแรงได้ง่ายกว่าเดิม
    สมัยเคยทำงานที่ BigBank เวลาจะ deploy production ต้องมีคนเฝ้าอย่างน้อยห้าคนและผ่านขั้นตอนมากมาย แต่ก็ทำให้รู้แน่ชัดว่ากำลัง deploy อะไร

    • เห็นด้วยมาก
      ไม่ใช่ว่าเพราะ GitHub Actions หรือสคริปต์ release อัตโนมัติไม่ดี แต่ผมคิดว่าวิธีแบบเก่าที่ build เอง เซ็นเอง อัปโหลด tarball เอง แล้วค่อยตรวจสอบ ปลอดภัยกว่ามาก
      ระบบ distribution (เช่น ระบบแพ็กเกจของ Debian) ยังมีขั้นตอนตรวจสอบแยกต่างหากด้วย ซึ่งเป็นเหตุผลหนึ่งว่าทำไมตอนเหตุการณ์ xz อินเทอร์เน็ตทั้งโลกถึงไม่โดนเจาะไปหมด
      อย่างน้อยควรบังคับให้มีขั้นตอนที่มนุษย์เซ็น binary ด้วยตัวเองก่อน release จะถูก publish
      และเพราะยังมีปัญหาที่ผู้โจมตีอาจเพิ่มตัวเองเป็น maintainer แล้วเซ็นด้วยกุญแจของตัวเองได้ จึงต้องมีการจัดการ trusted key แบบเดียวกับระบบแพ็กเกจของ distribution ควบคู่ไปด้วยถึงจะปลอดภัยขึ้น
      ถ้า threat model ของผมตั้งอยู่บนแนวคิดว่า “แค่ GitHub account หรือ API key หลุดอันเดียว ผู้ใช้ทั้งหมดก็พังได้” ก็คงต้องย้อนถามตัวเองจริง ๆ ว่านี่สมเหตุสมผลหรือไม่

  • การใช้ 2FA สำหรับ publishing ก็ดี แต่จะปลอดภัยกว่ามากถ้าต้องให้ผู้เขียนหลายคนลงนามยืนยันด้วยลายเซ็นเข้ารหัส
    ไม่ควรให้การเจาะคนเพียงคนเดียวทำให้การโจมตีสำเร็จได้

    • หลาย package มีผู้เขียนแค่คนเดียว

    • การบังคับให้มีลายเซ็นจากหลายผู้เขียนก็ดี แต่ถ้ามีการตรวจสอบลายเซ็นไม่ว่ากับ commit, tag, artifact หรืออะไรก็ตาม ก็สามารถป้องกันการโจมตีส่วนใหญ่ได้
      ระบบแพ็กเกจของ distribution รองรับการตรวจสอบลายเซ็นอย่างจริงจัง แต่ language package manager ยังขาดระบบแบบนั้น
      ตัวอย่างเช่นกระบวนการ release ทางการของ runc จะถูกเซ็นทั้งหมดด้วยกุญแจของผู้ดูแล และกุญแจถูกเก็บใน Yubikey เป็นต้น
      ระบบ distribution ก็จัดการ keyring แยกต่างหากเพื่อใช้ตรวจสอบ source และ binary ทางการ
      ถ้ามีกระบวนการแบบนี้อยู่ การโจมตีครั้งนี้ก็น่าจะถูกสกัดได้ตั้งแต่หลายจุด
      ถึงจะ build ได้ตรงจาก CI แต่ในขั้นสุดท้ายก็ควรมีโครงสร้างที่ให้ maintainer เป็นคนเซ็นเอง
      ถ้า language package manager ยังไม่มี workflow แบบนี้ Trusted Publishing ก็เป็นทางเลือกที่แย่น้อยกว่าในตอนนี้
      แต่ถ้า GitHub account ถูกเจาะได้ (เช่น ขโมย cookie) ก็ยัง publish ได้อยู่ดี
      ใน GitHub มีการตั้งค่าความปลอดภัยอย่าง timeout สำหรับ Trusted Publishing ก็จริง แต่ผู้โจมตีก็อาจปิดมันได้
      แต่ถึงบัญชีผมจะโดนเจาะ ฝั่ง distribution ก็จะไม่ยอมรับการเปลี่ยนแปลงที่ไม่ได้เซ็นด้วยกุญแจที่ผมเซ็นไว้ จึงปลอดภัยกว่าค่อนข้างมาก
      อ้างอิง: ผมสังกัด SUSE แต่ก็อยากเห็นการรองรับการตรวจสอบ artifact เพิ่มขึ้นใน openSUSE, Arch, Gentoo เช่นกัน
      ลิงก์ที่เกี่ยวข้อง:

    • runc.keyring

    • keyring_validate.sh

    • release_sign.sh

    • runc.keyring ของ openSUSE

  • ผมเกลียด token มาก
    token ก็ไม่ต่างอะไรจาก static password
    คิดว่าควรมีวิธียืนยันตัวตนที่ดีกว่านี้
    ตัวอย่างเช่นการใช้ Github เป็น token provider ให้ AWS ดูจะเป็นแนวทางที่พอเหมาะกว่า
    การเชื่อมต่อ Github กับ AWS ด้วย OIDC
    แต่วิธีนี้ก็เป็นเพียงกรณีพิเศษเท่านั้น

    • OIDC flow ระหว่าง machine ถ้าทำดี ๆ ก็ปลอดภัยได้ แต่การตั้งค่าซับซ้อนเกินไป
      และสุดท้าย OIDC ก็ให้ความรู้สึกว่าเป็นแค่ “token ที่ซับซ้อนขึ้น” เท่านั้น
      ถ้าเป็นระบบอัตโนมัติที่ไม่มีมนุษย์คอยตรวจสอบ สุดท้ายก็ยังมีบางอย่างที่รั่วได้อยู่ดีไม่ทางใดก็ทางหนึ่ง (ไม่ว่าจะเป็น token หรือเครื่องมือสร้าง token)
      แม้แต่ในกรณี worm ครั้งนี้ OIDC ก็ไม่ใช่คำตอบระดับรากฐาน
      ถ้า Github workflow ถูกเจาะ ไม่ว่าจะใช้ OIDC หรือไม่ สุดท้ายก็แค่มีการ inject temporary identity เข้าไปใน environment
      สิ่งสำคัญจริง ๆ คือระบบที่ทำให้ผู้ใช้ที่ไม่ได้รับอนุญาตไม่สามารถรัน workflow ที่มี secret ได้
      ถ้าต้องการแบ่งสิทธิ์แบบละเอียด บางทีการลด scope ของ token อาจได้ผลกว่าการใช้ OIDC เสียอีก

    • เจตนาเดิมของ token คือให้มีอายุสั้นและมีขอบเขตสิทธิ์ (authZ) จำกัด
      แต่ในหลายกรณีมันกลับไม่เป็นแบบนั้น และถูกใช้แบบ static เหมือน password
      มีทางเลือกอย่าง oauth หรือ biscuits ที่จำกัดสิทธิ์ได้ละเอียด แต่ในทางปฏิบัติก็แทบไม่มีใครใช้

    • ตอนนี้ Trusted Publishing รองรับแล้วใน package registry หลายแห่งรวมถึง npm
      ข่าวที่เกี่ยวข้อง

    • อย่างที่คนอื่นพูดไว้ token ควรถูกออกให้เฉพาะหลังจากมีอายุสั้นหรือหลังผ่านการยืนยันแบบ manual เท่านั้น (เช่น MFA, passphrase)

    • ใช้ mTLS (TLS client certificate) น่าจะเป็นทิศทางที่ใกล้คำตอบที่สุด

  • มีใครรู้จักเครื่องมือหรือสคริปต์สาธารณะสำหรับตรวจ package npm ที่มีช่องโหว่ไหม?
    ดูเหมือนหน้า stepsecurity จะไม่มีเครื่องมือแบบนั้น

    • ถึงจะกันได้ไม่หมดทุกอย่าง แต่การนำ provenance-action มาใช้ก็เป็นความคิดที่ดี
      provenance-action

    • สำหรับประเด็นที่รู้จักอยู่แล้ว npm audit คือเครื่องมือพื้นฐาน

  • การ publish แบบใช้ local 2FA ไม่สามารถยืนระยะได้
    ทำไมการ publish แบบ local 2FA ถึงยืนระยะไม่ได้?
    ปัญหาที่แท้จริงคือ workflow การ publish แบบอัตโนมัติ
    ผมคิดว่า package npm ส่วนใหญ่ไม่ได้ publish บ่อยหรือมีขั้นตอน release ที่ซับซ้อนขนาดนั้น
    ให้คนทำ npm publish พร้อม 2FA เอง มันลำบากขนาดนั้นเลยหรือ?
    ถ้าแค่นี้ยังน่ารำคาญ ก็ควรกลับไปประเมินจำนวน package ที่ตัวเองดูแลใหม่

    • ก็มีเหตุผล
      ที่ผมหมายถึงคือกังวลเรื่องความผิดพลาดอย่าง publish จาก branch ผิด หรือ build ตกหล่น ในการ publish จาก local มากกว่า

  • ก็แอบคิดเหมือนกันว่าถ้า CI job ไป force push แก้ส่วนลึก ๆ ของ git history จะเป็นอย่างไร

  • สถานะปัจจุบันมันใช้งานต่อไปแบบเดิมไม่ไหวแล้ว
    แน่นอนว่าเราชมข้อดีทางเทคนิคของ OIDC token หรือโซลูชัน zero trust ได้
    แต่ในหมู่ maintainer ของ npm library ที่มียอดดาวน์โหลดระดับหลายล้าน จำนวนไม่น้อยจะไม่ใส่ใจเรื่องความปลอดภัยจริงจัง จนกว่าจะถูกแฮ็กหรือ npm บล็อกการ deploy ไปเลย
    และก็มักมีข้อเสนอที่เป็นไปไม่ได้อย่าง “เลิกใช้ dependency ทั้งหมดแล้วเหลือแต่ standard library” โผล่มาด้วย
    การลด dependency เป็นเรื่องดี แต่ไม่ได้ช่วยแก้ปัญหาที่มีอยู่แล้วเลย
    ในโลกจริง ทางเลือกมีแค่ให้คนเป็นหมื่นเป็นแสนเลิกใช้ npm แล้วกลับไปแก้โค้ดกันหมด หรือไม่ก็ให้ npm บังคับใช้ข้อกำหนดอย่าง 2FA, OIDC กับ package ที่มียอดดาวน์โหลดสูง และถ้าไม่ทำตามก็ห้าม deploy ไปเลย
    ชัดเจนอยู่แล้วว่าอะไรทำได้จริงมากกว่า
    ไม่เช่นนั้นชื่อเสียงของ npm ก็จะตกต่ำจนลงไปแตะพื้น และสุดท้ายก็จะกลายเป็นสถานการณ์แบบ XKCD 927