
Claude Mythos Preview และ Project Glasswing ได้แสดงให้เห็นถึงการมาถึงของยุคสมัยที่ AI สามารถค้นพบ "ช่องโหว่ซอฟต์แวร์ที่ซ่อนตัวมานานหลายปี" และสร้างโค้ดโจมตี (Exploit) ได้ด้วยตนเอง ไม่ว่าจะเป็นบั๊กใน Network Stack ของ OpenBSD ที่หลับใหลมานานถึง 27 ปี, บั๊กอายุ 16 ปีใน FFmpeg ที่รอดพ้นจากการทำ Automated Fuzzing มากว่า 5 ล้านครั้ง หรือช่องโหว่ Remote Code Execution ใน NFS ของ FreeBSD (CVE-2026-4747) ซึ่งล้วนเป็นจุดอ่อนที่มนุษย์ไม่สามารถตรวจพบได้ แต่กลับถูกเปิดโปงออกมาทีละรายการ
บทความนี้จะสรุปการเปลี่ยนแปลงที่เกิดจาก Mythos และ Glasswing โดยอ้างอิงจากการประกาศอย่างเป็นทางการของ Anthropic (red.anthropic.com, anthropic.com/glasswing) และการประเมินจากผู้เชี่ยวชาญอย่าง Bruce Schneier พร้อมทั้งรวบรวม 5 แนวทางปฏิบัติสำหรับทีม DevSecOps ในองค์กรขนาดกลางในรูปแบบเช็คลิสต์ แม้ว่าตัว Mythos จะยังเปิดให้ใช้งานในวงจำกัด แต่ยังมีหลายสิ่งที่องค์กรสามารถทำได้ด้วยโมเดลปัจจุบัน การคิดว่า "จะรอให้เปิดตัวก่อนแล้วค่อยเริ่ม" เป็นความคิดที่ล้าหลังอย่างแน่นอนในยุคสมัยนี้
Claude Mythos Preview คือโมเดลแบบจำกัดการเข้าถึง (Limited Access) ที่ Anthropic วางตำแหน่งให้เป็น Frontier Model ที่เชี่ยวชาญด้านความปลอดภัยทางไซเบอร์โดยเฉพาะ ไม่ใช่โมเดลสร้างโค้ดอเนกประสงค์ทั่วไป แต่สามารถจัดการวงจรการโจมตีและป้องกันได้อย่างอัตโนมัติ ทั้งการค้นหาช่องโหว่ในซอร์สโค้ด การสร้างเอ็กซ์พลอยต์ (Exploit) และการสร้างแพตช์แก้ไข
บล็อกวิจัย Red Team ของ Anthropic ที่ red.anthropic.com ระบุว่า Mythos Preview มีประสิทธิภาพ "เหนือกว่าผู้เชี่ยวชาญที่เป็นมนุษย์ส่วนใหญ่" แม้จะไม่มีแผนเปิดเผยต่อสาธารณะ แต่มีรายงานว่าจะให้บริการแก่พันธมิตรที่ได้รับคัดเลือกในราคา 25 ดอลลาร์ต่อ 1 ล้านอินพุตโทเค็น และ 125 ดอลลาร์สำหรับเอาต์พุต
โมเดลนี้เป็นเครื่องมือหลักของ Project Glasswing ซึ่งถูกนำมาใช้เพื่อตรวจสอบซอฟต์แวร์สำคัญทั่วโลกในเชิงรุก (Proactive) สำหรับฝ่ายป้องกันอย่างบริษัทของเรา นี่ถือเป็นข้อเท็จจริงเบื้องต้นที่ต้องทำความเข้าใจเมื่อพิจารณาถึงความต่อเนื่องทางธุรกิจ
โมเดลอเนกประสงค์ (General-purpose models) ที่ผ่านมานั้นมีความสามารถในการสร้างโค้ดและตรวจจับรูปแบบช่องโหว่ที่เป็นที่รู้จักได้ดี แต่ยังไม่สามารถเทียบชั้นกับนักวิจัยที่เป็นมนุษย์ได้ในด้านการสร้างห่วงโซ่การโจมตี (Exploit chain) ที่ซับซ้อนด้วยตนเอง หรือการค้นหาบั๊กด้านความปลอดภัยของหน่วยความจำระดับต่ำโดยอัตโนมัติ
ความโดดเด่นของ Mythos Preview อยู่ที่ความสามารถในการดำเนินการตั้งแต่ (1) การค้นหาบั๊กจากซอร์สโค้ด (2) การสร้าง Exploit ที่ทำงานได้จริง (3) การทำวิศวกรรมย้อนกลับ (Reverse engineering) ของซอฟต์แวร์แบบปิด (Closed-source) ไปจนถึง (4) การสร้างแพตช์แก้ไข โดยทั้งหมดนี้สามารถทำได้โดยอัตโนมัติหลังจากได้รับ "Initial prompt เพียงครั้งเดียว" ทาง Anthropic ได้ระบุอย่างเป็นทางการว่าระบบนี้ทำงานได้ "fully autonomously" และรายงานว่าสามารถค้นหาและใช้ประโยชน์จากช่องโหว่ Remote Code Execution ที่มีมานานถึง 17 ปีได้โดยไม่ต้องอาศัยการแทรกแซงจากมนุษย์
นี่ถือเป็นการเปลี่ยนแปลงเชิงคุณภาพในโลกของการค้นหาช่องโหว่ เนื่องจาก SAST (Static Analysis) และ DAST (Dynamic Analysis) แบบเดิมต้องอาศัยการจับคู่รูปแบบ (Pattern matching) และการทำ Input Fuzzing จึงทำให้สามารถค้นพบได้เพียง "พื้นผิวการโจมตีที่นักออกแบบคาดการณ์ไว้เท่านั้น" แต่ Mythos สามารถทำความเข้าใจซอร์สโค้ดทั้งหมดในเชิงความหมาย (Semantically) และประกอบสร้างเส้นทางการโจมตีที่แม้แต่ตัวนักพัฒนาเองก็ยังไม่ทันสังเกตเห็น นี่คือเหตุผลที่บริษัทของเราอธิบายกับลูกค้าเสมอว่า "AI Code Review ไม่ใช่การเข้ามาแทนที่เครื่องมือเดิมที่มีอยู่ แต่เป็นชั้นการตรวจจับในอีกมิติหนึ่ง"
ตามการประกาศของ Anthropic ในการทดสอบด้วย CyberGym benchmark โมเดล Claude แบบทั่วไปทำคะแนนได้ 66.6% ในขณะที่ Mythos Preview ทำคะแนนได้ถึง 83.1% โดย CyberGym เป็น benchmark ที่วัดผลจากมุมมองของผู้โจมตี ทั้งในด้านการค้นหาช่องโหว่และการสร้าง exploit ซึ่งมีลักษณะแตกต่างจาก SWE-bench ที่เน้นวัดความสามารถด้านการเขียนโปรแกรม
ในการประเมินโดยใช้ OSS-Fuzz โมเดลทั่วไปสามารถตรวจพบ crash ใน Tier 1-2 ได้ 150-175 รายการ ในขณะที่ Mythos Preview บันทึกจำนวน crash ได้ถึง 595 รายการใน Tier เดียวกัน ยิ่งไปกว่านั้น ยังสามารถทำภารกิจใน Tier 5 ซึ่งเป็นระดับความยากสูงสุด (การเข้าควบคุม flow การทำงานโดยสมบูรณ์) ได้สำเร็จถึง 10 เป้าหมาย ซึ่งถือเป็นการก้าวกระโดดจากระดับ "ทำให้ระบบล่ม" ไปสู่ระดับ "การรันโค้ดตามต้องการ" (Arbitrary Code Execution)
ในการทดสอบการใช้ประโยชน์จากช่องโหว่ของ Firefox โมเดลทั่วไปทำสำเร็จเพียง 2 ครั้งจากการทดลองหลายร้อยครั้ง ในขณะที่ Mythos Preview ทำสำเร็จถึง 181 ครั้ง และยังสามารถควบคุมรีจิสเตอร์ได้อีก 29 ครั้ง ซึ่งเป็นความสามารถในการทำซ้ำที่แตกต่างกันอย่างสิ้นเชิง สิ่งนี้แสดงให้เห็นว่าไม่ใช่ความสำเร็จที่เกิดจากความบังเอิญหรือการสุ่ม แต่เป็นความสามารถในการวางแผนขั้นตอนการโจมตีอย่างเป็นระบบที่มีความเสถียร
หากความสามารถนี้ตกไปอยู่ในมือของผู้โจมตี เวลาในการเตรียมตัวของฝ่ายป้องกันจะลดน้อยลงอย่างมีนัยสำคัญ สถานการณ์ที่ "Anthropic ชิงความได้เปรียบไปก่อน" จึงมีความหมายเชิงยุทธศาสตร์อย่างยิ่ง
Mythos Preview ที่เผยแพร่ออกมานั้นมีความสำคัญในการแสดงให้เห็นถึงขอบเขตความสามารถของระบบ โดยกรณีศึกษาทั้งหมดได้รับการแก้ไขผ่านกระบวนการเปิดเผยช่องโหว่อย่างมีความรับผิดชอบ (Coordinated Vulnerability Disclosure) เรียบร้อยแล้ว และถือเป็นกรณีตัวอย่างที่ประสบความสำเร็จสำหรับฝ่ายป้องกัน
กรณีศึกษาทั้ง 4 รายการที่นำเสนอในที่นี้ ล้วนเป็นลักษณะที่ "การทำ Fuzzing หรือการตรวจสอบโดยมนุษย์ที่มีอยู่เดิมมองข้ามไป" เหตุผลที่พบช่องโหว่ที่ซ่อนตัวมานานเหล่านี้เป็นจำนวนมาก เป็นเพราะความสามารถของโมเดลที่สามารถทำความเข้าใจความหมายของซอร์สโค้ดและสร้างเส้นทางการโจมตีไปพร้อมกันนั้น เป็นสิ่งที่เครื่องมืออัตโนมัติในอดีตยังขาดอยู่
เรามักยกตัวอย่างเหล่านี้มาอ้างอิงบ่อยครั้งเมื่อต้องอธิบายถึงความคุ้มค่าของการนำ AI Code Review มาใช้ในขณะที่ให้การสนับสนุน DevSecOps แก่ลูกค้า หากภายในองค์กรถูกตั้งคำถามว่า "เหตุผลที่ต้องลงทุนใน AI Review คืออะไร?" การนำเสนอกรณีศึกษาเหล่านี้จะช่วยเพิ่มน้ำหนักในการโน้มน้าวใจได้อย่างมาก
OpenBSD เป็นระบบปฏิบัติการที่ถูกใช้งานอย่างแพร่หลายในโครงสร้างพื้นฐานที่สำคัญในฐานะไฟร์วอลล์และ VPN เกตเวย์ Mythos Preview ได้ค้นพบช่องโหว่ที่ทำให้เกิดการแครชจากระยะไกล ซึ่งซ่อนตัวอยู่ในส่วนการทำงานของ TCP SACK (Selective Acknowledgment) ของระบบปฏิบัติการนี้มานานถึง 27 ปี
กลไกการโจมตีเป็นรูปแบบที่ใช้ประโยชน์จาก Integer Overflow ของหมายเลขลำดับ TCP (TCP sequence number) โดย SACK เป็นฟังก์ชันเพิ่มความเร็วที่ช่วยให้ฝั่งผู้รับสามารถรายงานการขาดหายของแพ็กเก็ตได้พร้อมกัน แต่การคำนวณขอบเขตของฟังก์ชันนี้ไม่ได้พิจารณาถึงสถานการณ์ที่หมายเลขลำดับวนกลับมาครบรอบในขอบเขต 32 บิต ผู้โจมตีสามารถส่งลำดับที่ข้ามขอบเขตดังกล่าวโดยเจตนาเพื่อทำลายสถานะภายในและกระตุ้นให้เกิด Kernel Panic ได้
ข้อเท็จจริงที่ว่าช่องโหว่นี้ถูกมองข้ามโดยนักวิจัยและเครื่องมืออัตโนมัติจำนวนมากมาเป็นเวลาหลายปี แสดงให้เห็นว่าโมเดลที่เข้าใจบริบทของซอร์สโค้ดสามารถเข้ามาเสริมการทำงานของเครื่องมือตรวจสอบเชิงไวยากรณ์ (Syntactic analysis) ที่มีอยู่เดิมได้ บั๊กในเงื่อนไขขอบเขต (Boundary condition) เป็นประเภทของปัญหาที่ "หากนึกภาพ Test case ไม่ออก ก็จะไม่พบ" ซึ่งเป็นจุดที่ AI ที่สามารถอนุมานพื้นที่ของข้อมูลนำเข้าเชิงความหมายได้จะแสดงจุดแข็งออกมา
เนื่องจาก OpenBSD ถูกใช้เป็นรากฐานของผลิตภัณฑ์ด้านความปลอดภัย หากการค้นพบนี้เกิดขึ้นโดยฝ่ายผู้โจมตีก่อน ก็อาจนำไปสู่สถานการณ์ร้ายแรงที่ขอบเขตของเครือข่ายองค์กรถูกบุกรุกได้
ในส่วนของ FFmpeg ซึ่งเป็นซอฟต์แวร์ประมวลผลวิดีโอ (Video Codec) นั้น Mythos Preview ได้ตรวจพบช่องโหว่อายุ 16 ปีในตัวถอดรหัส H.264 ซึ่งมีสาเหตุมาจากข้อจำกัดในการใช้งานตัวแปรประเภท 16-bit แบบเก่า หากประมวลผลไฟล์วิดีโอพิเศษที่มีข้อมูลเกินขอบเขตที่กำหนด จะทำให้บัฟเฟอร์ภายในล้นและนำไปสู่การรันโค้ดโดยไม่ได้รับอนุญาต (Arbitrary Code Execution) ช่องโหว่นี้ถือเป็นบั๊กประเภทที่ไม่สามารถตรวจพบได้แม้จะผ่านการทำ Automated Fuzzing มาแล้วกว่า 5 ล้านครั้งด้วย OSS-Fuzz ซึ่งเป็นตัวอย่างที่ดีที่แสดงให้เห็นว่า AI สามารถค้นพบเส้นทางของโค้ดที่การสุ่มข้อมูลแบบปกติไม่สามารถเข้าถึงได้ด้วยการวิเคราะห์เชิงตรรกะ
สำหรับ FreeBSD นั้น Mythos Preview ได้ค้นพบและใช้ประโยชน์จากช่องโหว่อายุ 17 ปี (CVE-2026-4747) ใน NFS (Network File System) ซึ่งเปิดช่องให้สามารถรันโค้ดจากระยะไกลได้ โดย AI ได้ทำการผสมผสานช่องโหว่ประเภท Type Confusion และ Memory Corruption ที่ซ่อนอยู่ในกระบวนการถอดรหัส RPC ของ NFS เข้าด้วยกัน จนถึงขั้นสร้าง ROP (Return-Oriented Programming) chain ได้อย่างสมบูรณ์แบบโดยอัตโนมัติ ทั้งนี้ Anthropic ได้ระบุชัดเจนว่า "ระบบทำงานโดยอัตโนมัติอย่างสมบูรณ์หลังจากได้รับคำสั่งเริ่มต้น" ซึ่งเป็นการพิสูจน์ว่า AI สามารถค้นหา ROP gadget ที่แฮกเกอร์มักใช้กันได้ด้วยตนเอง
ใน Linux เคอร์เนล โมเดลสามารถเชื่อมโยงช่องโหว่หลายจุดเข้าด้วยกันจนประสบความสำเร็จในการยกระดับสิทธิ์จากผู้ใช้ทั่วไปไปสู่ root ได้ แม้จะเป็นเพียงบั๊กเล็กน้อยหากมองแยกส่วน แต่การนำมาประกอบกันตามลำดับ ทั้งการจัดการหน่วยความจำ (memory layout), การนำออบเจกต์ของเคอร์เนลกลับมาใช้ใหม่ (kernel object reuse) และการยกเลิกการอ้างอิงที่ขอบเขตสิทธิ์ (dereferencing at privilege boundaries) ก็เป็นเส้นทางสู่การยกระดับสิทธิ์ที่ไม่ใช่เรื่องแปลกใหม่แต่อย่างใด สิ่งนี้แสดงให้เห็นว่าโมเดลสามารถสร้างเส้นทางการโจมตีที่ปกติแล้วนักทดสอบเจาะระบบที่เป็นมนุษย์ต้องใช้เวลาหลายวันในการสร้างขึ้นมาได้โดยอัตโนมัติ
ในส่วนของเบราว์เซอร์ โมเดลสามารถสร้างการโจมตีแบบผสม (composite exploit) ต่อ JIT (Just-In-Time) compiler ของ Firefox ได้ โดยการรวมเทคนิค JIT spraying และการคาดการณ์ heap layout เข้าด้วยกัน ทำให้สามารถสร้างเส้นทางจากการเข้าชมหน้าเว็บไปสู่การรันโค้ดตามอำเภอใจ (arbitrary code execution) ได้สำเร็จถึง 181 ครั้ง และยังสามารถควบคุมรีจิสเตอร์ได้อีก 29 ครั้ง ซึ่งถือเป็นความสามารถในการทำซ้ำที่เหนือชั้นกว่าเดิมมาก และบ่งชี้ว่านี่ไม่ใช่ "ความบังเอิญ" อีกต่อไป แต่กำลังกลายเป็นความสามารถที่มั่นคงและชัดเจนขึ้นเรื่อยๆ
Project Glasswing คือกลุ่มความร่วมมือทางอุตสาหกรรมที่จัดตั้งขึ้นเพื่อให้ฝ่ายป้องกันสามารถใช้งาน Mythos Preview ได้ "ก่อนที่ผู้โจมตีจะทำได้" โดยเป็นความพยายามในการตรวจสอบซอฟต์แวร์สำคัญอย่างครอบคลุมด้วย AI เพื่อสร้างยุคสมัยที่ฝ่ายป้องกันมีความได้เปรียบโดยเจตนา
ตามข้อมูลจากหน้าเว็บไซต์ทางการของ Anthropic ที่ anthropic.com/glasswing พันธมิตรก่อตั้งประกอบด้วย 11 องค์กร ได้แก่ Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA และ Palo Alto Networks นอกจากนี้ยังมีอีกกว่า 40 องค์กรที่เข้าร่วมในฐานะผู้ดูแลโครงสร้างพื้นฐานที่สำคัญ
เวลาที่ฝ่ายป้องกันจะสามารถครอบครองขีดความสามารถด้าน AI แต่เพียงผู้เดียวนั้นมีจำกัด แม้แต่ Anthropic เองยังระบุว่า "หากลงมือทำในตอนนี้ เราจะสามารถสร้างยุค AI ที่ฝ่ายป้องกันมีความได้เปรียบได้" ซึ่งในทางกลับกัน นี่ก็เป็นคำเตือนว่าหากไม่ลงมือทำ ฝ่ายโจมตีจะเป็นผู้ได้เปรียบแทน
Anthropic ได้ให้คำมั่นว่าจะมอบเครดิตการใช้งาน Mythos Preview มูลค่าสูงสุด 100 ล้านดอลลาร์ และบริจาคโดยตรงให้กับองค์กรด้านความปลอดภัยแบบโอเพนซอร์สเป็นจำนวน 4 ล้านดอลลาร์ โดยแบ่งเป็นการบริจาคให้ Alpha-Omega และ OpenSSF ผ่านทาง Linux Foundation จำนวน 2.5 ล้านดอลลาร์ และให้กับ Apache Software Foundation จำนวน 1.5 ล้านดอลลาร์
Glasswing มีแผนที่จะเผยแพร่รายงานผลลัพธ์ภายใน 90 วัน กระบวนการเปิดเผยข้อมูลอย่างรับผิดชอบทั้งหมดจะเป็นไปตามนโยบาย Coordinated Vulnerability Disclosure ของ Anthropic ซึ่งโดยหลักการแล้วจะมีการเปิดเผยข้อมูลภายใน 90 วันหรือเมื่อมีการปล่อยแพตช์แล้วแต่เหตุการณ์ใดจะเกิดขึ้นก่อน นอกจากนี้ หลังจากมีการปล่อยแพตช์แล้ว โดยปกติจะมีการเว้นระยะเวลาไว้ 45 วันก่อนที่จะเปิดเผยรายละเอียดทางเทคนิค เพื่อสร้างความสมดุลระหว่างการให้เวลาแก่นักพัฒนาในการแก้ไขปัญหาและการแบ่งปันข้อมูลให้กับฝ่ายป้องกัน
มีช่องทางหลัก 2 ช่องทางที่บริษัทขนาดกลางและผู้ดูแล OSS จะเข้ามามีส่วนร่วมกับ Glasswing ได้:
ช่องทางแรกคือโปรแกรม "Claude for Open Source" ซึ่งเป็นกรอบการทำงานที่มอบ Claude ให้แก่ผู้ดูแล OSS โดยไม่มีค่าใช้จ่ายหรือในราคาพิเศษ สำหรับโครงการ OSS ที่มีผลงานบน GitHub ตามเกณฑ์ที่กำหนด ผู้ดูแลโครงการสามารถสมัครในนามบุคคลได้ หากผู้ดูแล OSS ที่บริษัทของคุณใช้งานอยู่เป็นผู้สมัคร ผลลัพธ์ที่ได้คือการยกระดับความปลอดภัยของต้นน้ำ (Upstream) ซึ่งจะนำไปสู่การปกป้องห่วงโซ่อุปทานของบริษัทคุณในท้ายที่สุด
อีกช่องทางหนึ่งคือ "Cyber Verification Program" ซึ่งเปิดโอกาสให้นักวิจัยและบริษัทที่มีผลงานด้านความปลอดภัยทางไซเบอร์ที่ได้รับการยอมรับ สามารถยื่นขอสิทธิ์เข้าถึงโมเดลที่มีประสิทธิภาพสูงขึ้นได้ โดยกลุ่มเป้าหมายหลักคือบริษัทที่มีทีม SOC หรือทีมทำ Pentest ภายในองค์กร รวมถึงบริษัทผู้ให้บริการด้านความปลอดภัย
แม้ว่าจะมีเพียงไม่กี่องค์กรเท่านั้นที่จะได้เข้าถึง Mythos Preview จริงๆ แต่การติดตามความเคลื่อนไหวและนำมาปรับใช้กับแนวทางด้านความปลอดภัยขององค์กรนั้นถือเป็นเรื่องสำคัญสำหรับทุกบริษัท ก่อนที่จะตัดบทว่า "เราไม่อยู่ในข่ายจึงไม่เกี่ยวข้อง" การพิจารณาความเป็นไปได้ในการสมัครภายในองค์กรก่อนถือเป็นแนวทางที่ควรทำ

