Bun Lockfiles และความปลอดภัยของ Supply Chain ของคุณ
Binary lockfiles เปรียบเสมือนภาษีด้านความปลอดภัย—ที่คุณต้องจ่ายคืนในภายหลังพร้อมดอกเบี้ย
แต่ก่อน Bun จะเก็บ dependencies ไว้ในไฟล์ไบนารีที่ชื่อว่า bun.lockb ซึ่งแม้จะรวดเร็วและมีขนาดเล็ก แต่คุณก็ไม่สามารถอ่านมันได้ คุณไม่สามารถทำ diff ใน pull request และไม่สามารถมองเห็นได้ว่ามีอะไรเปลี่ยนแปลงไปบ้าง
เมื่อคุณไม่สามารถตรวจสอบการเปลี่ยนแปลงของ dependency ได้ คุณก็ไม่มีนโยบายที่ชัดเจน—มีเพียงแค่ความรู้สึกเท่านั้น
Bun v1.2 ได้เปลี่ยนค่าเริ่มต้นมาเป็น bun.lock แบบข้อความ (text-based) ซึ่งเพียงแค่นี้ก็ถือเป็นชัยชนะครั้งใหญ่ในด้านความปลอดภัยแล้ว
ทำไม lockfile แบบข้อความถึงมีความสำคัญ
- Meaningful diffs – ผู้ตรวจสอบ (reviewers) จะเห็นได้อย่างชัดเจนว่าแพ็กเกจไหนมีการเคลื่อนย้ายหรือเปลี่ยนแปลง
- Easy policy checks – CI สามารถสแกนหาแพทเทิร์นที่ถูกสั่งห้ามหรือ registry ที่ไม่น่าเชื่อถือได้
- Faster forensics –
git logจะแสดง commit ที่นำแพ็กเกจอันตรายเข้ามาได้อย่างแม่นยำ
Lockfile ช่วยรับประกันความถูกต้อง (integrity) และความสามารถในการทำซ้ำ (reproducibility) แต่ไม่ใช่ยาสารพัดนึก มันไม่สามารถหยุดยั้งเวอร์ชันอันตรายที่ถูกเผยแพร่อย่างถูกต้องตามกฎ หรือผู้ดูแล (maintainer) ที่ถูกแฮ็กได้
สิ่งที่ text lockfile เพิ่มเข้ามาคือความสามารถในการมองเห็น (visibility) และความสามารถในการมองเห็นนี่เองคือด่านป้องกันแรกของคุณ
วิธีรักษาความปลอดภัยให้กับ Bun workflow ของคุณ
- รัน
bun install --frozen-lockfileใน CI โดยการ build จะล้มเหลวหาก lockfile จำเป็นต้องได้รับการอัปเดต - รัน
bun install --lockfile-onlyใน CI เพื่อตรวจสอบการหาความสัมพันธ์ (resolution) โดยไม่ต้องรันสคริปต์การติดตั้งที่หนักเครื่อง - เปลี่ยนไฟล์ bun.lockb ทั้งหมดให้เป็น bun.lock ทันที
- กำหนดให้ต้องมีการตรวจสอบโดยมนุษย์สำหรับการเปลี่ยนแปลง lockfile โดยเพิ่มเจ้าของที่เหมาะสมลงใน
CODEOWNERSเพื่อให้ผู้ที่เกี่ยวข้องได้เห็นทุกการอัปเดตของ dependency
เลิกเชื่อใจเครื่องมืออย่างหลับหูหลับตา แต่จงตรวจสอบทุกการเปลี่ยนแปลงแทน