Zero‑day & ห่วงโซ่อุปทาน

01ช่องโหว่เป็นเรื่องของทุกคน The whole chain

ลองนึกถึงร้านข้าวมันไก่ที่เราชอบกิน เจ้าของร้านต้มข้าวเอง ทำน้ำจิ้มเอง แต่ข้าวสารซื้อจากโรงสี ไก่รับจากฟาร์ม ซีอิ๊วมาจากโรงงาน ถ้าวันหนึ่งซีอิ๊วเจ้าหนึ่งปนเปื้อน ทุกร้านที่ใช้ซีอิ๊วเจ้านั้นก็พลอยมีปัญหาไปด้วย ทั้งที่ร้านเองไม่ได้ทำอะไรผิดเลย

ซอฟต์แวร์ก็เป็นแบบเดียวกันเป๊ะ แอปหรือเว็บที่เราใช้ทุกวัน ผู้พัฒนาเขียนเองจริง ๆ แค่ส่วนบนสุด ที่เหลือประกอบจาก “ชิ้นส่วนสำเร็จรูป” ที่คนอื่นเขียนไว้แล้วนับร้อยนับพันชิ้น เราเรียกชิ้นส่วนเหล่านี้ว่า ไลบรารี (library) หรือ dependency การรวมผู้ผลิต ผู้ส่งต่อ และผู้ใช้ทั้งหมดนี้เรียกว่า ห่วงโซ่อุปทานซอฟต์แวร์ (software supply chain)

บทนี้เล่าถึงจุดอ่อนสองแบบที่เกิดในห่วงโซ่นี้ แบบแรกคือ ช่องโหว่ (vulnerability) จุดบกพร่องที่เผลอทำพลาดไว้ และแบบที่สองน่ากลัวกว่า คือเมื่อมีคน จงใจวางยา ลงในชิ้นส่วนที่ทุกคนไว้ใจ ทั้งสองแบบมีจุดร่วมเดียวกัน คือมันกระทบคนจำนวนมากพร้อมกัน เพราะทุกคนใช้ชิ้นส่วนเดียวกัน

ศัพท์น่ารู้: ช่องโหว่ (Vulnerability) vs ช่องโหว่ Zero-day

ช่องโหว่คือจุดบกพร่องในซอฟต์แวร์ที่อาจถูกใช้โจมตีได้ ส่วน Zero-day (ช่องโหว่วันศูนย์) คือช่องโหว่ที่ ผู้พัฒนายังไม่รู้ จึงยัง “มีเวลาศูนย์วัน” ในการแก้ และยังไม่มีแพตช์ให้ใคร มันจึงอันตรายเป็นพิเศษ เพราะไม่มีใครเตรียมป้องกันได้เลย

02วงจรชีวิตของช่องโหว่ The vulnerability lifecycle

ช่องโหว่ทุกตัวมี “ชีวิต” ของมัน ตั้งแต่เกิดในโค้ดเงียบ ๆ จนถึงวันที่ถูกปิดสนิท ระหว่างทางมีสองช่วงที่อันตรายเป็นพิเศษ และการเข้าใจสองช่วงนี้คือหัวใจของบททั้งบท

คนส่วนใหญ่กลัวช่วง Zero-day เพราะมันลึกลับและป้องกันไม่ได้ ซึ่งก็น่ากลัวจริง แต่ความจริงที่หลายคนไม่รู้คือ การโจมตีที่เกิดขึ้น จริง ๆ ส่วนใหญ่อาศัยช่องโหว่แบบ N-day ต่างหาก คือช่องที่แพตช์ออกมาแล้ว รายละเอียดเปิดเผยหมดแล้ว แต่เหยื่อยัง “ขี้เกียจอัปเดต” ผู้โจมตีแค่หยิบแพตช์มาดูว่าแก้อะไร ก็รู้ทันทีว่าช่องอยู่ตรงไหน แล้วไล่ยิงเครื่องที่ยังไม่อัปเดต

ศัพท์น่ารู้: N-day และแพตช์ (Patch)

