พรมแดนใหม่ของความมั่นคงปลอดภัยไซเบอร์ AI: ความจริงหลัง Mythos

• หลังจากที่ Claude Mythos ของ Anthropic ตรวจพบช่องโหว่ zero-day จำนวนมากได้แบบอัตโนมัติ ก็พบว่า โมเดลเปิดขนาดเล็กก็สามารถตรวจพบช่องโหว่เดียวกันได้สำเร็จเช่นกัน
• โมเดลระดับ 3.6B~5.1B พารามิเตอร์ สามารถทำซ้ำบั๊กของ FreeBSD และ OpenBSD ได้ และบางตัวเสนอ เส้นทาง exploit ที่สร้างสรรค์ ซึ่งแตกต่างจาก Mythos
• ผลการทดลองชี้ว่า ขนาดโมเดลกับประสิทธิภาพมีความสัมพันธ์แบบไม่เป็นเส้นตรง และในบางงาน โมเดลขนาดเล็กแม่นยำกว่าโมเดลขนาดใหญ่
• ความสามารถด้านความปลอดภัยของ AI ไม่ได้ขยายตัวอย่างราบรื่น แต่เป็นแบบ ‘ขรุขระ’ และความได้เปรียบที่แท้จริงอยู่ที่ การออกแบบระบบและ pipeline การตรวจสอบ มากกว่าตัวโมเดล
• ดังนั้น คูเมืองของงานความปลอดภัยไม่ใช่โมเดล แต่คือระบบ และ โครงสร้าง orchestration ที่ฝังความรู้ผู้เชี่ยวชาญไว้ คือหัวใจของ AI security

---

ระบบต่างหากที่เป็นคูเมือง ไม่ใช่โมเดล

• วันที่ 7 เมษายน 2026 Anthropic เปิดตัว Claude Mythos Preview และ Project Glasswing พร้อมจัดตั้ง consortium ที่ใช้โมเดล Mythos เพื่อตรวจหาและแพตช์ช่องโหว่ความปลอดภัยของซอฟต์แวร์สำคัญโดยอัตโนมัติ
  • ให้คำมั่น เครดิตการใช้งานมูลค่า 100 ล้านดอลลาร์ และ เงินบริจาค 4 ล้านดอลลาร์แก่องค์กรด้านความปลอดภัยโอเพนซอร์ส
  • Mythos ค้นพบ ช่องโหว่ zero-day หลายพันรายการ และตรวจพบพร้อมสร้าง exploit ได้อย่างอัตโนมัติ เช่น บั๊ก OpenBSD ที่มีอยู่มา 27 ปี, บั๊ก FFmpeg ที่มีอยู่มา 16 ปี, และ ช่องโหว่ remote code execution ของ FreeBSD
• AISLE ทำซ้ำช่องโหว่เดียวกันด้วย โมเดลขนาดเล็ก ราคาถูก และเปิดน้ำหนักโมเดล
  • 8 จาก 8 โมเดล ตรวจพบ exploit ของ FreeBSD ได้
  • แม้แต่ โมเดล 3.6B พารามิเตอร์ (ราคา $0.11 ต่อโทเค็น) ก็ตรวจพบได้สำเร็จ
  • โมเดล 5.1B สามารถกู้คืน chain หลักของบั๊ก OpenBSD ได้
  • ในบางงาน โมเดลเปิดขนาดเล็กทำได้ดีกว่าโมเดลขนาดใหญ่
• ผลลัพธ์จึงชี้ว่า ความสามารถด้านความปลอดภัยของ AI มีลักษณะไม่เป็นเส้นตรงและขรุขระ (jagged)
  • ไม่มีโมเดลใดทำได้ดีที่สุดในทุกงาน
  • แกนหลักของความสามารถในการแข่งขันด้านความปลอดภัยไม่ใช่โมเดล แต่เป็นระบบ โดยมี โครงสร้าง orchestration ที่ฝังความรู้ผู้เชี่ยวชาญ เป็นศูนย์กลาง

ตำแหน่งปัจจุบันของ AI security

