การโจมตีห่วงโซ่อุปทาน (Supply Chain Attack)

ซัพพลายเชนแอทแทค (Supply Chain Attack) คืออะไร

การพัฒนาซอฟต์แวร์ในปัจจุบันไม่ได้จบลงที่บริษัทเดียวอีกต่อไป ไม่ว่าจะเป็นไลบรารี OSS, CI/CD pipeline, แพ็กเกจรีจิสทรี (Package Registry) หรือใบรับรองการลงนามรหัส (Code Signing Certificate) เส้นทางทั้งหมดที่ผลิตภัณฑ์เดินทางไปถึงมือผู้ใช้นั้นคือ "ซัพพลายเชน" และผู้โจมตีจะมุ่งเป้าไปที่จุดที่ป้องกันอ่อนแอที่สุดในเส้นทางนั้น ความแตกต่างที่สำคัญจากการโจมตีแบบเดิมคือ องค์กรที่ตกเป็นเหยื่อไม่ได้ถูกโจมตีโดยตรง แต่ถูกใช้เป็นทางผ่านผ่านทางผู้ให้บริการต้นน้ำที่ได้รับความไว้วางใจ

ทำไมถึงเป็นเรื่องร้ายแรง

เนื่องจากการโจมตีผ่านช่องทางการจัดจำหน่ายที่เป็นทางการ ทำให้การตรวจจับทำได้ยากกว่าช่องโหว่ของเว็บแอปพลิเคชันทั่วไปที่ระบุโดย OWASP มาก แบ็กดอร์ที่แฝงมากับการอัปเดตที่มีลายเซ็นดิจิทัลสามารถหลบเลี่ยงการป้องกันที่ปลายทาง (Endpoint Protection) ได้ และไม่ใช่เรื่องแปลกที่จะต้องใช้เวลาหลายเดือนกว่าจะตรวจพบ ในรีจิสทรีสาธารณะอย่าง npm หรือ PyPI มีการรายงานเรื่อง Typosquatting (การเผยแพร่แพ็กเกจอันตรายโดยใช้ชื่อที่คล้ายกับแพ็กเกจจริง) อยู่บ่อยครั้ง ไลบรารีที่ปนเปื้อนเพียงหนึ่งเดียวสามารถส่งผลกระทบต่อโปรเจกต์นับพัน ซึ่งผลกระทบแบบทวีคูณนี้คือภัยคุกคามที่ใหญ่ที่สุดของซัพพลายเชนแอทแทค

แนวคิดในการป้องกัน

ในบริบทของ DevSecOps กลยุทธ์พื้นฐานคือการรวมการตรวจสอบความสัมพันธ์ (Dependency) เข้าไว้ตั้งแต่ช่วงเริ่มต้นของการพัฒนาตามหลักการ Shift Left โดยแนวทางที่เริ่มเป็นมาตรฐานในการปฏิบัติงานมีดังนี้:

• การสร้างและจัดการ SBOM (Software Bill of Materials): จัดทำรายการความสัมพันธ์ทั้งหมดที่รวมอยู่ในผลิตภัณฑ์ และตรวจสอบกับฐานข้อมูลช่องโหว่อย่างต่อเนื่อง
• การตรึงเวอร์ชัน (Pinning) และการตรวจสอบแฮชของความสัมพันธ์: กำหนดเวอร์ชันของความสัมพันธ์ด้วยไฟล์ล็อก (Lock file) และตรวจสอบ Checksum เมื่อมีการดึงข้อมูล
• การออกแบบ CI/CD ด้วยหลักสิทธิ์ขั้นต่ำ (Least Privilege): ไม่ให้สิทธิ์เกินความจำเป็นแก่บิลด์ไปป์ไลน์ แนวคิด Zero Trust Network Access ไม่ได้ใช้กับเครือข่ายเท่านั้น แต่ยังรวมถึงสภาพแวดล้อมในการบิลด์ด้วย
• การตรวจสอบลายเซ็นโดยอัตโนมัติ: ตรวจสอบลายเซ็นของคอมมิต (Commit) หรือผลลัพธ์ (Artifact) โดยอัตโนมัติใน CI เพื่อสกัดกั้นโค้ดที่ถูกแก้ไขก่อนที่จะถูกเมิร์จ (Merge)

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

ความเสี่ยงในการพัฒนา AI

ในระบบที่ใช้ LLM ไฟล์น้ำหนักของโมเดล (Model weights) และข้อมูลที่ใช้ฝึกสอน (Training data) ก็ถือเป็นส่วนหนึ่งของซัพพลายเชนเช่นกัน โมเดลที่ผ่านการ Fine-tuning ด้วยชุดข้อมูลที่ปนเปื้อนอาจสร้างผลลัพธ์ที่ไม่พึงประสงค์ผ่านช่องทางที่แตกต่างจาก Prompt Injection การตรวจสอบความน่าเชื่อถือของซัพพลายเชน AI นั้นยากกว่าซอฟต์แวร์แบบเดิม และเป็นขั้นตอนที่ทั้งอุตสาหกรรมกำลังอยู่ในระหว่างการหาแนวทางรับมือ