N-day คือช่องโหว่ที่แพตช์ออกมาแล้ว “N วัน” แต่ยังมีคนไม่อัปเดต ส่วนแพตช์คือตัวแก้ไขที่ผู้พัฒนาปล่อยมาปิดช่องโหว่ บทเรียนสำคัญ: การออกแพตช์ไม่ได้แปลว่าปลอดภัยทันที มันปลอดภัยต่อเมื่อ “ติดตั้ง” แล้วเท่านั้น

03CVE & CVSS: ทะเบียนและคะแนน CVE & CVSS

พอมีช่องโหว่เกิดขึ้นทุกวันเป็นพัน ๆ ตัว โลกก็ต้องมีวิธีเรียกชื่อให้ตรงกัน ไม่งั้นคุยกันไม่รู้เรื่อง ระบบที่ใช้กันทั่วโลกคือ CVE ย่อมาจาก Common Vulnerabilities and Exposures เป็นเหมือน “เลขทะเบียนบ้าน” ของช่องโหว่แต่ละตัว เช่น CVE-2021-44228 แปลว่าช่องโหว่ที่ขึ้นทะเบียนในปี 2021 ลำดับที่ 44228 ทุกคนทั่วโลกอ้างถึงเลขเดียวกันนี้

ทะเบียน CVE ดูแลโดยองค์กรชื่อ MITRE ภายใต้การสนับสนุนของหน่วยงานรัฐบาลสหรัฐฯ ชื่อ CISA และมีหน่วยงานที่ได้รับมอบหมายให้ออกเลข CVE (เรียกว่า CNA) อยู่ทั่วโลกกว่า 400 แห่ง เช่น บริษัทซอฟต์แวร์ใหญ่ ๆ ที่ออกเลขให้ผลิตภัณฑ์ของตัวเองได้

แต่รู้แค่ชื่อยังไม่พอ เราต้องรู้ด้วยว่า “รุนแรงแค่ไหน” ตรงนี้ใช้คะแนนชื่อ CVSS (Common Vulnerability Scoring System) ให้คะแนนจาก 0 ถึง 10 ตามความง่ายในการโจมตีและความเสียหายที่เกิดได้ รุ่นที่ใช้กันปัจจุบันคือ CVSS v4.0

เกร็ดที่ควรรู้สำหรับคนที่จะทำงานสายนี้: ในช่วงที่ผ่านมามีการปรับวิธีทำงานของฐานข้อมูลช่องโหว่ โดยหน่วยงานกลางจะเน้นลงรายละเอียดเฉพาะช่องโหว่ที่กระทบวงกว้างหรือถูกใช้โจมตีจริงก่อน และหันไปใช้คะแนนที่ผู้ออกเลข CVE (CNA) ให้มาเป็นหลักมากขึ้น เพราะจำนวนช่องโหว่เพิ่มเร็วเกินกว่าจะให้คะแนนเองได้ทุกตัว บทเรียนคือ อย่าดูแค่ตัวเลข CVSS อย่างเดียว ต้องดูด้วยว่าช่องนั้น “ถูกใช้โจมตีจริงอยู่หรือยัง”

04แจ้งอย่างมีความรับผิดชอบ Coordinated disclosure

สมมติเราเป็นนักเรียนที่บังเอิญเจอช่องโหว่ในเว็บของบริษัทหนึ่ง เราควรทำอะไร ป่าวประกาศลงโซเชียลเลยไหม คำตอบคือ ไม่ เพราะถ้าเราประกาศก่อนที่บริษัทจะแก้ทัน คนร้ายทั้งโลกก็เห็นพร้อมกัน แล้วรีบเอาไปโจมตีก่อนมีแพตช์ เท่ากับเราเปิดช่วง Zero-day ให้คนร้ายเอง