สำหรับการประกาศของ Mythos และ Glasswing นั้น ชุมชนผู้เชี่ยวชาญด้านความปลอดภัยทางไซเบอร์ได้หยิบยกประเด็นสำคัญหลายประการขึ้นมาถกเถียงกัน เราจำเป็นต้องวิเคราะห์อย่างใจเย็นว่าสิ่งใดเปลี่ยนไปและสิ่งใดที่ยังคงเดิม แทนที่จะมองโลกในแง่ดีเพียงอย่างเดียว
ในที่นี้ เราจะหยิบยก 2 ประเด็นที่มีอิทธิพลสูงมากล่าวถึง ได้แก่ คำเตือนของ Bruce Schneier ที่ว่า "ความได้เปรียบในการป้องกันกำลังลดน้อยลง" และข้อสังเกตของบริษัทความปลอดภัย Aisle ที่ระบุว่า "ความสามารถบางส่วนสามารถทำซ้ำได้ด้วยโมเดลที่มีอยู่เดิม" ซึ่งทั้งสองประเด็นนี้ต่างชี้ให้เห็นถึงลำดับความสำคัญของการดำเนินการที่องค์กรควรทำในทันที
นักวิจัยด้านความปลอดภัย Bruce Schneier ได้เตือนผ่านบล็อกส่วนตัว schneier.com ว่า แม้ความได้เปรียบในการป้องกันของ Mythos จะเป็นเรื่องจริง แต่ "เมื่อโมเดลที่มีความสามารถสูงขึ้นเรื่อยๆ ปรากฏออกมา ความได้เปรียบนั้นก็น่าจะลดน้อยลง"
ในขณะที่เขายอมรับว่าความไม่สมมาตรที่ว่า "การค้นหาบั๊กเพื่อแก้ไขนั้นง่ายกว่าสำหรับ AI เมื่อเทียบกับการค้นหาเพื่อนำไปใช้ประโยชน์" เป็นข้อได้เปรียบชั่วคราว แต่เขาก็ชี้ให้เห็นว่าเป็นเพียงเรื่องของเวลาก่อนที่ฝ่ายโจมตีจะเข้าถึงขีดความสามารถที่เท่าเทียมกันด้วยโมเดลโอเพนซอร์ส
Schneier เรียกร้องให้เปลี่ยนผ่านไปสู่การสร้างความยืดหยุ่น (Resilience) ในระดับระบบ โดยตั้งอยู่บนสมมติฐานของ "โลกที่การโจมตีแบบ Zero-day กลายเป็นเรื่องดาษดื่น (dime-a-dozen)" โดยเฉพาะอย่างยิ่ง แกนหลักจะไม่ใช่การจัดการแพตช์แบบรายตัวอีกต่อไป แต่จะเป็นการออกแบบโดยแบ่งส่วน (Segmentation), การบันทึกข้อมูล (Logging), หลักการสิทธิ์ขั้นต่ำ (Least Privilege) และระบบการตอบสนองที่รวดเร็ว โดยเป็นการเปลี่ยนผ่านจากโมเดลที่ "ตั้งเป้าว่าจะไม่ถูกบุกรุก" ไปสู่โมเดลที่ "ลดความเสียหายให้เหลือน้อยที่สุดแม้จะถูกบุกรุก" หรือก็คือการนำการออกแบบ Zero Trust มาใช้อย่างเต็มรูปแบบนั่นเอง
บริษัทด้านความปลอดภัย Aisle ชี้ให้เห็นว่า เราสามารถจำลองความสามารถบางส่วนที่ Mythos ทำได้ โดยใช้โมเดลอเนกประสงค์ราคาประหยัดที่มีเผยแพร่อยู่ทั่วไป แม้ว่าจะยังคงมีช่องว่างระหว่าง "การค้นหาช่องโหว่" กับ "การเปลี่ยนให้เป็นช่องทางการโจมตีที่ใช้งานได้จริง" แต่สำหรับวัตถุประสงค์ในการป้องกันขององค์กร เป้าหมายคือ "การค้นหาและกำจัดบั๊กที่อาจถูกโจมตีได้ตั้งแต่เนิ่นๆ" จึงไม่จำเป็นต้องถึงขั้นทำระบบสร้างเอ็กซ์พลอยต์ (Exploit) ให้เป็นอัตโนมัติ การค้นหาบั๊กตั้งแต่เนิ่นๆ ไปจนถึงการเสนอแพตช์แก้ไขโดยอัตโนมัติก็เพียงพอที่จะสร้างความคุ้มค่าในการลงทุนแล้ว
กล่าวคือ แม้แต่บริษัทขนาดกลางที่ยังเข้าไม่ถึง Mythos Preview ก็ยังมีช่องว่างมากมายในการนำ "การค้นหาช่องโหว่ด้วย AI" มาปรับใช้ในกระบวนการทำงานด้วยกลุ่มโมเดลที่มีอยู่ในปัจจุบัน ซึ่งนี่คือประเด็นที่บริษัทของเราเน้นย้ำกับลูกค้ามากที่สุด เราควรเริ่มต้นจากการ "ทำความเข้าใจอย่างถ่องแท้ว่าโมเดลปัจจุบันสามารถทำอะไรได้บ้าง" แทนที่จะคิดว่า "ทำอะไรไม่ได้เลยเพราะเข้าไม่ถึง Frontier Model"
การจะเปลี่ยนข่าวสารจาก Mythos Preview ให้ไม่ใช่แค่เรื่องของคนอื่น แต่เป็นการนำมาปรับใช้กับแนวทางความปลอดภัยขององค์กรนั้น จำเป็นต้องเปลี่ยนจากทฤษฎีเชิงนามธรรมให้กลายเป็นการปฏิบัติที่เป็นรูปธรรม ต่อไปนี้คือ 5 แนวทางการปฏิบัติที่บริษัทของเราแนะนำสำหรับธุรกิจขนาดกลาง
แนวทางทั้งหมดนี้ไม่จำเป็นต้องเข้าถึงตัว Mythos โดยตรง แต่เน้นไปที่สิ่งที่สามารถทำได้จริงด้วยการผสมผสานโมเดลปัจจุบันและเครื่องมือที่มีอยู่เดิม ซึ่งใช้เวลาดำเนินการเร็วที่สุดเพียง 1-2 สัปดาห์ และใช้เวลาประมาณ 3 เดือนสำหรับการใช้งานเต็มรูปแบบ หากดำเนินการควบคู่ไปกับการจัดทำธรรมาภิบาล AI (AI Governance) จะช่วยให้การจัดทำเอกสารด้านการปฏิบัติตามกฎระเบียบ (Compliance) และการนำไปใช้งานจริงดำเนินไปพร้อมกัน ซึ่งจะช่วยหลีกเลี่ยงสถานการณ์ที่ต้องมาเร่งจัดการเรื่องการตรวจสอบย้อนหลังได้ง่ายขึ้น
แม้ว่า Mythos จะยังเปิดให้ใช้งานแบบจำกัด แต่การวิเคราะห์โค้ดแบบสแตติก (Static Code Analysis) และการรีวิวอัตโนมัติโดยใช้ Claude หรือ GPT รุ่นทั่วไปที่มีอยู่ในปัจจุบันนั้นสามารถทำได้แล้ว หากนำไปรวมเข้ากับ CI/CD pipeline โดยใช้กระบวนการสามขั้นตอนคือ "LLM Review → Existing Linter → Fuzzing" ในทุกๆ PR จะช่วยลดบั๊กเชิงตรรกะที่มนุษย์อาจมองข้ามไปได้อย่างมาก
แนวทางที่เป็นจริงคืออย่าเพิ่งรีบเร่งไปสู่ระบบอัตโนมัติเต็มรูปแบบ แต่ควรเริ่มจากการวัดผลใน repository ขนาดเล็กก่อน เพื่อสะสมข้อมูลอัตราการตรวจพบ (Detection Rate) และอัตราการแจ้งเตือนที่ผิดพลาด (False Positive Rate) ไว้เป็นข้อมูลภายในบริษัท หากมีการวัดผลทุกๆ 3 เดือนในหัวข้อ "สัดส่วนของสิ่งที่ LLM ชี้ว่าเป็นบั๊กและเป็นบั๊กจริง" และ "จำนวนบั๊กที่ LLM ตรวจพบหลังจากผ่านการรีวิวโดยมนุษย์ไปแล้ว" ก็จะได้ข้อมูลที่เพียงพอสำหรับการตัดสินใจลงทุน
สำหรับบริษัทที่ประกอบธุรกิจด้านความปลอดภัยโดยตรง หรือองค์กรที่มีนักวิจัยผู้เชี่ยวชาญประจำอยู่ การพิจารณาสมัครเข้าร่วม Cyber Verification Program ถือเป็นสิ่งที่คุ้มค่า หากได้รับการอนุมัติ คุณจะสามารถเข้าถึงฟังก์ชันการทำงานของโมเดลระดับ Mythos ได้บางส่วน ซึ่งช่วยให้สามารถตรวจสอบผลิตภัณฑ์ของตนเองได้อย่างละเอียดก่อนการใช้งานจริง
การสมัครจำเป็นต้องแสดงผลงานทางธุรกิจที่ชัดเจน ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องเก็บประวัติการมีส่วนร่วมในการเปิดเผยช่องโหว่ (Vulnerability Disclosure) และการเข้าร่วมโครงการ Bug Bounty ไว้ตั้งแต่ช่วงเวลาปกติ โดยผลงานที่จะนำมาพิจารณา ได้แก่ ประวัติการเข้าร่วมแพลตฟอร์มอย่าง HackerOne / Bugcrowd ของพนักงานในองค์กร, รายงานช่องโหว่ที่ได้รับหมายเลข CVE และจำนวนครั้งที่ได้รับคำขอบคุณจากการเปิดเผยข้อมูลอย่างรับผิดชอบ (Responsible Disclosure)
สำหรับองค์กรที่เผยแพร่ OSS โครงการ Claude for Open Source จะเป็นจุดเริ่มต้นที่เหมาะสมกว่า หากเป็นโปรเจกต์ OSS ที่มีประวัติการดำเนินงานบน GitHub ทางโครงการก็เปิดรับการสมัครในระดับผู้ดูแล (Maintainer) เช่นกัน
โดยทั่วไปแล้ว Incident Response Playbook แบบเดิมมักถูกออกแบบโดยตั้งสมมติฐานว่า "จะตอบสนองต่อเมื่อมีการรายงาน CVE ที่ทราบแน่ชัดแล้ว" แต่สิ่งที่ Mythos แสดงให้เห็นคือความจริงที่ว่า ยังมี Zero-day ที่ยังไม่ถูกเปิดเผยอีกหลายพันรายการซ่อนอยู่ใน OS, เบราว์เซอร์ และไลบรารีหลักๆ ของโลก และทันทีที่ผู้โจมตีสามารถใช้ AI ในการค้นหาช่องโหว่เหล่านี้ได้ในระดับเดียวกัน ช่องโหว่เหล่านี้จะถูกนำมาใช้เป็นอาวุธทันที
เพื่อให้สอดคล้องกับสมมติฐานที่ว่า "Zero-day มีอยู่ตลอดเวลา" IR Playbook ควรครอบคลุม 4 ประเด็นต่อไปนี้:
DevSecOps の基本原則である「シフトレフト」を、AI コードレビューと統合します。OWASP Top 10 や OWASP LLM Top 10 のチェック項目を PR 自動コメントとして反映する仕組みを作ることで、開発者は「指摘されてから直す」のではなく「書いた瞬間にフィードバックを受ける」ループへ移行できます。
また、シニアレビュアーの工数を、判断が難しい設計レビューに集中させられるという副次効果もあります。当社の支援案件では、AI コードレビュー導入後 2 ヶ月で人間によるレビュー時間が 30〜40% 削減された事例があります。
注意点として、AI レビューを「ハンコ押し(形式的な承認)」にしないためのルール作りが必要です。「LLM が OK を出したから安全」と過信すると、誤検知の逆である見落とし(false negative)が問題となります。AI は補助的な層であり、人間の最終判断を排除するものではないという運用ルールを明文化してください。
EU AI Act ซึ่งมีผลบังคับใช้เต็มรูปแบบแล้ว ได้กำหนดให้ระบบ AI ที่มีความเสี่ยงสูงต้องมีมาตรการรักษาความปลอดภัยทางไซเบอร์และการบริหารจัดการความเสี่ยงอย่างต่อเนื่อง ในกรณีที่มีการนำ AI มาใช้ในกระบวนการตรวจหาช่องโหว่ (vulnerability discovery) อย่างเป็นทางการ ความรับผิดชอบ (accountability) และการเก็บรักษาบันทึกข้อมูล (log preservation) ของตัว AI เอง จะกลายเป็นประเด็นสำคัญด้านการปฏิบัติตามกฎระเบียบ (compliance) การจัดเก็บข้อมูลในรูปแบบที่สามารถตรวจสอบย้อนหลังได้ว่า "โมเดลใด ตรวจพบอะไร ในโค้ดส่วนไหน เมื่อใด และด้วยเหตุผลใด" ถือเป็นเงื่อนไขเบื้องต้นสำหรับการรองรับการตรวจสอบ (audit)
การตรวจสอบความสอดคล้องระหว่างหมวดหมู่ต่างๆ ใน OWASP LLM Top 10 (เช่น Prompt Injection, การรั่วไหลของข้อมูลลับ, Supply Chain ฯลฯ) กับธรรมาภิบาลภายในองค์กร รวมถึงการระบุขอบเขตความรับผิดชอบ (responsibility demarcation) ให้ชัดเจนในกรณีที่ผลการตรวจสอบโค้ดด้วย AI นำไปสู่เหตุการณ์ไม่พึงประสงค์ จะเป็นประโยชน์อย่างยิ่งต่อการรองรับการตรวจสอบในอนาคต
นอกจากนี้ ในกลุ่มประเทศอาเซียน กฎหมายคุ้มครองข้อมูลส่วนบุคคล (เช่น PDPA ของไทย, PDPL ของเวียดนาม, กฎหมาย PDP ของอินโดนีเซีย และกฎหมายคุ้มครองข้อมูลส่วนบุคคลของลาว) กำลังได้รับการพัฒนาให้มีความสมบูรณ์ยิ่งขึ้น ซึ่งส่งผลให้จำเป็นต้องมีการปรับกรอบธรรมาภิบาลให้สอดคล้องกัน ครอบคลุมไปถึงบริษัทลูกในแต่ละท้องถิ่นด้วย
Mythos Preview อาจจะยังไม่เข้าถึงมือของบริษัทขนาดกลาง แต่ไม่ได้หมายความว่า "ยุคสมัยที่ AI ค้นหาและใช้ประโยชน์จากช่องโหว่" จะเป็นเรื่องไกลตัว สิ่งที่เราต้องการจะสื่อคือ แม้แต่โมเดลในปัจจุบันก็สามารถเสริมความแข็งแกร่งในการป้องกันได้อย่างเพียงพอ และช่วงเวลานี้ซึ่งเป็นช่วงเตรียมการคือเวลาที่ต้องลงมือทำ
ในฐานะที่เราสนับสนุนบริษัทขนาดกลางในไทย ญี่ปุ่น และกลุ่มประเทศอาเซียน ลำดับความสำคัญนั้นชัดเจน ประการแรก คือการนำ Claude หรือ GPT รุ่นทั่วไปที่มีอยู่ในปัจจุบันมาใช้ในการรีวิวภายใน (Internal Review) และการทำ Fuzzing เข้าสู่กระบวนการทำงาน ประการที่สอง คือการปรับปรุง IR Playbook โดยตั้งสมมติฐานว่า "Zero-day คือเรื่องปกติ" พร้อมทั้งจัดเตรียมการเก็บรักษา Log และการซ้อมแผนรับมือ (Tabletop Exercise) ประการที่สาม คือการปรับกรอบการกำกับดูแล AI (EU AI Act / OWASP LLM Top 10) ให้สอดคล้องกับการดำเนินงานขององค์กร
การรอให้ "Mythos เปิดตัวสู่สาธารณะแล้วค่อยคิด" นั้นถือว่าสายเกินไป สิ่งที่ Glasswing แสดงให้เห็นคือความจริงที่ว่า ระยะเวลาผ่อนปรนที่มอบให้กับฝ่ายป้องกันนั้นไม่ได้ยาวนานนัก ดังที่ Schneier ได้เตือนไว้ว่า เป็นเพียงเรื่องของเวลาก่อนที่ฝ่ายโจมตีจะเข้าถึงขีดความสามารถที่เท่าเทียมกัน และเมื่อถึงเวลานั้น บริษัทที่ "ไม่ได้ทำอะไรเลย" จะตกเป็นเหยื่อก่อน
บริษัทของเราให้บริการสนับสนุนการสร้างระบบ Secure Coding โดยใช้ Claude, การจัดทำ LLM Governance และการนำระบบ AI Code Review มาใช้ภายในองค์กร สำหรับบริษัทที่ต้องการทบทวนท่าทีด้านความปลอดภัยทางไซเบอร์ในยุค AI สามารถติดต่อปรึกษาเราได้ทันที

Yusuke Ishihara
เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)