สรุปสั้น

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

Echo วิเคราะห์วงจรชีวิตของ CVE เกือบ 40,000 รายการใน 250 โครงการคอนเทนเนอร์โอเพนซอร์ส ร่วมกับข้อมูลจากแพลตฟอร์มของตัวเองตลอดหนึ่งปี แบบสอบถามผู้บริหารด้านความปลอดภัยกว่า 80 คน และการวิเคราะห์อิสระเกี่ยวกับโมเดล Claude Mythos ของบริษัท Anthropic แล้วสรุปออกมาเป็นรายงานชื่อ “Mythos Readiness Report” ตัวเลขสำคัญที่สุดคือจากช่องโหว่ที่ Mythos ค้นพบราว 23,019 รายการ มีไม่ถึง 10% ที่ผ่านการตรวจสอบยืนยันจากภายนอก และในจำนวนช่องโหว่ 27 รายการที่ Anthropic เปิดเผยต่อสาธารณะ Mythos จัดให้ 8 รายการเป็นระดับวิกฤต แต่หลังนักวิจัยตรวจสอบซ้ำอย่างเป็นอิสระ เหลือเพียงรายการเดียวที่ยังคงระดับวิกฤตไว้ได้

อีกด้านหนึ่ง รายงานชี้ว่าปัญหาที่แท้จริงขององค์กรไม่ใช่การไม่มีแพตช์ เพราะ 89% ของช่องโหว่ที่ตรวจสอบมีแพตช์ออกมาแล้ว แต่เกือบ 40% ของช่องโหว่ที่แก้ได้กลับค้างอยู่ในระบบเกินหกเดือน และ 56% ของช่องโหว่ในคอนเทนเนอร์มาจากแพ็กเกจ ยูทิลิตี และเครื่องมือพัฒนาที่ไม่จำเป็นต้องมีอยู่ในระบบโปรดักชันตั้งแต่แรก

รายละเอียดข่าว

เว็บไซต์ Dark Reading รายงานเมื่อวันที่ 2 กันยายน 2569 ว่า Echo เผยแพร่รายงานที่ประเมินความพร้อมขององค์กรต่อคลื่นช่องโหว่ที่ AI ค้นพบ โดยตั้งข้อสังเกตว่าสิ่งที่วงการเรียกกันว่า “Vulnpocalypse” อาจไม่ท่วมท้นทีมความปลอดภัยขององค์กรอย่างที่กลัวกัน หากมีกลยุทธ์ที่ถูกต้อง

รายงานยืนยันภาพที่ทีมความปลอดภัยเจอกับตัวมาตลอดปีที่ผ่านมา นั่นคือจำนวน CVE ที่ถูกเปิดเผยต่อเดือนเพิ่มขึ้น 145% ในช่วงสองปี จาก 3,173 รายการในเดือนมิถุนายน 2567 เป็น 7,765 รายการในเดือนมิถุนายน 2569 ส่วนหนึ่งมาจากการขยายตัวของโครงการ CVE เอง และอีกส่วนที่เพิ่มขึ้นเรื่อย ๆ มาจากการค้นหาช่องโหว่โดยมี AI ช่วย เมื่อดูเป็นรายปี ตัวเลขขยับจาก 30,949 รายการในปี 2566 เป็น 49,979 รายการในปี 2568 และจากตัวเลขที่ผ่านมาของปี 2569 มีแนวโน้มจะแซงหน้าปีก่อนอีก

รูปแบบเดียวกันปรากฏใน base image ของคอนเทนเนอร์ ซึ่ง Node และ Python เป็นสองตัวที่ถูกใช้บ่อยที่สุด โดยระหว่างเดือนมกราคมถึงมิถุนายน 2569 จำนวน CVE ที่รู้จักใน base image ของ Node พุ่งขึ้น 338% จากราว 16,000 เป็น 70,000 รายการ ส่วนฝั่ง Python ขยับจาก 17,500 เป็น 45,000 รายการในช่วงเวลาเดียวกัน Echo สรุปไว้ในรายงานว่า “ช่องโหว่ถูกค้นพบด้วยความเร็วระดับเครื่องจักร ขณะที่การแก้ไขยังเป็นงานมือเป็นหลัก” เท่ากับ AI เร่งสมการได้เพียงข้างเดียว ส่วนอีกข้างยังตามไม่ทัน

Echo ยังพบว่า Claude Mythos เปลี่ยนต้นทุนทางเศรษฐศาสตร์ของการพัฒนาโค้ดโจมตีไปอย่างสิ้นเชิง โดยทำให้ทั้งนักวิจัยและผู้ไม่หวังดีสามารถพัฒนาโค้ดโจมตีที่ใช้งานได้จริงสำหรับช่องโหว่ที่รู้จักแล้วภายในเวลาไม่ถึงหนึ่งวันและด้วยงบไม่ถึง 2,000 ดอลลาร์สหรัฐ ซึ่งเป็นตัวเลขที่เปลี่ยนสมมติฐานเรื่องระยะเวลาปลอดภัยหลังการเปิดเผยช่องโหว่ไปทั้งหมด

อย่างไรก็ตาม นาย Eylam Milner ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีและผู้ร่วมก่อตั้ง Echo บอกกับ Dark Reading ว่าเรื่องที่ทำให้ทีมวิจัยประหลาดใจที่สุดคือการเตรียมพร้อมรับมือ Mythos ทำได้ง่ายกว่าที่คาดไว้มาก เพราะแม้โมเดลจะเก่งเรื่องการหาช่องโหว่จริง แต่เชื่อถือได้น้อยกว่ามากในการตัดสินว่าช่องโหว่นั้นร้ายแรงเพียงใด ซึ่งเป็นความแตกต่างที่สำคัญมากสำหรับทีมความปลอดภัยที่ต้องตัดสินใจว่าจะทุ่มเวลาไปกับเรื่องไหน