• ตั้งแต่กลางปี 2025 AISLE ได้นำ ระบบตรวจหาและแพตช์ช่องโหว่ด้วย AI ไปใช้กับเป้าหมายจริง
  • ค้นพบ CVE 15 รายการ ใน OpenSSL, 5 รายการ ใน curl และรวมแล้วมากกว่า 180 CVE ที่ได้รับการยืนยันจากภายนอก
  • CTO ของ OpenSSL ประเมินว่า “คุณภาพของรายงานและกระบวนการทำงานร่วมกันยอดเยี่ยม”
• แม้จะใช้หลายโมเดล แต่ โมเดลของ Anthropic ไม่ได้ดีกว่าเสมอไป
  • เนื่องจากโมเดลที่เหมาะสมต่างกันไปตามงาน จึงเลือกใช้แนวทางแบบ ไม่ยึดติดกับโมเดลใดโมเดลหนึ่ง

แยกส่วน pipeline ความปลอดภัย AI

• AI security ในโลกจริงไม่ได้ประกอบด้วยโมเดลเดี่ยว แต่เป็น pipeline หลายขั้นตอน
  • แต่ละขั้น เช่น การสแกนวงกว้าง, การตรวจหาช่องโหว่, การตรวจสอบและจัดประเภท, การสร้างแพตช์, การประกอบ exploit ล้วนมี ลักษณะการขยายตัวที่ต่างกัน
• Anthropic เน้นขยายอินพุตตัวแรก (ความฉลาดของโมเดล) ให้สูงสุด ขณะที่ AISLE ให้ความสำคัญเท่าๆ กันกับปัจจัยหลายด้าน เช่น ต้นทุนต่อโทเค็น, ความเร็ว, และความเชี่ยวชาญด้านความปลอดภัย

บทสรุป: คูเมืองคือระบบ

• โครงสร้างที่กล่าวถึงในโพสต์เทคนิคของ Mythos เช่น การรันคอนเทนเนอร์, การสแกนไฟล์, การตรวจสอบด้วย ASan, การประเมินลำดับความสำคัญ มีลักษณะคล้ายกับระบบของ AISLE
• ศูนย์กลางของคุณค่าไม่ได้อยู่ที่โมเดล แต่อยู่ที่กระบวนการกำหนดเป้าหมาย การตรวจสอบ และการสร้างความเชื่อมั่น
• วิธีการ วางโมเดลขนาดเล็กจำนวนมากแบบขนาน เพื่อสำรวจโค้ดทั้งหมดอย่างกว้างขวาง สามารถได้ทั้ง ความคุ้มค่าทางเศรษฐกิจและประสิทธิภาพในการตรวจจับ
• Mythos พิสูจน์ให้เห็นว่าหมวดหมู่นี้ใช้งานได้จริง แต่ การขยายการปฏิบัติการและการสร้างความน่าเชื่อถือ ยังเป็นโจทย์ที่เหลืออยู่

ผลการทดลอง: ความสามารถด้านความปลอดภัยที่ขรุขระ

• มีการทดลองกับ โมเดลขนาดเล็กและต้นทุนต่ำ โดยใช้ช่องโหว่เด่นจากการประกาศของ Mythos เป็นเป้าหมาย

  • บั๊ก FreeBSD NFS, บั๊ก OpenBSD SACK, การทดสอบ false positive ของ OWASP

    • โดยสรุป ขนาด รุ่น และราคาของโมเดลมีความสัมพันธ์กับประสิทธิภาพแบบไม่เป็นเส้นตรง
    • การตรวจหา FreeBSD สำเร็จทุกโมเดล, OpenBSD สำเร็จเพียงบางโมเดล, ส่วน OWASP โมเดลขนาดเล็กแม่นยำกว่าโมเดลใหญ่
    • การตรวจหา FreeBSD: ทั้ง 8 โมเดลตรวจพบบัฟเฟอร์โอเวอร์โฟลว์
    • แม้แต่โมเดล 3.6B ก็ยังคำนวณได้อย่างถูกต้องและทำ การประเมินความเป็นไปได้ของ RCE
    • DeepSeek R1 ทำการคำนวณที่สอดคล้องกับโครงสร้างสแตกจริง
    • ในด้าน ตรรกะการทำ exploit ทุกโมเดลเสนอ กลยุทธ์ ROP chain
    • บางโมเดลเสนอแนวทางแก้ปัญหาที่สร้างสรรค์และต่างจาก Mythos (เช่น ยกระดับสิทธิ์จาก user mode แทน kernel mode)
    • บั๊ก OpenBSD SACK: โมเดล 5.1B สามารถกู้คืน chain ทั้งหมดและเสนอแพตช์ที่ถูกต้อง
    • Qwen3 32B ทำได้สมบูรณ์แบบใน FreeBSD แต่ในกรณีนี้กลับตัดสินผิดว่า “ปลอดภัย”
    • อันดับประสิทธิภาพของแต่ละโมเดลสลับกันโดยสิ้นเชิงในแต่ละงาน