วิธีที่ถูกต้องเรียกว่า การเปิดเผยอย่างมีการประสานงาน (coordinated disclosure) คือแจ้งผู้พัฒนาเป็นการส่วนตัวก่อน ให้เวลาเขาแก้ (ปกติ 90 วันเป็นมาตรฐานที่หลายคนใช้) แล้วค่อยเปิดเผยต่อสาธารณะพร้อมกับแพตช์ หลายบริษัทมีช่องทางรับแจ้งและโครงการให้รางวัล (bug bounty) สำหรับคนที่รายงานช่องโหว่อย่างถูกต้อง นี่คือเส้นทางของ “แฮกเกอร์หมวกขาว” ที่ถูกกฎหมายและได้รับการยกย่อง

และเมื่อแพตช์ออกมาแล้ว หน้าที่ก็ย้ายมาอยู่ที่ฝั่งผู้ใช้ คือต้อง จัดการแพตช์ (patch management) ให้เป็นระบบ รู้ว่าเครื่องไหนใช้อะไรบ้าง อัปเดตตัวสำคัญก่อน ทดสอบว่าไม่พัง แล้วทยอยปล่อย ยิ่งทำเร็ว ช่วง N-day ก็ยิ่งสั้น โอกาสโดนก็ยิ่งน้อย

05เมื่ออัปเดตกลายเป็นอาวุธ Poisoned updates

ตลอดบทที่ผ่านมา เราพร่ำบอกให้ “อัปเดตเสมอ” ซึ่งถูกต้อง แต่มีการโจมตีแบบหนึ่งที่พลิกคำแนะนำนี้กลับหัว คือเมื่อ ตัวอัปเดตเอง คือสิ่งที่มีพิษ ผู้โจมตีไม่ได้เจาะเครื่องเราโดยตรง แต่ไปเจาะที่ ผู้พัฒนาต้นทาง แล้วแอบฝังโค้ดร้ายลงในอัปเดตของจริง ก่อนที่มันจะถูกเซ็นรับรองและส่งถึงเรา

06Log4Shell: ช่องโหว่ในของที่ลืม Log4Shell

คราวนี้มาดูจุดอ่อนอีกแบบ ไม่ใช่การจงใจวางยา แต่เป็นช่องโหว่ธรรมดาในชิ้นส่วนเล็ก ๆ ที่บังเอิญถูกใช้กันทั้งโลก ชื่อของมันคือ Log4Shell และมันสอนบทเรียนสำคัญข้อหนึ่ง: เราป้องกันของที่เราไม่รู้ว่าเราใช้อยู่ไม่ได้

พระเอกของเรื่องคือไลบรารีชื่อ Log4j เป็นเครื่องมือเล็ก ๆ สำหรับ “จดบันทึก” (logging) ว่าโปรแกรมทำอะไรไปบ้าง ฟังดูไม่มีพิษภัย แต่มันถูกฝังอยู่ในแอป เซิร์ฟเวอร์ และบริการนับไม่ถ้วนทั่วโลก ปัญหาคือมันมักไม่ได้ถูกเรียกใช้ตรง ๆ แต่ “ติดมา” กับไลบรารีอื่นอีกที ฝังลึกหลายชั้นจนเจ้าของแอปเองไม่รู้ด้วยซ้ำว่ามีมันอยู่

07xz-utils: ประตูหลังที่เกือบสำเร็จ The xz backdoor

คดีสุดท้ายน่าขนลุกที่สุด เพราะมันรวมทั้งการวางยาและความเปราะบางของโลกโอเพนซอร์สไว้ด้วยกัน และมันเกือบสำเร็จแบบที่แทบไม่มีใครทันสังเกต

xz-utils เป็นเครื่องมือบีบอัดไฟล์เล็ก ๆ ที่ฝังอยู่ในระบบปฏิบัติการ Linux แทบทุกตัวบนโลก ดูแลโดยอาสาสมัครไม่กี่คน ในปี 2024 มีคนใช้ชื่อว่า “Jia Tan” ค่อย ๆ เข้ามาช่วยพัฒนาอย่างขยันขันแข็งเป็นเวลากว่าสองปี จนได้รับความไว้ใจให้เป็นผู้ดูแลร่วม ระหว่างนั้นยังมีบัญชีลึกลับหลายบัญชีคอยกดดันผู้ดูแลคนเดิมให้ปล่อยอำนาจ เมื่อได้สิทธิ์แล้ว เขาก็ค่อย ๆ แอบฝัง ประตูหลัง (backdoor) ลงในโค้ด อย่างแนบเนียนจนแทบมองไม่เห็น

