โทเคน stage-only ของ npm: หลักฐานที่ต้องบันทึกไว้เมื่อแยกการเผยแพร่อัตโนมัติออกจากการอนุมัติขั้นสุดท้าย
การแยกสิทธิ์ของ CI ในการสร้างแพ็กเกจออกจากสิทธิ์ในการเผยแพร่แพ็กเกจนั้นให้ผู้ใช้เห็น จะทำให้ความรับผิดชอบขั้นสุดท้ายของการเผยแพร่มีความชัดเจนยิ่งขึ้น อย่างไรก็ตาม การเพิ่มปุ่มอนุมัติเพียงปุ่มเดียวไม่ได้ทำให้ความเสี่ยงในซัพพลายเชนหมดไป คุณต้องเริ่มจากการกำหนดให้ชัดเจนก่อนว่าผู้อนุมัติต้องตรวจสอบอะไรบ้าง
GitHub ประกาศเมื่อวันที่ 18 กันยายนว่า สามารถเลือกสิทธิ์การเขียนแบบ stage-only ใน granular access token ของ npm ได้แล้ว โฟลว์การทำงานคือระบบอัตโนมัติจะส่งเวอร์ชันให้อยู่ในสถานะรอการตรวจสอบ จากนั้นผู้ดูแล (maintainer) จะอนุมัติการเผยแพร่ต่อสาธารณะผ่าน 2FA ต่อไปนี้คือคำอธิบายที่แยกความแตกต่างระหว่างการเปลี่ยนแปลงอย่างเป็นทางการและข้อเสนอแนะของกองบรรณาธิการเพื่อนำไปปรับใช้ในการปฏิบัติงานจริง
การบล็อกการเผยแพร่โดยตรงกับการลบสิทธิ์การเขียนนั้นต่างกัน
ตามคำแนะนำอย่างเป็นทางการ คุณสามารถใช้โทเคนดังกล่าวรันคำสั่ง npm stage publish ได้ แต่การเผยแพร่สู่สาธารณะโดยตรงผ่าน npm publish จะถูกปฏิเสธ ข้อจำกัดนี้จะมีผลบังคับใช้แม้ว่าจะมีการตั้งค่าบายพาส 2FA สำหรับระบบอัตโนมัติไว้ก็ตาม นี่ไม่ใช่ฟีเจอร์ที่จะเปลี่ยนพฤติกรรมของโทเคนเดิมโดยอัตโนมัติ แต่เป็นการเปิดรับนำมาปรับใช้ตามความสมัครใจ
ข้อควรระวังคือ สิทธิ์ในการเขียนแพ็กเกจอื่น ๆ เช่น การย้าย dist-tag และการ deprecate เวอร์ชันยังคงมีอยู่ ไม่ควรตีความชื่อ stage-only ว่าเป็นโทเคนแบบอ่านอย่างเดียวหรือไม่มีอันตราย คุณยังคงต้องจัดการขอบเขตแพ็กเกจที่อนุญาต ตำแหน่งจัดเก็บข้อมูลลับ (secrets) ผู้ใช้งาน และขั้นตอนการเพิกถอนสิทธิ์อยู่ดี
กำหนดชุดข้อมูลการเผยแพร่ที่ผู้อนุมัติจะใช้เปรียบเทียบ
เนื้อหาต่อไปนี้ไม่ใช่การตั้งค่าบังคับของ npm แต่เป็นข้อเสนอแนะในการปฏิบัติงานสำหรับทีมขนาดเล็ก ในคำขออนุมัติหนึ่งรายการ ควรระบุคอมมิตต้นทาง, แพ็กเกจและเวอร์ชันเป้าหมาย, ผลการทดสอบ, รายการไฟล์ที่จะรวมอยู่ในแพ็กเกจ และสรุปการเปลี่ยนแปลงไว้ด้วยกัน หากผู้อนุมัติต้องรวบรวมหลักฐานจากล็อก CI หลายจุด การตรวจสอบก็มักจะกลายเป็นการคลิกผ่าน ๆ ตามพิธีการได้ง่าย
โดยเฉพาะอย่างยิ่ง การตรวจสอบซอร์สโค้ดกับการตรวจสอบไฟล์สำหรับเผยแพร่นั้นเป็นคนละเรื่องกัน ไฟล์ที่ไม่มีอยู่ในคลังเก็บโค้ด (repository) อาจถูกรวมเข้ามาในกระบวนการบิลด์ หรือไฟล์ที่จำเป็นอาจตกหล่นไปได้ ทีมสามารถวางหลักการในการสร้างเอกสารการตรวจสอบโดยอิงจากผลลัพธ์ (artifacts) ที่ส่งไปจริง และหากมีการเปลี่ยนแปลงผลลัพธ์หลังการตรวจสอบ ก็ต้องถือว่าเป็นเป้าหมายการตรวจสอบชิ้นใหม่
ยังมีสถานะรอดำเนินการหลังจาก CI ผ่านเป็นสีเขียว
หากระบบอัตโนมัติเดิมรายงานว่าคำสั่งสำเร็จคือการเผยแพร่เสร็จสิ้น คุณควรเริ่มจากการเปลี่ยนวิธีแสดงสถานะก่อน โดยแบ่งออกเป็น ส่งข้อมูลสำเร็จ, รอการอนุมัติ, เผยแพร่สู่สาธารณะเสร็จสมบูรณ์ และบันทึกหลักฐานการยืนยันของแต่ละขั้นตอน ในการแจ้งเตือน การระบุขั้นตอนปัจจุบันและผู้รับผิดชอบจะมีประโยชน์ต่อผู้ปฏิบัติงานมากกว่าคำสั้น ๆ เพียงคำเดียวว่า "สำเร็จ"
ตัวอย่างสมมุติ เช่น หาก CI รอบดึกส่งเวอร์ชันใหม่เข้ามา แต่ผู้รับผิดชอบจะตรวจสอบในวันรุ่งขึ้น ก็ไม่ควรส่งประกาศการเปิดตัวให้ผู้ใช้ทราบในตอนที่ส่งเวอร์ชัน ควรเชื่อมโยงให้จัดทำเอกสารหรือประกาศหลังจากที่มีการยืนยันการเผยแพร่ตามเกณฑ์ที่ทีมกำหนดแล้ว นอกจากนี้ยังต้องตกลงกันล่วงหน้าว่าหากมีคิวสะสม ใครจะเป็นผู้ตรวจสอบ และจะเคลียร์สิ่งที่ส่งมาก่อนหน้านี้เมื่อใด
ตรวจสอบการย้ายระบบด้วยแพ็กเกจขนาดเล็กสักหนึ่งแพ็กเกจ
เงื่อนไขเริ่มต้นในคำแนะนำอย่างเป็นทางการปัจจุบันประกอบด้วย แพ็กเกจ npm ที่มีอยู่เดิม, สิทธิ์ในการเผยแพร่แพ็กเกจสู่สาธารณะ, 2FA ของบัญชี, npm CLI เวอร์ชัน 11.15.0 ขึ้นไป และ Node.js เวอร์ชัน 22.14.0 ขึ้นไป ก่อนการย้ายระบบจริง คุณควรตรวจสอบเอกสารล่าสุดอีกครั้งและตรวจเช็กเวอร์ชันของ runner ที่ใช้งาน
เราขอแนะนำให้เริ่มต้นด้วยการจำกัดขอบเขตโทเคนในแพ็กเกจที่มีผลกระทบน้อยสักหนึ่งแพ็กเกจ และฝึกปฏิบัติตั้งแต่การส่งไปยัง staging, การตรวจสอบโดยผู้ดูแล ไปจนถึงการยืนยันผลการเผยแพร่ หากเกิดข้อผิดพลาดแล้วกลับไปใช้โทเคนเดิมที่มีสิทธิ์กว้างกว่าทันที ขอบเขตที่แบ่งไว้ก็จะไร้ความหมาย คุณต้องสามารถจัดการกับความล่าช้าในการอนุมัติในฐานะสถานะปกติได้ด้วย
คำถามที่ต้องเปรียบเทียบกับ trusted publishing
npm ยังมี trusted publishing ที่ใช้ OIDC ด้วยเช่นกัน สิ่งสำคัญคือต้องพิจารณาก่อนว่าเหมาะสมกับสภาพแวดล้อม CI ที่รองรับและวิธีการอนุมัติของทีมหรือไม่ จึงไม่มีเหตุผลที่จะเหมารวมว่าโทเคน stage-only เป็นทางออกสุดท้ายสำหรับทุกทีม หากเป็นระบบอัตโนมัติที่จำเป็นต้องใช้โทเคนต่อไป นี่ก็นับเป็นทางเลือกใหม่สำหรับการค่อย ๆ ย้ายระบบทีละขั้นตอน
การประกาศอย่างเป็นทางการระบุเป้าหมายในเดือนมกราคม 2027 สำหรับการยกเลิกการเผยแพร่สู่สาธารณะโดยตรงด้วยโทเคนที่ bypass-2FA แทนที่จะคาดเดารายละเอียดการนำไปใช้ทั้งหมดที่ยังไม่แน่นอน การรวบรวมรายชื่อเวิร์กโฟลว์เป้าหมายและผู้รับผิดชอบการย้ายระบบตั้งแต่ตอนนี้จึงเป็นเรื่องที่ใช้งานได้จริงมากกว่า ส่วนการเปลี่ยนแปลงกำหนดการหรือไม่นั้น จำเป็นต้องตรวจสอบจากประกาศอย่างเป็นทางการในภายหลัง
เมื่อต้องตัดสินใจว่าจะนำมาใช้หรือไม่
บทความนี้ไม่ได้อ้างถึงฉันทามติในวงกว้างของชุมชนหรืออัตราการลดลงของอุบัติการณ์จริง แต่เป็นการเสนอแนะขั้นตอนการปฏิบัติงานที่สามารถนำไปตรวจสอบได้โดยอิงจากการทำงานอย่างเป็นทางการของฟีเจอร์ใหม่ การที่สามารถอธิบายได้ว่างานใดที่ระบบอัตโนมัติต้องรับผิดชอบ และงานใดที่มนุษย์ต้องตรวจสอบ คือจุดเริ่มต้นของการพิจารณาว่าจะนำมาใช้หรือไม่
สิ่งที่คุณสามารถทำได้ในวันนี้คือ การค้นหาจุดที่มีการใช้โทเคนเผยแพร่ในปัจจุบัน, ระบุเงื่อนไขในการตัดสินว่าการเผยแพร่สู่สาธารณะเสร็จสมบูรณ์, และกำหนดหลักฐานที่จำเป็นสำหรับการอนุมัติในแต่ละครั้ง การจำกัดสิทธิ์ควบคู่ไปกับคุณภาพของการตรวจสอบเท่านั้นที่จะทำให้ขั้นตอน staging เกิดประโยชน์อย่างแท้จริง