ทำไมทุกคนควรใช้ dependency cooldown

• dependency cooldown คือ เทคนิคความปลอดภัยที่เรียบง่ายและได้ผล ซึ่งสามารถบรรเทาการโจมตีซัพพลายเชนของโอเพนซอร์สได้เป็นส่วนใหญ่
• โดยทั่วไปผู้โจมตีจะยึดโครงการโอเพนซอร์สยอดนิยมเพื่อกระจายโค้ดอันตราย แต่ช่วงเวลาที่การโจมตี เปิดเผยอยู่มักสั้นกว่า 1 สัปดาห์
• หากตั้งค่า cooldown ให้รอช่วงเวลาหนึ่งหลังปล่อยเวอร์ชันใหม่ (เช่น 7 วัน) จะช่วย ลดความเสี่ยงการติดเชื้อจากการอัปเดตอัตโนมัติได้มาก
• Dependabot, Renovate, pnpm ฯลฯ รองรับ ฟีเจอร์ cooldown เป็นมาตรฐานอยู่แล้ว ตั้งค่าได้ง่ายและไม่มีค่าใช้จ่ายเพิ่ม
• หากมี cooldown เป็นค่าพื้นฐานในระดับ package manager ก็จะช่วย เสริมความปลอดภัยของซัพพลายเชนและลดการแจ้งเตือนที่ไม่จำเป็น ได้

---

โครงสร้างและปัญหาของการโจมตีซัพพลายเชน

• การโจมตีซัพพลายเชน (supply chain attack) ส่วนใหญ่มีรูปแบบเดียวกัน
  • ผู้โจมตีใช้ การขโมยข้อมูลรับรอง หรือ ช่องโหว่ CI/CD เพื่อเข้าถึงโครงการโอเพนซอร์สยอดนิยม
  • อัปโหลดการเปลี่ยนแปลงอันตรายไปยังช่องทางเผยแพร่ เช่น PyPI, npm
  • ผู้ใช้ติดตั้งเวอร์ชันที่ปนเปื้อนจากการอัปเดตอัตโนมัติหรือการไม่ตรึงเวอร์ชันไว้
  • ผู้ให้บริการด้านความปลอดภัยตรวจพบและแจ้งเตือน จากนั้นคลังแพ็กเกจจึงลบเวอร์ชันดังกล่าวออก
• ช่วงระหว่างขั้นตอน (1)~(2) มักยาว แต่ช่วง (2)~(5) จะเกิดขึ้นภายใน ไม่กี่ชั่วโมงถึงไม่กี่วัน ทำให้ช่วงเวลาที่ผู้โจมตีดำเนินการได้ค่อนข้างสั้น
• ช่วงเวลาเปิดโอกาสในการโจมตี (window of opportunity) ของกรณีสำคัญในช่วง 18 เดือนล่าสุด
  • xz-utils: ประมาณ 5 สัปดาห์
  • Ultralytics: 12 ชั่วโมง (ขั้นที่ 1), 1 ชั่วโมง (ขั้นที่ 2)
  • tj-actions: 3 วัน
  • chalk: น้อยกว่า 12 ชั่วโมง
  • Nx: 4 ชั่วโมง
  • rspack: 1 ชั่วโมง
  • num2words: น้อยกว่า 12 ชั่วโมง
  • Kong Ingress Controller: ประมาณ 10 วัน
  • web3.js: 5 ชั่วโมง
• ในกรณีเหล่านี้ 8 เหตุการณ์มี ช่วงเวลาการโจมตีน้อยกว่า 1 สัปดาห์ และส่วนใหญ่สามารถป้องกันได้ด้วย cooldown

แนวคิดและประสิทธิภาพของ cooldown

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

    version: 2
    - package-ecosystem: github-actions
      directory: /
      schedule:
        interval: weekly
      cooldown:
        default-days: 7
    

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

บทสรุปและข้อเสนอแนะ

• การโจมตี 8 จาก 10 กรณีมี ระยะเวลาไม่เกิน 1 สัปดาห์ และสามารถป้องกันได้เป็นส่วนใหญ่ด้วย cooldown 7 วัน
• หากใช้ cooldown 14 วัน จะป้องกันได้ทุกกรณียกเว้น xz-utils
• cooldown ไม่ใช่คำตอบที่สมบูรณ์แบบ แต่เป็น วิธีง่าย ๆ ที่ลดความเสี่ยงจากการเปิดรับได้ 80~90%
• นอกจาก Dependabot และ Renovate แล้ว ยังควรปรับปรุงให้ package manager เองรองรับ cooldown เป็นค่าพื้นฐาน ด้วย
• ความปลอดภัยของซัพพลายเชนไม่ใช่แค่ปัญหาทางเทคนิค แต่ยังเป็นเรื่องของ โครงสร้างความไว้วางใจทางสังคม และ cooldown ก็เป็นมาตรการบรรเทาที่ใช้งานได้จริง