• การทดสอบ false positive ของ OWASP: ในโค้ด Java แบบง่าย โมเดลเล็กแม่นยำกว่าโมเดลใหญ่

  • GPT-OSS-20b, DeepSeek R1, OpenAI o3 ตัดสินได้ถูกต้องว่า “ตอนนี้ปลอดภัย แต่มีความเป็นไปได้ที่จะเปราะบาง”
  • โมเดลตระกูล Anthropic และ GPT-4.x หลายตัวกลับ ตรวจพบ SQL injection ผิดพลาด

การทดสอบการรับรู้แพตช์ (อัปเดต 9 เมษายน 2026)

• มีการเปรียบเทียบ ความสามารถในการตรวจพบบั๊กและรับรู้การแก้ไข กับโค้ดเวอร์ชันที่แพตช์แล้วของ FreeBSD
  • ทุกโมเดลตรวจพบบั๊กที่ยังไม่แพตช์ได้ แต่ หลังแพตช์แล้วกลับเกิด false positive จำนวนมากในโค้ด
  • มีเพียง GPT-OSS-120b เท่านั้นที่ถูกต้องทั้งสองทิศทาง
  • โมเดลส่วนใหญ่กล่าวอ้างช่องโหว่ผิดพลาดจากการตีความเครื่องหมายของ oa_length ผิด
• สิ่งนี้แสดงให้เห็นว่า ความไว (พลังในการตรวจจับ) สูง แต่ ความจำเพาะ (ความแม่นยำ) ต่ำ และย้ำว่า
  ระบบตรวจสอบและ triage ภายนอกโมเดลเป็นสิ่งจำเป็น

ขอบเขตของการประกอบ exploit

• กรณีอย่าง การหลบหนี browser sandbox แบบหลายขั้น และ kernel ROP chain ของ Mythos เป็นตัวอย่างที่ล้ำหน้ามาก
• โมเดลเปิดสามารถอธิบาย ความเป็นไปได้ของ exploit, เทคนิค, และกลยุทธ์การหลบหลีก ได้อย่างมีเหตุผล แต่
  กลไกการส่งมอบที่สร้างสรรค์ภายใต้สภาพแวดล้อมจำกัด ยังไม่ดีพอ
• อย่างไรก็ตาม ใน workflow เชิงป้องกัน ความน่าเชื่อถือของ การตรวจจับและการแพตช์ สำคัญกว่าการมี exploit ที่สมบูรณ์

มุมมองมหภาค

• การประกาศ Mythos พิสูจน์ให้เห็นถึง ความเป็นจริงและความสำคัญเชิงอุตสาหกรรมของ AI security
  • เงินทุนและความสนใจต่อความปลอดภัยโอเพนซอร์สเพิ่มขึ้น
• แต่คำกล่าวที่ว่า “ความสามารถนี้มีอยู่เฉพาะในโมเดลปิดบางตัวเท่านั้น” เป็นการพูดเกินจริง
  • ในทางปฏิบัติ ขั้นตอนการตรวจจับและวิเคราะห์เข้าถึงได้อย่างกว้างขวางแล้ว
  • ความเชี่ยวชาญด้านความปลอดภัย, การออกแบบระบบ, และการสร้างความเชื่อมั่น คือคอขวดที่แท้จริง

• สิ่งที่ต้องการตอนนี้ไม่ใช่โมเดล แต่คือการสร้างระบบ

  • scaffold, pipeline, ระบบความร่วมมือ, การบูรณาการกับ development workflow
  • โมเดลพร้อมใช้งานเพียงพอแล้ว

ข้อจำกัดและข้อควรระวัง

