เหตุการณ์แฮ็กแพ็กเกจ npm `debug` และ `chalk`

 (aikido.dev)
1 คะแนน โดย GN⁺ 2025-09-09 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 8 กันยายน ตรวจพบการ แทรกมัลแวร์ ลงในแพ็กเกจ npm ยอดนิยม
  • มีแพ็กเกจที่ได้รับผลกระทบทั้งหมด 18 รายการ ซึ่งมียอดดาวน์โหลดรวมกันมากกว่า 2 พันล้านครั้งต่อสัปดาห์ ทั่วโลก
  • ผู้โจมตีได้ฝังโค้ดที่ ดักจับกิจกรรมคริปโตและ Web3 อย่างลับ ๆ จากเบราว์เซอร์ของผู้เยี่ยมชมเว็บไซต์ รวมถึงเปลี่ยนเส้นทางการอนุมัติในวอลเล็ตและการไหลของเงิน ไปยังบัญชีของผู้โจมตี
  • ยืนยันแล้วว่ามีการเพิ่ม โค้ด JavaScript ที่ถูกทำให้อ่านยาก ลงในไฟล์แพ็กเกจหลัก (index.js)
  • เหตุการณ์นี้ เริ่มขึ้นพร้อมกับการอัปเดตของแพ็กเกจเป้าหมาย และขณะนี้ชุมชนกำลังเร่งรับมือ

ภาพรวมของเหตุการณ์

  • ณ เวลา 13:16 UTC ของวันที่ 8 กันยายน ฟีดตรวจสอบความปลอดภัยของ Aikido ตรวจพบว่ามีการอัปโหลด หลายแพ็กเกจบน npm ที่มีมัลแวร์แฝงอยู่
  • แพ็กเกจเหล่านี้เป็นที่นิยมอย่างมากบน npm และมียอดดาวน์โหลด มากกว่า 2 พันล้านครั้งต่อสัปดาห์

วิธีการโจมตีและรายละเอียด

  • หลังการอัปเดตที่เป็นอันตราย พบว่า มัลแวร์ JavaScript จะทำงานอย่างลับ ๆ ในเบราว์เซอร์ของผู้เยี่ยมชมเว็บไซต์ ที่ใช้แพ็กเกจเหล่านี้
    • จุดประสงค์ของโค้ดนี้คือ เฝ้าดูกิจกรรมคริปโตและ Web3, ดัดแปลงการโต้ตอบกับวอลเล็ต และเปลี่ยนที่อยู่ปลายทางของการชำระเงินโดยไม่ได้รับอนุญาต
    • ผู้ใช้อาจไม่เห็นความเปลี่ยนแปลงใด ๆ บนหน้าจอ แต่เงินและสิทธิ์การอนุมัติอาจถูก ส่งไปยังที่อยู่คริปโตที่ผู้โจมตีกำหนด

การวิเคราะห์รายละเอียดมัลแวร์

  • ตัวอย่างเช่น ใน is-arrayish และแพ็กเกจอื่น ๆ มีการแก้ไขไฟล์ index.js เพื่อแทรก JavaScript ที่ซับซ้อนและถูกทำให้อ่านยาก
  • ภายในโค้ดมีการใช้ window.ethereum เพื่อ ตรวจสอบข้อมูลบัญชีวอลเล็ต และผ่านขั้นตอนยืนยันเงื่อนไขก่อนเรียกใช้โค้ดโจมตี
  • ภายในยังมีที่อยู่คริปโตหลายรายการ (เช่น Bitcoin, Ethereum) และลอจิกของฟังก์ชันสำหรับ แทนที่ที่อยู่วอลเล็ตและรายละเอียดธุรกรรมด้วยที่อยู่ของผู้โจมตี
  • ส่งผลให้เกิดความเสี่ยงที่ทรัพย์สินคริปโตของผู้ใช้จริงจะ รั่วไหลและถูกโอนย้ายโดยไม่ได้รับอนุญาตโดยที่เจ้าตัวไม่รู้ตัว