ตัวเลขสำคัญจากรายงาน

ประเด็นที่รายงานเน้นมากที่สุดคือช่องว่างระหว่าง “ค้นพบ” กับ “ยืนยันแล้ว” โดยในช่วงที่ Echo ศึกษา Mythos ค้นพบช่องโหว่ที่อาจเป็นไปได้ราว 23,019 รายการ แต่มีไม่ถึง 10% ที่ผ่านการตรวจสอบจากภายนอกหรือถูกตรวจสอบอย่างเป็นอิสระ และในกลุ่มช่องโหว่ 27 รายการที่ Anthropic เปิดเผยต่อสาธารณะ Mythos จัดให้ 8 รายการเป็นระดับวิกฤตตั้งแต่ต้น ทว่าเมื่อนักวิจัยเข้าไปตรวจสอบซ้ำ กลับเหลือเพียงรายการเดียวที่ยังคงระดับวิกฤตเอาไว้ได้ นั่นหมายความว่าปริมาณงานที่ไหลเข้าทีมความปลอดภัยจริง ๆ น้อยกว่าตัวเลขดิบมาก หากมีกระบวนการคัดกรองที่ดีพอ

อีกชุดตัวเลขที่ชี้ปัญหาเชิงกระบวนการคือ 89% ของช่องโหว่ที่ Echo ตรวจสอบมีแพตช์ออกมาแล้ว และสัดส่วนนี้ยิ่งสูงขึ้นในช่องโหว่ระดับวิกฤตและระดับสูง แต่กลับพบว่าเกือบ 40% ของช่องโหว่ที่แก้ไขได้ยังค้างไม่ได้รับการแก้เกินหกเดือน Milner อธิบายว่าการมีแพตช์ไม่ได้แปลว่าติดตั้งได้ง่าย เพราะการนำแพตช์ขึ้นระบบอาจต้องอัปเกรดไลบรารีที่พึ่งพากันอยู่ ทดสอบความเข้ากันได้และการเปลี่ยนแปลงที่กระทบระบบเดิม แล้วผลักผ่านกระบวนการพัฒนาและปล่อยรุ่นตามปกติขององค์กร เมื่อคูณด้วยช่องโหว่หลักพันรายการ การแก้ไขจึงกลายเป็นปัญหาการจัดลำดับและทรัพยากรขนาดใหญ่ที่ต้องแย่งเวลากับงานพัฒนาผลิตภัณฑ์

ข้อค้นพบสุดท้ายชี้ว่าองค์กรจำนวนมาก แม้แต่กลุ่มที่ประเมินตัวเองว่ามีแนวปฏิบัติด้านความปลอดภัยที่เข้าที่แล้ว ก็ยังสร้างความเสี่ยงให้ตัวเอง โดยเกือบ 6 ใน 10 หรือ 56% ของช่องโหว่ในคอนเทนเนอร์มาจากแพ็กเกจ ยูทิลิตี เครื่องมือพัฒนา และซอฟต์แวร์อื่นที่ไม่จำเป็นต้องมีอยู่ในระบบโปรดักชันเลย

ข้อจำกัดของรายงานฉบับนี้

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

ขอบเขตของข้อมูลก็จำกัดอยู่ที่โครงการคอนเทนเนอร์โอเพนซอร์ส 250 โครงการและแบบสอบถามผู้บริหารเพียง 80 กว่าคน ส่วนตัวเลขความแม่นยำของ Mythos คำนวณจากช่องโหว่ที่ Anthropic เปิดเผยต่อสาธารณะเพียง 27 รายการ ซึ่งเป็นกลุ่มตัวอย่างที่เล็กมากสำหรับข้อสรุปเรื่องความน่าเชื่อถือของการจัดระดับความรุนแรง นอกจากนี้การที่ช่องโหว่ยังไม่ได้รับการยืนยันจากภายนอกก็ไม่ได้แปลว่าไม่จริง อาจแปลเพียงว่ายังไม่มีใครมีเวลาไปตรวจเท่านั้น

ผลกระทบ

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

ตัวเลขที่ว่าโค้ดโจมตีสำหรับช่องโหว่ที่รู้จักแล้วสร้างได้ในไม่ถึงหนึ่งวันด้วยงบไม่ถึง 2,000 ดอลลาร์สหรัฐ ยังกระทบกับสมมติฐานเรื่องรอบการแพตช์โดยตรง องค์กรที่ยังวางแผนแพตช์เป็นรอบรายเดือนหรือรายไตรมาสสำหรับระบบที่เปิดสู่อินเทอร์เน็ต กำลังเดิมพันกับหน้าต่างเวลาที่แคบกว่าที่เคยเป็นมาก ขณะที่ข้อค้นพบเรื่องซอฟต์แวร์ส่วนเกินในคอนเทนเนอร์ 56% เป็นเรื่องที่ลดได้ทันทีโดยไม่ต้องซื้อของเพิ่ม เพียงแค่รื้อ base image ให้เหลือเท่าที่จำเป็นต่อการทำงานจริง

คำแนะนำ

องค์กรควรเริ่มจากการลดพื้นที่โจมตีที่มีอยู่แล้วก่อนกังวลกับช่องโหว่ใหม่ที่ AI จะขุดเจอ โดยตรวจสอบ base image ของคอนเทนเนอร์ที่ใช้อยู่ ถอดเครื่องมือพัฒนา คอมไพเลอร์ และยูทิลิตีที่ไม่จำเป็นต่อการรันในโปรดักชันออก แล้วเปลี่ยนไปใช้อิมเมจแบบบางที่มีเฉพาะสิ่งที่ต้องใช้

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

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

แหล่งอ้างอิง