• ขอบเขตการทดสอบจำกัด: มีการให้ฟังก์ชันที่เปราะบางและ hint แก่โมเดลโดยตรง ไม่ใช่การสำรวจอัตโนมัติแบบเต็มรูปแบบ
• ไม่มีการเข้าถึงเครื่องมือ: ไม่ได้ใช้การรันโค้ด, ลูป, หรือสภาพแวดล้อม sandbox
• สะท้อนการอัปเดตของโมเดล: โมเดล Anthropic รุ่นใหม่บางตัวได้รับการปรับปรุงในภายหลัง
• ทำให้ขอบเขตของข้ออ้างชัดเจน: ไม่ได้ปฏิเสธความสามารถของ Mythos แต่ชี้ว่า
  การผูกขาดความสามารถในการตรวจจับนั้นถูกพูดเกินจริง

สรุปภาคผนวก

• อ้างอิงการตรวจหา FreeBSD

  • Kimi K2: “oa_length ถูกคัดลอกโดยไม่มีการตรวจสอบ จึงอาจเกิดโอเวอร์โฟลว์ได้”
  • Gemma 4: “อาจเกินบัฟเฟอร์สแตก 128 ไบต์”

• ตารางเปรียบเทียบประสิทธิภาพตามงาน

  • การตรวจหา FreeBSD สำเร็จทุกโมเดล, OpenBSD สำเร็จเพียงบางโมเดล, OWASP โมเดลเล็กเหนือกว่า

• การทดสอบโค้ดที่แพตช์แล้ว

  • โมเดลส่วนใหญ่เกิด false positive จากข้อผิดพลาดเรื่องเครื่องหมายของ oa_length
  • มีเพียง GPT-OSS-120b ที่ถูกต้องสมบูรณ์
  • สรุป:
  • ความสามารถในการแข่งขันหลักของ AI security ไม่ได้อยู่ที่ ขนาดหรือความเป็นกรรมสิทธิ์ของโมเดล แต่
  • อยู่ที่ การออกแบบระบบที่ฝังความรู้ผู้เชี่ยวชาญและโครงสร้างการปฏิบัติการที่เชื่อถือได้
  • แม้แต่โมเดลขนาดเล็กก็ทรงพลังเพียงพอ และตอนนี้ก็ถึงขั้นที่สามารถสร้าง ระบบป้องกันอัตโนมัติขนาดใหญ่ โดยใช้โมเดลเหล่านี้ได้แล้ว

[GN⁺]

ความคิดเห็นใน Hacker News