คดี xz สอนเราว่า ในโลกโอเพนซอร์ส “ความไว้ใจ” เองก็เป็นช่องโหว่ได้ ผู้โจมตีที่อดทนพอจะใช้เวลาเป็นปี ๆ สะสมความน่าเชื่อถือ แล้วค่อยใช้มันในวินาทีสำคัญ

08ป้องกัน: SBOM & ลายเซ็น Defending the chain

เรื่องห่วงโซ่อุปทานฟังดูใหญ่โตเกินตัวสำหรับคนทั่วไป แต่หลักคิดในการป้องกันกลับตรงไปตรงมา และนักพัฒนารุ่นใหม่ควรรู้ไว้ตั้งแต่ต้น มันมีสี่ชั้น

ศัพท์น่ารู้: SBOM และ Code signing

SBOM (Software Bill of Materials) คือ “บัญชีรายการส่วนผสม” ของซอฟต์แวร์ บอกว่าข้างในประกอบด้วยไลบรารีอะไรบ้าง รุ่นไหน เหมือนฉลากโภชนาการบนห่ออาหาร ส่วน Code signing คือการที่ผู้พัฒนาเซ็นรับรองโค้ดด้วยลายเซ็นดิจิทัล เพื่อให้ผู้ใช้ตรวจได้ว่าของจริงและไม่ถูกแก้ไขระหว่างทาง

กฎระเบียบของโลกก็กำลังขยับไปทางนี้ เช่น กฎหมายความมั่นคงไซเบอร์ของสหภาพยุโรป (Cyber Resilience Act) ที่เริ่มมีผลบังคับหน้าที่รายงานช่องโหว่ในช่วงเดือนกันยายน 2026 ซึ่งผลักดันให้ผู้ผลิตต้องรับผิดชอบความปลอดภัยของซอฟต์แวร์ตลอดอายุการใช้งานมากขึ้น รวมถึงการจัดทำ SBOM

สำหรับนักเรียนหรือนักพัฒนามือใหม่ เริ่มง่าย ๆ ได้เลย: ใช้ไลบรารีจากแหล่งทางการ หมั่นอัปเดต dependency ให้เป็นรุ่นใหม่ และลองใช้เครื่องมือตรวจช่องโหว่ในโปรเจกต์ (dependency scanning) ที่หลายแพลตฟอร์มมีให้ฟรี แค่นี้ก็ปิดช่องส่วนใหญ่ได้แล้ว

09สรุปให้จำ Recap

ในโลกที่ซอฟต์แวร์ทุกชิ้นสร้างจากชิ้นส่วนของคนอื่น ความปลอดภัยของเราผูกกับความปลอดภัยของทั้งห่วงโซ่ ห้าข้อนี้คือแก่นของบท

• Zero-day คือช่องที่ยังไม่มีแพตช์ แต่การโจมตีจริงส่วนใหญ่อาศัยช่วง N-day ที่คนขี้เกียจอัปเดต
• CVE คือเลขทะเบียน CVSS คือคะแนนความรุนแรง 0–10 ระดับ Critical ต้องรีบที่สุด
• เจอช่องโหว่ให้แจ้งผู้พัฒนาก่อน อย่าป่าวประกาศก่อนมีแพตช์ (coordinated disclosure)
• อัปเดตเองก็ถูกวางยาได้ ถ้าต้นทางถูกเจาะ อย่างคดี SolarWinds ตรวจลายเซ็นช่วยได้
• รู้ว่ามีอะไรในระบบด้วย SBOM จะได้ตอบได้ทันทีว่าช่องโหว่ใหม่กระทบเราไหม

ลองทบทวนดู