ชุมชน JavaScript กำลังเผชิญกับจุดเปลี่ยนสำคัญหลังจากสิ่งที่เรียกว่าการโจมตี supply-chain ที่ใหญ่ที่สุดในประวัติศาสตร์ ในขณะที่ความตื่นตระหนกในทันทีเริ่มคลี่คลายและนักพัฒนาเสร็จสิ้นการรักษาความปลอดภัยระบบของตน การถกเถียงอย่างเข้มข้นก็เกิดขึ้นเกี่ยวกับว่าระบบนิเวศจะแก้ไขข้อบกพร่องด้านความปลอดภัยพื้นฐานในที่สุดหรือจะดำเนินต่อไปตามปกติ
การโจมตีครั้งนี้ได้จุดประกายการวิพากษ์วิจารณ์ที่มีมายาวนานเกี่ยวกับแนวทางการจัดการ dependency ของ JavaScript โดยหลายคนชี้ไปที่ต้นไม้แผ่กิ่งก้านสาขาของ micro-libraries ที่กลายเป็นเอกลักษณ์ของระบบนิเวศ npm อย่างไรก็ตาม การตอบสนองของชุมชนเผยให้เห็นความแตกแยกอย่างลึกซึ้งเกี่ยวกับทั้งลักษณะของปัญหาและแนวทางแก้ไขที่เป็นไปได้
การถกเถียงเรื่อง Micro-Dependency แสดงความก้าวหน้าและความคงอยู่
หนึ่งในประเด็นที่ถูกพูดถึงมากที่สุดคือ micro-dependencies เช่น package left-pad ที่มีชื่อเสียงฉาวโฉ่ นักวิจารณ์โต้แย้งว่าการพึ่งพา JavaScript ต่อ libraries ขนาดเล็กที่มีจุดประสงค์เดียวสร้างพื้นผิวการโจมตีที่ไม่จำเป็น อย่างไรก็ตาม นักพัฒนาหลายคนชี้ให้เห็นว่าการวิพากษ์วิจารณ์นี้ล้าสมัยมากขึ้นเรื่อยๆ ฟังก์ชันการทำงานที่ left-pad ให้บริการได้เป็นส่วนหนึ่งของ standard library ของ JavaScript มาเกือบทศวรรษแล้วผ่าน String.padStart() และแนวโน้มปัจจุบันสนับสนุน zero dependencies อย่างแรงกล้าเป็นจุดขายในการพัฒนา frontend
แม้จะมีความก้าวหน้านี้ การเปลี่ยนผ่านจาก micro-packages ยังไม่สมบูรณ์ นักพัฒนาบางคนรายงานว่าพบผู้ร้ายที่จงใจแทรก libraries ของตนเองเป็น dependencies เพื่อเพิ่มจำนวนการดาวน์โหลดเพื่อผลประโยชน์ทางการเงิน สิ่งนี้บ่งบอกว่าแม้ชุมชนจะตระหนักถึงปัญหา แต่ปัญหาเชิงระบบยังคงมีอยู่ในวิธีการบำรุงรักษาและแจกจ่าย packages
ขนาดทำให้แนวทางแก้ไขแบบดั้งเดิมไม่สามารถใช้ได้จริง
เมื่อพูดถึงการแก้ไขที่เป็นไปได้ หลายคนชี้ไปที่ Linux distributions เป็นแบบอย่างสำหรับการจัดการ package ที่ปลอดภัย ระบบเหล่านี้ใช้คอลเลกชันที่คัดสรร ผู้ดูแล package และกระบวนการตรวจสอบที่เข้มงวด อย่างไรก็ตาม ความแตกต่างของขนาดสร้างความท้าทายอย่างมหาศาล Debian ซึ่งเป็นหนึ่งในตัวอย่างที่ประสบความสำเร็จมากที่สุด จัดการ packages ประมาณ 20,000 ตัวด้วยอาสาสมัครประมาณ 1,000 คน - อัตราส่วน 20:1
การนำแบบจำลองนี้มาใช้กับ packages 3 ล้านตัวของ npm จะต้องการอาสาสมัคร 150,000 คน แม้ว่าจะมีเพียง 100,000 packages ที่ถือว่าคุ้มค่าในการบำรุงรักษา ความพยายามนี้ก็ยังต้องการอาสาสมัครที่ทุ่มเทอีก 5,000 คน การหาคนที่มีคุณสมบัติเหมาะสมจำนวนมากที่เต็มใจทำงานฟรีดูเหมือนจะไม่สมจริง โดยเฉพาะเมื่อ Debian เองก็มีผู้สนับสนุนสูงสุดเพียงประมาณ 1,000 คน แม้จะเป็นรากฐานสำหรับซอฟต์แวร์ที่ใช้กันมากที่สุดในโลก
การเปรียบเทียบขนาด: Linux Distributions เทียบกับ npm
- Debian: จัดการแพ็กเกจประมาณ 20,000 แพ็กเกจโดยอาสาสมัครประมาณ 1,000 คน (อัตราส่วน 20:1)
- npm: แพ็กเกจ 3 ล้านแพ็กเกจจะต้องใช้อาสาสมัคร 150,000 คนหากใช้อัตราส่วนเดียวกัน
- ชุดย่อยที่เป็นจริง: แม้แต่แพ็กเกจ "ที่มีคุณค่า" 100,000 แพ็กเกจก็ยังต้องการอาสาสมัคร 5,000 คน
- ความสามารถปัจจุบันของ Debian: เต็มขีดความสามารถที่ผู้ร่วมพัฒนาประมาณ 1,000 คน แม้จะมีการใช้งานทั่วโลก
การแก้ไขทางเทคนิคปรากฏขึ้นแต่พลาดปัญหาราก
ชุมชนได้เริ่มนำแนวทางแก้ไขทางเทคนิคมาใช้เพื่อชะลอการโจมตี Package managers เช่น pnpm และ Yarn กำลังแนะนำข้อกำหนดอายุการเผยแพร่ขั้นต่ำ บังคับให้มีการหน่วงเวลาก่อนที่ package versions ใหม่จะสามารถติดตั้งได้ แม้ว่าสิ่งนี้อาจจับการอัปเดตที่เป็นอันตรายบางส่วนได้ แต่ก็สร้างปัญหาใหม่เมื่อ security patches เร่งด่วนต้องการการติดตั้งทันที
นักพัฒนาบางคนแนะนำให้ใช้ระบบ AI เพื่อสแกน packages หาโค้ดที่เป็นอันตรายโดยอัตโนมัติ อย่างไรก็ตาม แนวทางนี้เผชิญกับความสงสัยจากนักพัฒนาที่ใส่ใจความปลอดภัยที่กังวลว่าการสแกนอัตโนมัติอาจสร้างความมั่นใจที่ผิดๆ ในขณะที่ผู้โจมตีที่ซับซ้อนพัฒนาเทคนิคการปิดบังที่ออกแบบมาเป็นพิเศษเพื่อหลอก AI systems
โดยพื้นฐานแล้ว การแก้ไขไม่ใช่เรื่องเทคนิค แต่เป็นเรื่องสังคม / โครงสร้าง บริษัทต่างๆ ต้องรับผิดชอบต่อการอนุมัติ dependencies ที่ใช้ รับผิดชอบต่อ repos ในการอนุมัติ dependencies หรือทำต่อไปในสิ่งที่เราทำมา
โซลูชันทางเทคนิคที่กำลังดำเนินการในปัจจุบัน
- pnpm: การตั้งค่าใหม่สำหรับอายุขั้นต่ำของการเผยแพร่แพ็กเกจ
- Yarn: ตัวเลือกการกำหนดค่า npmMinimumReleaseAge และ npmMinimumReleaseAgeExclude
- ข้อจำกัด: การแพตช์ความปลอดภัยเร่งด่วนต้องการการยกเว้นอย่างสมบูรณ์จากข้อกำหนดเรื่องอายุ
- แพลตฟอร์มทางเลือก: JSR.io ที่มีโมเดลความน่าเชื่อถือที่แตกต่างกัน, Deno Standard Library
ระบบนิเวศทางเลือกให้ทางหนีที่จำกัด
นักพัฒนาบางคนกำลังสำรวจทางเลือกอื่นเช่น JavaScript runtime ของ Deno และ JSR package registry ซึ่งเน้นแนวทางที่แตกต่างในการจัดการ dependency และความปลอดภัย อย่างไรก็ตาม แม้แต่ทางเลือกเหล่านี้ก็เผชิญกับความท้าทายเมื่อพวกเขาสนับสนุน npm packages มากขึ้นเพื่อรักษาความเข้ากันได้ ซึ่งอาจนำช่องโหว่เดียวกันที่พวกเขาตั้งใจจะหลีกเลี่ยงกลับมาอีกครั้ง
การอภิปรายเผยให้เห็นความตึงเครียดพื้นฐานในการพัฒนาซอฟต์แวร์สมัยใหม่ ความสะดวกและความเร็วของระบบการจัดการ dependency ปัจจุบันได้เปิดใช้งานนวัตกรรมและการพัฒนาอย่างรวดเร็ว แต่ต้องแลกด้วยความปลอดภัยและเสถียรภาพ ผู้เข้าร่วมส่วนใหญ่ดูเหมือนจะยอมรับการปรับปรุงแบบค่อยเป็นค่อยไปมากกว่าการเปลี่ยนแปลงแบบปฏิวัติ
การถกเถียงในที่สุดสะท้อนคำถามที่กว้างขึ้นเกี่ยวกับวิธีที่อุตสาหกรรมซอฟต์แวร์สร้างสมดุลระหว่างความเร็วในการสร้างนวัตกรรมกับความรับผิดชอบด้านความปลอดภัย ในขณะที่แนวทางแก้ไขทางเทคนิคยังคงปรากฏขึ้น แรงจูงใจทางสังคมและเศรษฐกิจที่สร้างปัญหาเหล่านี้ยังคงไม่เปลี่ยนแปลงเป็นส่วนใหญ่ ดังที่ผู้สังเกตการณ์คนหนึ่งกล่าวไว้ รูปแบบของวิกฤตและการตอบสนองที่น้อยนิดนี้ได้เกิดขึ้นซ้ำมาหลายทศวรรษในระบบนิเวศการเขียนโปรแกรมหลายแห่ง ซึ่งบ่งบอกว่าการปฏิรูปที่มีความหมายอาจต้องการมากกว่าแค่นวัตกรรมทางเทคนิค