• จากบทความ Mythos Preview ของ Anthropic ระบุว่าพบ ช่องโหว่ร้ายแรงที่สุด ใน OpenBSD
  ค่าใช้จ่ายรวมสำหรับการรันหนึ่งพันครั้งต่ำกว่า 20,000 ดอลลาร์ และมีการรันครั้งหนึ่งที่พบบั๊กได้ด้วยค่าใช้จ่ายต่ำกว่า 50 ดอลลาร์
  แต่ก็เน้นว่านี่เป็นตัวเลขที่มีความหมายเฉพาะเมื่อมองย้อนหลังเท่านั้น เพราะในความเป็นจริงไม่สามารถรู้ได้ว่าการรันครั้งไหนจะสำเร็จ
  มีการเปรียบเทียบว่า Mythos ค้นทั้งทวีปเหมือนร่อนหาทอง และคาดว่าถ้าทดลองแบบเดียวกันกับโค้ดเบสทั้งหมดของ FreeBSD ก็จะ มีสัญญาณรบกวนมากเกินไป

  • scaffolding ของ Mythos แทบจะเป็นการวนดูทุกไฟล์ด้วยลูป bash แล้วให้โมเดลหาช่องโหว่
    เลยสงสัยว่า Anthropic เปิดเผย อัตรา false positive หรือไม่
    เห็นใน Xitter ว่ามีคนทดลองด้วยโมเดลเปิดตัวอื่น ๆ แล้วทำซ้ำได้เพียงบางส่วนของสิ่งที่ Mythos พบ
    คิดว่า Mythos แสดงให้เห็นถึง การพัฒนาแบบค่อยเป็นค่อยไปแต่สำคัญ เมื่อเทียบกับโมเดลก่อนหน้า และในขณะเดียวกันก็ซับซ้อนขึ้นด้วย
    การตลาดแบบ “ทรงพลังเกินกว่าจะเผยแพร่” ดูเหมือนเป็นการห่อหุ้มความจริงที่ว่า “ถ้ารันกับทั้งโค้ดเบสจะเสีย 20,000 ดอลลาร์”
    ในงานบรรยายของ Nicholas Carlini ก็ใช้ Opus เช่นกัน และด้านความปลอดภัยก็เป็นพื้นที่ที่ Anthropic โฟกัสมานานแล้ว
  • Mythos ก็สร้าง ช่องโหว่มั่ว ๆ ออกมาจำนวนมากเช่นกัน แต่บางส่วนได้รับการตรวจยืนยันผ่านการทดสอบจริง
    ประเด็นสำคัญคือโมเดลเล็ก ๆ จะทำขั้นตอนตรวจยืนยันแบบนี้ได้หรือไม่ และจะทำได้ในต้นทุนที่ถูกกว่าหรือไม่
  • ในทางกลับกัน มีคนมองว่างานวิจัยอื่นใช้วิธีที่สุดโต่งเกินไป
    พวกเขาแยกเฉพาะฟังก์ชันที่มีช่องโหว่ออกมาให้โมเดลประเมิน ซึ่งก็เหมือนกับ “บอกห้องที่ซ่อนทองไว้โดยตรง”
    ในความเป็นจริง ส่วนที่ยากกว่าคือการหาห้องนั้นให้เจอจากทั้งทวีป
  • การใช้เงิน 20,000 ดอลลาร์เพื่อหาช่องโหว่ DoS หนึ่งจุดใน OpenBSD ให้ความรู้สึกว่าไม่มีประสิทธิภาพ
    บรรยากาศเหมือน Mythos ถูกปฏิบัติเหมือนถ้วยรางวัล แต่คิดว่าบริจาคให้มูลนิธิ OpenBSD ยังจะดีกว่า
  • ถ้าโมเดลเล็กสามารถหาช่องโหว่เดียวกันได้ ก็ทำให้สงสัยว่าทำไมบริษัทนั้นถึงหาไม่เจอตั้งแต่แรก

• มีงานวิจัยที่ระบุว่าโมเดลเปิดขนาดเล็กสามารถตรวจจับช่องโหว่ FreeBSD ของ Mythos ได้ครบ 8 จาก 8 จุด
  แต่เพราะพวกเขา แยกเฉพาะโค้ดที่เกี่ยวข้องออกมา เพื่อทดสอบ จึงคิดว่ามันต่างจากกรณีใช้งานจริง
  คุณค่าที่แท้จริงคือความสามารถในการโยนทั้งโค้ดเบสเข้าไปแล้วสแกนได้

  • ทีมวิจัยก็ยอมรับข้อจำกัดนี้ด้วยตัวเอง
    เพราะพวกเขาให้ทั้งฟังก์ชันที่มีช่องโหว่และคำใบ้แก่โมเดลโดยตรง จึงเป็นเพียง ขีดบนสุด ของการค้นหาแบบอัตโนมัติเต็มรูปแบบเท่านั้น
    อย่างไรก็ตาม scaffolding ที่ออกแบบดีสามารถสร้างบริบทแบบนี้ขึ้นมาได้เองโดยอัตโนมัติ ดังนั้น หัวใจอยู่ที่ระบบ (moat) ไม่ใช่ตัวโมเดล
  • ตามโพสต์เทคนิคของ Anthropic โครงสร้างคือเปิดคอนเทนเนอร์ ให้โมเดลสแกนไฟล์ ตั้งสมมติฐาน และตรวจยืนยันด้วย ASan
    กล่าวคือ เฟรมเวิร์ก (harness) เป็นฝ่ายทำงานส่วนใหญ่ และโมเดลสามารถสลับเปลี่ยนได้
  • แม้ใช้โมเดลเล็กก็สร้าง automatic harness ที่คอยยิงพรอมป์ต์แบบวนซ้ำในระดับไฟล์หรือฟังก์ชันทั้งหมดได้
    จากนั้นค่อยใช้โมเดลใหญ่ตรวจยืนยันซ้ำเฉพาะส่วนที่ถูกชี้ว่ามีช่องโหว่อย่างสม่ำเสมอ
    สุดท้ายแล้วสิ่งสำคัญคือ harness ไม่ใช่โมเดล
  • สุดท้ายความต่างก็มีแค่ harness เท่านั้น ฉันเองก็สามารถสร้าง harness ที่แยกโค้ดเป็นระดับฟังก์ชันแล้วป้อนเข้า agent วิเคราะห์ได้