สถานการณ์ปัจจุบันและการตอบสนองของชุมชน

  • เวอร์ชันของแพ็กเกจอันตราย กำลังถูกลบออกจากรีจิสทรี npm หลักอย่างรวดเร็ว
  • ในชุมชน IT/โอเพ่นซอร์ส มีการดำเนินการอย่างเข้มข้นทั้ง การแนะนำให้หยุดใช้งานและอัปเกรดแพ็กเกจที่เกี่ยวข้อง รวมถึงการตรวจหาการติดเชื้อเพิ่มเติมและมาตรการรับมือ
  • เหตุการณ์แฮ็กครั้งนี้กำลังทำให้เกิดความตระหนักอย่างมากเกี่ยวกับ ความปลอดภัยของซัพพลายเชนแพ็กเกจ, การตรวจจับโค้ดที่ถูกทำให้อ่านยาก, และการปกป้องส่วนขยายเบราว์เซอร์ Web3

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

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

 
crawler 2025-09-09

> 8 กันยายน 2023

เป็นความสับสนจนใส่วันที่ผิดไป ไม่ใช่เรื่องของปี 2023 แต่เป็นเรื่องตอนนี้เอง
ดูเหมือนว่าจะมีข่าว npm ถูกแฮ็กค่อนข้างบ่อยพอสมควร ดูเป็นปัญหาที่น่ากังวล
 