• เหมือนตัวอย่าง Heartbleed, ถ้าแสดงเฉพาะโค้ดที่มีช่องโหว่ให้ดู ใคร ๆ ก็หาบั๊กเจอได้
  แต่การหาส่วนนั้นให้เจอในโค้ดขนาดใหญ่ต่างหากคือเรื่องยากจริง
  เลยแปลกใจที่ Aisle เขียนบทความแบบนี้

  • แม้จะเป็นบทความเชิงโฆษณา แต่ที่ขึ้นไปอยู่บน HN ด้านบนได้ น่าจะเพราะมันกระตุ้นความรู้สึกของคนว่า “โมเดลใหม่ก็ไม่ได้พิเศษอะไรนี่”
  • เวลาทำโปรเจ็กต์ใหญ่ ๆ พอกลับมาดูหลังพักไปสักช่วง ก็มักรู้สึกว่าแม้แต่โค้ดที่ตัวเองเขียนก็ยังดูเละเทะ
    ความยากในการรักษาบริบท เป็นหนึ่งในต้นตอของบั๊ก
  • มนุษย์ไม่เก่งงานที่ซ้ำซากและต้องละเอียดมาก
    ในขณะที่เครื่องจักรสามารถไล่อ่านโค้ดต่อไปได้โดยไม่เบื่อ
    คำกล่าวที่ว่า “ถ้ามีสายตามากพอ บั๊กทุกตัวก็จะตื้น” ไม่ตรงกับความจริง
  • ถ้าอย่างนั้นก็ทำให้กระบวนการ “ดูใกล้ ๆ” เป็นอัตโนมัติไปเลย
    สามารถสร้างเครื่องมือที่ไล่ดูโค้ดเบสและพรอมป์ต์ LLM ซ้ำ ๆ ว่า “ถ้าโค้ดนี้มีช่องโหว่ ก็จงหามันให้เจอ”
    กล่าวคือ เครื่องมือ (harness) คือกุญแจที่ทำให้ LLM ฉลาดขึ้น
  • นี่เหมือนการสับสนระหว่างการแก้ปัญหากับการตรวจยืนยัน
    เป็นอุปมาทำนองว่า “ถ้ามีคนบอกวิธีแยกตัวประกอบให้แล้ว การเจาะ PKI ก็เป็นเรื่องง่าย”

• คิดว่าวิธีวิทยาในบทความนี้เป็นการ เปรียบเทียบที่ผิดอย่างสิ้นเชิง
  การให้ทั้งฟังก์ชันที่มีช่องโหว่และคำใบ้โดยตรงเป็นงานคนละแบบกันเลย
  ในความเป็นจริง ต่อให้แบ่งโค้ดออกเป็นชิ้น ๆ แล้วโยนให้โมเดลเล็ก ก็ยากจะได้ผลลัพธ์ระดับโมเดลใหญ่
  ฉันเคยพบบั๊กใน Redis ได้จำนวนมากด้วย pipeline เชลล์สคริปต์ง่าย ๆ
  แต่โมเดลที่อ่อนกว่านั้นทำไม่ได้ ถ้าลองเองจะเห็นความต่าง
  อีกทั้งถึงโมเดลเล็กจะหาได้ 80% ก็ยังต้องมี โมเดลที่แข็งแกร่งกว่า เพื่อหาที่เหลืออีก 20%

  • Anthropic ก็ระบุว่าเปิดเผยช่องโหว่ที่พวกเขาพบออกมาไม่ถึง 1%
    น่าจะดีถ้าลองให้โมเดลเปิดทำงานกับสภาพแวดล้อม Linux เวอร์ชันเก่า แล้วดูว่าหาเจอได้มากแค่ไหน
  • แต่อีกคนมองว่าวิธีนี้สมเหตุสมผล
    โมเดลเล็กกรอง false positive ได้ดี และถ้าใช้ harness ที่เหมาะสม ก็ให้ผลลัพธ์ใกล้เคียงโมเดลใหญ่ได้
    โมเดลเล็กนั้นเร็วและถูกกว่า ดังนั้นถ้าผู้ใช้มีความชำนาญก็จะมีประสิทธิภาพกว่ามาก
    คิดว่าในอนาคต การผสมโมเดลเบา + harness แบบนี้จะกลายเป็นกระแสหลัก
  • มีคนตอบเชิงเสียดสีว่า “Thanks Dario, very cool!”

• หลายคอมเมนต์บอกว่า “พอแยกโค้ดออกมาก็ถือว่าใช้ไม่ได้แล้ว” แต่ Anthropic เองก็รันโมเดลแบบเดียวกันในระดับไฟล์
  harness ของ Mythos มีโครงสร้างที่ให้ คะแนนความสำคัญ กับแต่ละไฟล์ แล้วสร้าง Claude Code instance เพื่อโฟกัสที่ไฟล์นั้น
  ดังนั้นการแยกโค้ดออกมาเองไม่ได้ทำให้ผลลัพธ์เป็นโมฆะ

• ในวิดีโอบรรยาย ของ Nicholas Carlini ก็แนะนำเทคนิคเดียวกัน
  การให้ LLM รีวิวทีละไฟล์อย่างเข้มข้นมีประสิทธิภาพสูง
  “นวัตกรรม” ของ Mythos แท้จริงแล้วคือการ ทำอัตโนมัติของการพรอมป์ต์รายไฟล์ แบบเรียบง่ายนี้
  และวิธีนี้เองอาจเป็นเหตุผลที่ต้นทุนพุ่งไปถึง 20,000 ดอลลาร์
  ฉันเองก็ลองใช้วิธีเดียวกันกับ Opus 4.6 และ GPT 5.4 แล้ว พบว่าตรวจละเอียดกว่ามาก
  กล่าวคือ ถ้าให้หนึ่งเซสชันโฟกัสกับหนึ่งไฟล์ โมเดลจะวิเคราะห์ได้ลึกกว่ามาก

  • แต่ถ้าทำแบบนี้ ก็อาจพลาดช่องโหว่ที่เกิดจาก ปฏิสัมพันธ์ระหว่างไฟล์ ได้

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

• ถ้าไม่เปิดเผย อัตรา false positive การวิเคราะห์ก็ไร้ความหมาย
  ถ้าบอกว่าทุกบรรทัดมีบั๊กก็จะได้อัตราตรวจจับ 100% แต่ไม่มีประโยชน์
  ทั้ง Anthropic และ OpenAI ก็ไม่เปิดเผยตัวเลขแบบนี้ จึงยากจะเชื่อถือ

  • แต่ก็มีข้อโต้แย้งว่าถ้ามี oracle ที่ตรวจยืนยันได้ false positive ก็อาจมองข้ามได้
  • ในการทดสอบ false positive จริง ๆ โมเดลเล็กตอบถูก แต่ Opus ตอบผิด
    เพียงแต่ยังไปไม่ถึงระดับ การตรวจยืนยัน exploit แบบ Mythos
    ผลของ Deepseek R1 ค่อนข้างน่าเชื่อถือ แต่ก็ไม่ชัดเจนว่ามันทำงานได้จริงหรือไม่
  • อย่างน้อยต้องทำ coverage แบบเดียวกับที่ Anthropic ได้ให้สำเร็จก่อน จึงจะมีความหมาย

• ประเด็นสำคัญคือการ แยกโค้ดที่เกี่ยวข้องออกมา
  zero-day ที่ซับซ้อนมักเกิดจากปฏิสัมพันธ์ระหว่างหลายไฟล์ ดังนั้นแนวทางนี้จึงมีข้อจำกัด

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

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

  • บางคนเปรียบเทียบต่อว่าเหมือนเอากลิ่นไปติดที่ลูกบอล ให้สุนัขดมกลิ่นนั้นก่อน แล้วค่อยปล่อยในพื้นที่แคบ ๆ
  • เนื่องจาก Mythos ไม่สามารถใส่ทั้งโค้ดทั้งหมดเข้าไปพร้อมกันได้ จึงมีความเป็นไปได้สูงว่ามี sub-agent หลายตัวช่วยกันแบ่งงาน
    สุดท้ายสิ่งสำคัญจึงไม่ใช่โมเดล แต่เป็น harness (ระบบเครื่องมือ)