GN⁺ 2025-09-09
ความคิดเห็นจาก Hacker News

  • ใช่ครับ ผมโดนแฮ็กจริง ๆ น่าอายมากและก็ขอโทษทุกคนจริง ๆ อยากให้ดูรายละเอียดเพิ่มเติมที่ นี่ และ นี่ ผมได้ลงรายชื่อแพ็กเกจที่ได้รับผลกระทบไว้แล้ว ดูเหมือนว่าการโจมตีครั้งนี้จะเป็นการโจมตีแบบเจาะจงเป้าหมาย ผมจะอัปเดตต่อเนื่องจนกว่าจะหมดเวลาที่แก้ไขคอมเมนต์ได้ ตอนนี้แพ็กเกจ Chalk กู้คืนได้แล้ว แต่ตัวอื่น ๆ ยังถูกยึดอยู่ (8 วันที่ 17:50 CEST) ฝั่ง NPM ยังไม่มีข่าวอะไรเลย บัญชี NPM ของผมยังเข้าไม่ได้ และฟังก์ชันกู้รหัสผ่านก็ไม่ทำงาน ตอนนี้สิ่งเดียวที่ผมทำได้คือรอ อีเมลจากทีมซัพพอร์ตมาจาก npmjs dot help และมันดูน่าเชื่อมาก นี่ไม่ใช่ข้อแก้ตัวนะ แต่ตอนนั้นเป็นเช้าที่เหนื่อยมาก และผมพยายามจะจัดการงานให้เสร็จสักอย่าง เลยเผลอกดลิงก์แทนที่จะเข้าเว็บทางการเองตามปกติ (น่าจะเพราะตอนนั้นใช้มือถือ) การโจมตีครั้งนี้กระทบแค่ NPM และผมจะอัปเดตต่อที่ /debug-js อีกครั้ง ขอโทษจริง ๆ

    • การรับมือได้เร็วและโปร่งใสขนาดนี้ในสถานการณ์ที่กดดันมากถือเป็นแบบอย่างได้เลย คิดว่าตัวเองคงไม่โดนฟิชชิงแล้ว แต่ขอเสริมทิปส์นิดหน่อย: 1) อย่าล็อกอินผ่านลิงก์ในอีเมลเด็ดขาด เพราะอีเมลฟิชชิงกับอีเมลจริงแยกยากมาก วิธีเดียวที่จะไม่โดนคือไม่พยายามเลย 2) ถ้าใช้กุญแจความปลอดภัย U2F/Webauthn เป็นการยืนยันตัวตนสองชั้น จะกันฟิชชิงได้แทบสมบูรณ์แบบ ส่วน TOTP ทำไม่ได้แบบนั้น สุดท้ายแล้วคนเราก็พลาดได้เสมอเวลาเหนื่อยหรือยุ่ง ครั้งนี้แค่บังเอิญเป็นคุณที่โดนเอง อีกครั้งหนึ่ง ขอบอกว่ารับมือได้ดีมาก

    • ตามคำแนะนำของ sindresorhus คุณสามารถตรวจว่าใน dependency tree ของตัวเองมีมัลแวร์หรือไม่ด้วยคำสั่งนี้: rg -u --max-columns=80 _0x112fa8 (ต้องมี ripgrep ติดตั้งก่อน ติดตั้งได้ด้วย brew install rg) และดู คอมเมนต์ต้นฉบับ ได้ด้วย

    • ตอนเรียนมหาวิทยาลัยผมเคยโดนฟิชชิงตอนเมาเหมือนกัน (นานมากแล้ว) ใครก็เป็นเหยื่อได้ทั้งนั้น แต่ก็น่าแปลกใจที่ NPM ตอบสนองช้ามาก แบบนี้ยิ่งเข้าทางผู้โจมตีมากขึ้นอีก

    • Socket ตรวจจับเหตุการณ์นี้ได้แทบจะทันที พูดถึงไว้ใน บล็อกที่เกี่ยวข้อง ด้วย เรื่องนี้น่าเศร้า แต่ก็น่ายกย่องที่ ecosystem โอเพนซอร์ซตอบสนองได้เร็วมาก เหตุการณ์แบบนี้ย้ำอีกครั้งว่าการสแกนแพ็กเกจสำคัญแค่ไหน

    • ขอบคุณที่เตือนเร็ว ผมส่งอีเมลไปขอให้ porkbun บล็อกโดเมนแล้ว

  • มีส่วนที่แนบเนียนมากในเพย์โหลดมัลแวร์นี้ซึ่งคนยังพูดถึงไม่พอ นั่นคือมันไม่ได้สุ่มแทนที่ที่อยู่กระเป๋าเงิน แต่จะคำนวณ Levenshtein distance ระหว่างที่อยู่จริงกับที่อยู่แต่ละอันในรายการของมัน แล้วเลือกกระเป๋าของผู้โจมตีที่คล้ายที่สุด ดังนั้นมันถูกออกแบบมาเพื่อเจาะพฤติกรรมความปลอดภัยที่คนส่วนใหญ่มักตรวจแค่ต้นกับท้ายของ address คร่าว ๆ มีบทความ สรุปรายละเอียดไว้ ซึ่งวิเคราะห์โดย deobfuscate เพย์โหลดทั้งหมดรวมถึงฟีเจอร์แปลกนี้ด้วย ขอให้ทุกคนปลอดภัย

    • มีส่วนหนึ่งในบทความที่ทำให้ผมงง เพราะผมเข้าใจว่า package-lock.json ใช้ตรึงเวอร์ชันแบบ "เป๊ะ" อยู่แล้ว ส่วน package.json สามารถกำหนดแบบ "ตั้งแต่เวอร์ชัน x ขึ้นไป" ได้ แต่ใน lockfile จะมีทั้งเวอร์ชันที่ระบุของแต่ละ dependency และ tarball URL ถูกฝังไว้ตรง ๆ ถ้ามี lockfile อยู่แล้ว ใน CI ก็ควรจะไม่เกิดการอัปเดตแพ็กเกจอัตโนมัติ ผมเลยสงสัยว่าตัวเองเข้าใจการทำงานของ npm/yarn/pnpm lockfile ผิดหรือเปล่า ลองดู คำอ้างอิงจากเอกสาร npm ด้วย

    • ผมคิดว่าถ้าแสดงค่าแฮชด้วยสีของแต่ละตัวอักษร (สีตัวอักษร/สีพื้นหลัง) โดยใช้ color scheme ที่กำหนดจากแฮชและอินเด็กซ์ มันจะช่วยให้แยกแฮชที่ถูกทำให้คล้ายกันทางสายตาได้ง่ายขึ้นมาก

    • มีข้อมูลไหมว่าเทคนิคนี้เกี่ยวข้องกับกลุ่มแฮ็กเฉพาะกลุ่มใดหรือเปล่า

    • โค้ดโจมตีนี้ฉลาดก็จริง แต่จริง ๆ แล้วบนเว็บเราสู้กับการโจมตีแบบ address คล้ายกันมาหลายสิบปีแล้ว นี่ก็แค่เวอร์ชันที่ dynamic ขึ้นเท่านั้น ผมไม่เห็นด้วยกับการยกย่องมันเกินจริง ตรง ๆ คือบทวิเคราะห์ทั้งชิ้นให้อารมณ์เหมือน AI เขียนมากกว่า และดูไม่ใช่การวิเคราะห์ที่รอบคอบนัก

  • เมื่อ 12 วันก่อนตอนฝั่ง Nx โดนแบบเดียวกัน ผมก็เขียน คอมเมนต์คล้ายกัน ไว้ นี่ไม่ใช่ความผิดพลาดของคนคนเดียว แต่เป็นความล้มเหลวของทั้งอุตสาหกรรม การโจมตีซัพพลายเชนมีผลกระทบมหาศาล และที่จริงผมคิดว่ามันเป็นปัญหาที่แก้ได้มานานแล้ว เราเป็นนักพัฒนาซอฟต์แวร์ ถ้านำมาตรการความปลอดภัยมาตรฐานมาใช้แบบครอบคลุมทั้งหมด เช่น code signing, artifact signing, การตรวจจับความผิดปกติของบัญชี, 2FA ฯลฯ ก็ป้องกันได้ ที่แพลตฟอร์มแพ็กเกจต่าง ๆ ยังไม่ทำ ไม่ใช่เพราะข้อจำกัดทางเทคนิค แต่เพราะไม่มีใครบังคับ และด้วยความก้าวหน้าของ AI กับความสำเร็จซ้ำ ๆ ของการโจมตีจริง สถานการณ์จะยิ่งแย่ลงจากนี้ ผมคิดว่าถึงเวลาต้อง "บังคับใช้" มาตรฐานความปลอดภัยที่เข้มงวดแล้ว

    • มาตรการความปลอดภัยพวกนี้มี trade-off อยู่ เช่น ถ้าใช้ระบบเชิงฮิวริสติกหรือกลไกแบบพิสูจน์ได้ ก็อาจกันระบบอัตโนมัติจำนวนมากหรือผู้ใช้ทั่วไปออกไปได้พอสมควร 2FA แบบ SMS ปลอดภัยน้อย และอีเมลก็เสี่ยงฟิชชิง TOTP จะมีความหมายก็ต่อเมื่อใช้เป็น open standard แต่ถึงอย่างนั้นก็ยังกันฟิชชิงไม่ได้ทั้งหมด การยืนยันตัวตนด้วยฮาร์ดแวร์เป็นวิธีเดียวที่ได้ผลจริง แต่ก็มีข้อจำกัดว่าทำจริงในแพลตฟอร์มขนาดใหญ่ได้ยาก

    • เรื่องนี้ไม่ได้ง่ายแค่ว่า "แค่ทำตามมาตรฐานความปลอดภัยก็กันได้หมด" ต่อให้ใช้มาตรการแน่นแค่ไหน ถ้ามนุษย์พลาด ระบบทั้งระบบก็เปราะบางอยู่ดี ไม่มีระบบที่ปลอดภัยสมบูรณ์แบบ ตอนนี้ AI ทำให้อีเมลฟิชชิงแยกจากของจริงแทบไม่ได้ แต่ในทางกลับกัน เราก็ใช้ AI ตรวจจับการโจมตีแบบนี้ได้ดีขึ้นเช่นกัน สุดท้ายก็คงต้องใช้ AI มาป้องกัน AI

    • เมื่อก่อนการแฮ็กมุ่งเป้าไปที่ Windows เยอะ แต่ตอนนี้จำนวนนักพัฒนา JavaScript และ Python มีมากกว่ามาก การโจมตีแบบนี้จะยิ่งหนักขึ้นเรื่อย ๆ

  • ผมคิดว่า NPM ก็ต้องรับผิดชอบส่วนหนึ่งด้วย ผู้ขายโซลูชันความปลอดภัยภายนอกและสตาร์ตอัปหลายรายตรวจพบกิจกรรมอันตรายพวกนี้ได้เร็ว แต่ NPM ซึ่งมองเห็นทุกแพ็กเกจและทุก security event แบบเรียลไทม์กลับไร้พลังซ้ำแล้วซ้ำอีกจนเข้าใจยาก แทบจะเหมือนจงใจไม่รับรู้อยู่แล้ว

    • ตอนนี้ NPM เป็นของ GitHub ซึ่งก็คือของ Microsoft ดูเหมือนพวกเขาจะยุ่งกับการยัด generative AI อย่าง Copilot เข้าไปในทุกแอปมากกว่า

    • สำหรับแพ็กเกจที่มีผู้ดูแลหลายคน อย่างน้อยก็ควรมีตัวเลือกให้ต้องมีผู้ดูแลคนอื่นอนุมัติก่อน publish ถึงจะปล่อยได้

    • ผู้โจมตีคนเดียวกันอัดเพย์โหลดที่ obfuscated (แถมดูน่าสงสัยมาก) เข้าไปในแพ็กเกจที่เงียบมานานกว่า 22 แพ็กเกจ แล้วปล่อยพร้อมกันในคราวเดียว ผมคิดว่าจะให้ NPM จับสิ่งนั้นได้แทบจะเป็นไปไม่ได้ ในฐานะคนที่เคยส่งแอป/ส่วนขยายขึ้นแพลตฟอร์มซอฟต์แวร์อื่น บางครั้งต้องรอเป็นวันหรือเป็นสัปดาห์เป็นเรื่องปกติ แต่ที่น่าตกใจคือ NPM แทบไม่แสดงร่องรอยว่าได้รับการลงทุนอย่างจริงจังกับบริการเลย ทั้งที่ MS และ GitHub ก็ขายโซลูชันความปลอดภัยสารพัด

    • ผมก็ไม่คิดว่า NPM มีเหตุผลอะไรที่ต้องเปลี่ยน เพราะตลอดกว่า 10 ปีมันเป็นแหล่งกระจายมัลแวร์อยู่แล้ว แต่ก็ไม่มีใครหยุดใช้ ดังนั้นธุรกิจก็ไม่เสียหายอะไร

    • สาเหตุหนึ่งคือการแพร่กระจายของ package manager มากเกินไป ผมไม่ชอบมาตั้งแต่แรกแล้วที่ต้องพึ่ง dependency แม้แต่เรื่องจิ๊บจ๊อย และก็เกลียดเวลามันดึงเวอร์ชันล่าสุดแบบสุ่มจน environment พัง ไม่ใช่แค่ npm ที่ไม่ชอบ แต่ package manager โดยทั่วไปก็น่าหงุดหงิดเหมือนกัน

  • ตอนนี้ถ้าใครยังกรอกรหัสผ่านลงเว็บที่โดเมนไม่ตรงกับโดเมนทางการเองโดยไม่มี password manager ผมคิดว่าไม่ควรทำเรื่องสำคัญบนอินเทอร์เน็ตแล้ว

    • password manager/ระบบกรอกอัตโนมัติของเบราว์เซอร์น่าจะเตือนโดเมนปลอมแบบนี้ได้ และก็น่าจะกันกรณีฟิชชิง NPM ครั้งนี้ที่ npmjs.help ไม่ตรงกับโดเมนทางการได้ด้วย

    • ก็จริง แต่ในโลกจริงผมก็เคยเจอหลายครั้งเหมือนกันที่แอปทางการกับเว็บไซต์ใช้คนละโดเมนกันแบบคนละเรื่องเลย กรณีแย่สุดคือแอปมือถือกับเว็บใช้โดเมนคนละอันไปเลย ไม่รู้ใครเป็นคนออกแบบแบบนั้น

  • ทุกครั้งที่เกิดเรื่องแบบนี้ ผมไม่เข้าใจว่าทำไม package registry ถึงไม่บังคับให้ทุกแพ็กเกจมีลายเซ็นดิจิทัล แน่นอนว่าใน CI/CD ถ้าเซ็นอัตโนมัติแล้วระบบนั้นถูกยึดด้วยก็ยังพังได้ แต่ปัญหาส่วนใหญ่จะป้องกันได้ แลกกับการที่นักพัฒนาต้องมีขั้นตอนเพิ่ม เช่น ดาวน์โหลด artifact เอง เซ็น แล้วอัปโหลด

    • ถ้าเป็น registry จริง ๆ ก็ควรทำแบบ Debian มานานแล้ว npm ดู amateur มากจนในองค์กรใหญ่หลายแห่งถึงกับห้ามใช้

    • วิธีที่ผมชอบคือการยืนยันภายหลัง คือให้ CI/CD อัปโหลดอัตโนมัติไปก่อน แต่ต้องมีคนเข้าเว็บไปกดอีกครั้งถึงจะปล่อยจริง แบบนี้ลดแรงเสียดทานของกระบวนการรีลีสได้ และยังมีขั้นตอนให้มนุษย์อนุมัติซ้ำอีกชั้น

    • แต่ก็ยังมีปัญหายากอยู่ดีว่า "ควรเชื่อถือ signing key อันไหน" เพราะใครก็ตามที่ยึด 2FA ได้ก็อัปโหลดคีย์ใหม่มาเซ็นได้เหมือนกัน ดังนั้นน่าจะต้องมีวิธีอย่างหน่วงเวลาการลงทะเบียน signing key ใหม่เมื่อพบกิจกรรมบัญชีที่น่าสงสัย

  • ผมสรุปแล้วว่าการหลีกเลี่ยง npm registry ให้ได้คุ้มค่ากว่าเยอะ ควรดึงแพ็กเกจจาก (git) repository โดยตรงแทน npm registry เป็นช่องทางหลักของการโจมตีซัพพลายเชนอยู่แล้ว และยังมีปัญหาที่ซอร์สกับโค้ดที่แจกจ่ายแยกขาดจากกันด้วย npm publish สามารถอัปโหลดโค้ดอะไรก็ได้จากเครื่อง local ทำให้ผู้ไม่หวังดีแทรกโค้ดอันตรายได้ง่าย

    • ตอน deploy ไป npm จาก GitHub builds มันมีฟีเจอร์ตรวจสอบความถูกต้องอยู่เหมือนกัน แต่ดูเหมือนว่าจะยัง publish จาก environment อื่นได้อยู่ เลยยังไม่ค่อยเข้าใจชัด

    • ในฐานะนักพัฒนา C ผมรู้สึกแปลกมากที่เมื่อก่อนการลด dependency, ใช้ไลบรารีแบบ single-header, หรือ vendoring ถูกมองว่าเป็นวิธีโบราณ แต่ตอนนี้ทุกคนกลับเริ่มตระหนักว่ามันเป็นสิ่งจำเป็นมาตลอด

    • ฟีเจอร์ provenance ใหม่ของ npm ช่วยแก้ปัญหานี้ได้ และตั้งค่าก็ค่อนข้างง่าย น่าจะช่วยป้องกันการโจมตีแบบนี้ได้ดี เห็นแพ็กเกจใหญ่ ๆ ทยอยใช้กันแล้วก็ดีใจ

    • อยากรู้ว่าใน CI ก็ใช้วิธีนี้เหมือนกันไหม ปกติคือเปลี่ยนจาก npm install บนเซิร์ฟเวอร์มาเป็น git clone แทนหรือเปล่า

    • แนวคิด "ดึงแพ็กเกจจาก git repository โดยตรง" ฟังดูดีในทางทฤษฎี แต่ในทางปฏิบัติ npm มีบั๊กเยอะมาก และมีปัญหาที่กระทบการติดตั้ง git dependency ด้วย อย่างที่ผมเขียนไว้ใน issue มันเคยใช้ไม่ได้จริงจนถึงปี 2020 เพราะปัญหา build step และตอน npm install แบบ global ก็ยังมีปัญหาอยู่ แม้แต่ prepack script ที่ระบุในเอกสาร npm ชัดเจน ในความเป็นจริงก็ไม่ทำงานกับ dependency ที่มาจาก git ทีม TypeScript compiler เองก็ต้องใช้วิธีแก้ขัดแปลก ๆ เพราะบั๊กนี้ และยังมีทั้ง โค้ดแก้ปัญหา กับ บั๊ก ให้ดู อีกปัญหาคือถึง prepack จะล้มเหลว มันก็ไม่ส่งต่อ exit code ทำให้ npm install จบแบบพัง ๆ ไปเฉย ๆ เรื่องแบบนี้ทำให้ผมคิดว่า npm ต้องการการกำกับดูแลการปฏิบัติการอย่างจริงจัง หรือไม่ก็ต้องถูกแทนที่ด้วย package manager ใหม่ไปเลย

  • สำหรับคนนอก ecosystem ของ npm อย่างผม มันน่าประหลาดใจมากว่าทำไมถึงดึงแพ็กเกจเยอะแยะขนาดนี้มาใช้กับเรื่องเล็กน้อยทุกอย่าง

    • เหตุผลคือ standard library มันอ่อนเกินไป และแม้แต่ฟังก์ชันพื้นฐานก็ยังต้องพึ่งแพ็กเกจภายนอก ถ้าจะทำเอง แม้แต่ของเล็กน้อยก็ต้องเขียนเยอะมาก

    • จากประสบการณ์พัฒนา 15 ปี ผมจะบอกว่า JavaScript developer ที่ทำงานประจำจำนวนมาก แทบจะเขียนโค้ดกันไม่ค่อยได้จริง ๆ ไม่ใช่เรื่องสติปัญญา แต่เป็นเรื่องการศึกษาและวัฒนธรรม พวกเขากลัวการเขียนโค้ดเองอย่างมาก สุดท้ายเลยพึ่ง dependency ภายนอกแม้แต่เรื่องเล็ก ๆ นักพัฒนาโปรเจกต์งานอดิเรกกลับไม่ค่อยเป็นแบบนั้น และโค้ดก็มักจะแข็งแรงกว่า ถ้าสนใจลองให้เพื่อนร่วมทีมที่บริษัทสร้างอะไรเองโดยไม่ใช้เฟรมเวิร์กใหญ่ ๆ ดู แล้วจะเห็นทันที

    • การดึงมาใช้เป็นโมดูลเล็ก ๆ แบบ trivial มีจุดประสงค์เพื่อไม่ให้รวมโค้ดที่ไม่จำเป็นไปกับฝั่ง client ไลบรารีแบบรวมชุดอาจให้ DX ที่สะอาดกว่า แต่ก็พาโค้ดที่ไม่ต้องการติดมาด้วย (แม้จะมี tree-shaking แต่ก็ไม่ใช่ยาวิเศษ)

    • หลังเหตุการณ์ leftpad การถกเถียงแบบนี้ก็มีมาตลอด อาจเป็นเพราะ standard library ของ JS เล็กเกินไปก็ได้

    • ในแง่การรีวิว PR การ import โมดูลหนึ่งบรรทัดที่ดู "trusted" มักทำให้ผู้รีวิวรู้สึกง่ายกว่าการดูโค้ดเปลี่ยนจำนวนมาก ทั้งที่จริงไม่ได้ปลอดภัยกว่า แต่ตอนเหนื่อย ๆ มันดูน่าเชื่อถือกว่าจริง

  • ตอนเหตุการณ์ nx ครั้งก่อนผมก็พูดแบบเดียวกันว่า package manager ควรมี "grace period" ที่ข้ามแพ็กเกจใหม่ไปช่วงหนึ่งเสมอ เช่น 24 ชั่วโมง เพราะการโจมตีแบบนี้ส่วนใหญ่จะถูกตรวจพบและบล็อกได้เร็วหลังปล่อย ถ้าผู้ใช้ไม่ติดตั้งเวอร์ชันล่าสุดอัตโนมัติในช่วงนั้น ก็จะลดความเสียหายจริงได้มาก

  • ผมนึกภาพความเจ็บปวดและความเครียดที่ผู้เขียนต้องเจอออกเลย การต้องคอยอธิบายเพราะความผิดพลาดเพียงครั้งเดียวคงหนักมาก นี่ก็เป็นตัวอย่างว่าระบบนิเวศโอเพนซอร์ซพึ่งพาแพ็กเกจที่คนคนเดียวถือครองมากแค่ไหน เราควรยอมรับว่าใคร ๆ ก็พลาดจนโดนแฮ็กได้ ในเชิงเทคนิค เมื่อ AI ถูกใช้อย่างแพร่หลายขนาดนี้ ก็น่าจะต้องมีการเปลี่ยนวัฒนธรรม เช่น ให้ deno/node/bun เตือนเมื่อเจอโค้ดน่าสงสัย ใช้การแจกจ่ายแบบ @verified ที่อิงการยืนยันตัวตนแนว Debian เพื่อเพิ่มความน่าเชื่อถือ และเลือกใช้เวอร์ชันที่ผ่านการตรวจสอบแล้วแทนการตามค่าล่าสุด ผู้เขียนก็เป็นมนุษย์คนหนึ่ง และพวกเราทุกคนควรปฏิบัติต่อเขาด้วยความเมตตา หลังสถานการณ์คลี่คลายแล้ว ผมก็อยากเห็นการวิเคราะห์เชิงเทคนิคหรือ postmortem ที่ละเอียดกว่านี้ด้วย