Project Glasswing: สิ่งที่ Mythos แสดงให้เห็น

• Mythos Preview ไม่ได้หยุดแค่การตรวจจับบั๊กรายตัวในคลังเก็บมากกว่า 50 แห่งของ Cloudflare แต่เชื่อมองค์ประกอบดั้งเดิมหลายอย่างเข้าด้วยกันเพื่อสร้าง exploit chain
• มันไม่ได้แค่ตรวจพบบั๊กต้องสงสัย แต่ยังเขียนโค้ดทริกเกอร์ คอมไพล์และรันชั่วคราว แล้วปรับสมมติฐานหลังความล้มเหลวซ้ำไปมาเพื่อสร้าง หลักฐานการทำงานจริง
• แม้ในการวิจัยช่องโหว่ที่ชอบธรรมก็ยังเกิดการปฏิเสธโดยสมัครใจ แต่ผลลัพธ์เปลี่ยนไปตามบริบทและการใช้ถ้อยคำ จึงยังขาดความสม่ำเสมอพอจะใช้เป็น ขอบเขตความปลอดภัย
• เอเจนต์เขียนโค้ดแบบอเนกประสงค์มีข้อจำกัดทั้งด้านการครอบคลุมคลังเก็บขนาดใหญ่และการสำรวจแบบขนาน ทำให้ Cloudflare สร้าง harness สำหรับรันงานแคบ ๆ แบบขนาน
• สำหรับทีมความปลอดภัย การสแกนและแพตช์ให้เร็วขึ้นอย่างเดียวไม่พออีกต่อไป แต่ สถาปัตยกรรม ที่ทำให้แม้มีบั๊กก็ยังเข้าถึงหรือใช้ประโยชน์ได้ยาก กลายเป็นสิ่งสำคัญมากขึ้น

---

วิธีที่ Mythos Preview เปลี่ยนแนวทางการวิจัยช่องโหว่

• ในช่วงไม่กี่เดือนที่ผ่านมา Cloudflare ได้ทดสอบ LLM ที่เน้นด้านความปลอดภัยบนโครงสร้างพื้นฐานของตนเอง และได้นำ Mythos Preview ของ Anthropic มาใช้เป็นส่วนหนึ่งของ Project Glasswing กับคลังเก็บภายในมากกว่า 50 แห่ง
• Mythos Preview ไม่ได้เป็นเพียงรุ่นปรับปรุงของ frontier model แบบอเนกประสงค์ที่มีอยู่เดิม แต่ใกล้เคียงกับการเป็น เครื่องมือใหม่ สำหรับทำงานในแต่ละขั้นของการวิจัยช่องโหว่มากกว่า
• การเปลี่ยนแปลงสำคัญคือมันไม่ได้จบแค่การลิสต์บั๊กเป็นรายตัว แต่สามารถรวมองค์ประกอบดั้งเดิมของการโจมตีหลายอย่างเข้าด้วยกันเพื่อสร้าง exploit chain
  • การโจมตีจริงมักไม่ได้ใช้บั๊กเพียงตัวเดียว แต่จะต่อเนื่องจากการเปลี่ยน use-after-free ให้เป็นองค์ประกอบสำหรับการอ่าน-เขียนตามอำเภอใจ ยึดการควบคุมการไหลของโปรแกรม และใช้ ROP chain เพื่อเข้าควบคุมระบบ
  • Mythos Preview สามารถผสานองค์ประกอบเหล่านี้และเชื่อมต่อไปสู่หลักฐานที่ใช้งานได้จริง โดยให้เหตุผลใกล้เคียงกับนักวิจัยที่ชำนาญ มากกว่าตัวสแกนอัตโนมัติทั่วไป
• การเปลี่ยนแปลงอีกอย่างคือความสามารถในการสร้าง หลักฐานการทำงานจริง ได้ด้วยตัวเองหลังจากพบบั๊กที่น่าสงสัย
  • มันเขียนโค้ดทริกเกอร์ คอมไพล์ในสภาพแวดล้อมชั่วคราว แล้วรัน
  • หากทำงานตามคาดก็กลายเป็นหลักฐานยืนยัน แต่ถ้าล้มเหลว มันจะอ่านผลล้มเหลว ปรับสมมติฐาน แล้วลองใหม่
  • ข้อบกพร่องที่ไม่มีหลักฐานการทำงานจริงมักยังเป็นเพียงการคาดเดา แต่ Mythos Preview สามารถลดช่องว่างนี้ได้ด้วยตัวเอง
• ใน harness เดียวกัน frontier model ตัวอื่นก็พบบั๊กพื้นฐานบางส่วน และบางครั้งให้เหตุผลได้ไกลกว่าที่คาด แต่ต่างกันชัดเจนในขั้นตอนการประกอบชิ้นส่วนหลายอย่างให้กลายเป็น chain ที่ใช้งานได้จริง
• Mythos Preview สามารถเชื่อมบั๊กที่ตามปกติอาจค้างอยู่ใน backlog ด้วยระดับความรุนแรงต่ำ ให้กลายเป็น exploit ที่มีความรุนแรงสูงกว่าได้

การปฏิเสธของโมเดลที่เกิดขึ้นแม้ในการวิจัยช่องโหว่ที่ชอบธรรม

• Mythos Preview ที่ให้ใช้ใน Project Glasswing ไม่มีมาตรการความปลอดภัยเพิ่มเติมแบบเดียวกับโมเดลที่เปิดให้ใช้ทั่วไปอย่าง Opus 4.7 หรือ GPT-5.5
• ถึงอย่างนั้น โมเดลก็ยังแสดงการต่อต้านต่อคำขอบางประเภทด้วยตัวเอง และเผยให้เห็นทั้งความสามารถด้านไซเบอร์ที่มีประโยชน์ต่อการค้นหาช่องโหว่ และ guardrail ที่เกิดขึ้นเอง
• การปฏิเสธโดยสมัครใจนี้ไม่ได้สม่ำเสมอ
  • แม้เป็นงานเดียวกัน แต่ถ้าเปลี่ยนวิธีเขียนหรือบริบท ผลลัพธ์อาจต่างกันอย่างสิ้นเชิง
  • เคยมีกรณีที่มันปฏิเสธการวิจัยช่องโหว่ในโปรเจ็กต์หนึ่งในตอนแรก แต่ยอมรับการวิจัยเดียวกันกับโค้ดเดียวกันหลังมีการเปลี่ยนแปลงในสภาพแวดล้อมของโปรเจ็กต์ที่ไม่เกี่ยวข้อง
  • บางครั้งหลังจากค้นหาและยืนยันบั๊กหน่วยความจำร้ายแรงหลายจุดใน codebase ได้แล้ว มันกลับปฏิเสธที่จะเขียน demo exploit
  • แม้เป็นคำขอเดียวกัน ผลลัพธ์ก็อาจต่างกันในแต่ละครั้งเพราะธรรมชาติแบบ stochastic ของโมเดล
• การปฏิเสธโดยสมัครใจและ guardrail มีอยู่จริง แต่ยังไม่สม่ำเสมอพอจะนับเป็น ขอบเขตความปลอดภัย ที่สมบูรณ์ได้ด้วยตัวมันเอง
• หากจะเปิดให้ใช้ cyber frontier model ที่มีความสามารถสูงในวงกว้าง ยังจำเป็นต้องมีมาตรการความปลอดภัยเพิ่มเติมเพื่อให้ใช้งานได้อย่างเหมาะสมนอกสภาพแวดล้อมวิจัยที่ควบคุมแบบ Project Glasswing

ปัญหาเรื่องสัญญาณกับสัญญาณรบกวน

• ในการคัดกรองช่องโหว่ด้านความปลอดภัย งานที่ยากที่สุดคือการตัดสินว่าบั๊กไหนมีอยู่จริง ใช้ประโยชน์ได้จริง และควรแก้ตอนนี้
• ปัญหานี้ยากอยู่แล้วก่อนมี AI และยิ่งแย่ลงจากทั้งตัวสแกนช่องโหว่แบบ AI และโค้ดที่ AI สร้างขึ้น ทำให้ Cloudflare ต้องสร้างหลายขั้นตอนของ การตรวจสอบภายหลัง

• ภาษาโปรแกรม

  • C และ C++ ให้การควบคุมหน่วยความจำโดยตรง และก่อให้เกิดบั๊กหลายประเภท เช่น buffer overflow และการอ่าน-เขียนนอกขอบเขต
  • ภาษาแบบ memory-safe อย่าง Rust กำจัดบั๊กประเภทนี้ตั้งแต่ขั้นคอมไพล์
  • ในโปรเจ็กต์ที่เขียนด้วยภาษาที่ไม่ memory-safe พบ false positive มากกว่าอย่างสม่ำเสมอ

• อคติของโมเดล

  • นักวิจัยมนุษย์ที่ดีจะบอกได้ว่าพบอะไรและมั่นใจแค่ไหน แต่โมเดลมีแนวโน้มจะสร้างผลลัพธ์ออกมาไม่ว่าในโค้ดจะมีบั๊กจริงหรือไม่
  • ผลลัพธ์มักถูกทำให้อ่อนลงด้วยคำอย่าง “possibly”, “potentially”, “could in theory” และ ผลลัพธ์เชิงคาดเดา เหล่านี้มีมากกว่าผลลัพธ์ที่ชัดเจนมาก
  • นี่เป็นอคติที่สมเหตุสมผลสำหรับเครื่องมือสำรวจ แต่ในคิวคัดกรอง ผลลัพธ์เชิงคาดเดาทุกชิ้นจะกินทั้งความสนใจของคนและโทเค็น และเมื่อสะสมเป็นหลักพันก็มีต้นทุนสูง
  • Mythos Preview แสดงการปรับปรุงอย่างชัดเจนในความสามารถด้าน การเชื่อมองค์ประกอบดั้งเดิม ให้เป็น PoC ที่ทำงานได้ แทนที่จะรายงานช่องโหว่หลายรายการแยกกัน
  • ผลลัพธ์ที่มี PoC แนบมาจะใกล้เคียงกับสิ่งที่นำไปจัดการได้ทันที และช่วยลดเวลาในการตรวจว่า “นี่เป็นของจริงหรือไม่” อย่างมาก
  • harness ของ Cloudflare ถูกจูนโดยตั้งใจให้รายงานมากขึ้นเพื่อพลาดให้น้อยลง จึงมีสัญญาณรบกวนมาก แต่ผลลัพธ์จาก Mythos Preview มีถ้อยคำที่ลดทอนน้อยกว่าและขั้นตอนการทำซ้ำชัดเจนกว่า ทำให้งานที่ต้องใช้เพื่อตัดสินใจแก้ไขหรือปัดตกน้อยลง

ข้อจำกัดของการนำเอเจนต์เขียนโค้ดแบบอเนกประสงค์ไปใช้กับคลังเก็บโดยตรง

• ในช่วงแรกของการวิจัยช่องโหว่ด้วย AI การให้เอเจนต์เขียนโค้ดแบบอเนกประสงค์รับคลังเก็บใด ๆ แล้วให้มันค้นหาช่องโหว่ เป็นจุดเริ่มต้นที่ดูเป็นธรรมชาติ
• วิธีนี้สร้างผลลัพธ์ได้ แต่ไม่เหมาะกับการครอบคลุม codebase จริงอย่างมีนัยสำคัญและค้นหาผลลัพธ์ที่มีคุณค่า

• บริบท

  • เอเจนต์เขียนโค้ดถูกออกแบบมาสำหรับเวิร์กโฟลว์งานเดียวที่มีจุดโฟกัส เช่น การพัฒนาฟีเจอร์ การแก้บั๊ก หรือการรีแฟกเตอร์
  • การวิจัยช่องโหว่ใกล้เคียงกับ งานแคบและทำแบบขนาน ที่เจาะลึกเป้าหมายเฉพาะ เช่น ฟังก์ชันซับซ้อนเดี่ยว การเปลี่ยนผ่านขอบเขตความปลอดภัย หรือ command injection แล้วทำซ้ำหลายพันครั้งทั่วทั้ง codebase
  • แม้จะใช้ sub-agent แต่เซสชันเอเจนต์เดี่ยวกับคลังเก็บขนาด 100,000 บรรทัด ก็อาจครอบคลุมพื้นผิวได้เพียงราว 0.1% ในรูปแบบที่ยังมีประโยชน์ ก่อนหน้าต่างบริบทของโมเดลจะเต็มและเริ่มบีบอัด
  • ระหว่างกระบวนการบีบอัดนั้น ผลลัพธ์ก่อนหน้าที่อาจสำคัญก็มีโอกาสถูกทิ้งไป

• ปริมาณงาน

  • เอเจนต์แบบสตรีมเดี่ยวทำงานได้ทีละงานเท่านั้น
  • codebase จริงต้องการความสามารถในการทดลองสมมติฐานจำนวนมากกับหลายองค์ประกอบพร้อมกัน และแตกแขนงออกกว้างขึ้นเมื่อเจอจุดที่น่าสนใจ
  • เมื่อผู้วิจัยมีเบาะแสอยู่แล้วและต้องการผู้ตรวจทานรอบสอง เอเจนต์เขียนโค้ดเหมาะกับการสืบค้นแบบแมนนวล
  • แต่ไม่เหมาะในฐานะเครื่องมือเพื่อให้ได้การครอบคลุมสูง ทำให้ Cloudflare เปลี่ยนไปสร้าง harness รอบ Mythos Preview แทน

ปัญหาที่ harness ช่วยแก้

• ประสบการณ์จากการรันในวงกว้างนำไปสู่ข้อสรุปว่าจำเป็นต้องมี harness สำหรับจัดการการทำงานทั้งหมด

• ขอบเขตที่แคบกว่าให้ผลลัพธ์ดีกว่า

  • คำขออย่าง “หาช่องโหว่ในคลังเก็บนี้” จะทำให้โมเดลหลงทาง
  • คำขอแบบ “ดู command injection ในฟังก์ชันนี้โดยเฉพาะ ด้านบนมี trust boundary นี้ นี่คือเอกสารสถาปัตยกรรม และนี่คือการครอบคลุมเดิมในบริเวณนี้” ให้ผลลัพธ์ที่ใกล้เคียงกับวิธีทำงานของนักวิจัยจริงมากกว่า

• การตรวจทานเชิงปฏิปักษ์ช่วยลดสัญญาณรบกวน

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

• แยก chain ตามเอเจนต์แล้วการให้เหตุผลดีขึ้น

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

• งานแคบแบบขนานชนะเอเจนต์ตัวเดียวที่ครอบคลุมทุกอย่าง

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

harness สำหรับค้นหาช่องโหว่ของ Cloudflare

• harness นี้ถูกใช้เพื่อสแกนโค้ดจริงของ runtime ของ Cloudflare, edge data path, protocol stack, control plane และโปรเจ็กต์โอเพนซอร์สที่พึ่งพา

• Recon

  • เอเจนต์จะอ่านคลังเก็บจากด้านบนลงมา แล้วแตกแขนงเป็น sub-agent ที่รับผิดชอบแต่ละ subsystem
  • มันสร้าง เอกสารสถาปัตยกรรม ที่รวมคำสั่ง build, trust boundary, entry point และ attack surface ที่คาดไว้
  • มันยังสร้างคิวงานเริ่มต้นสำหรับส่งต่อไปยังขั้นถัดไป และให้บริบทร่วมกับเอเจนต์ทั้งหมดที่ตามมาเพื่อลดปัญหาโมเดลหลงทาง

• Hunt

  • แต่ละงานประกอบด้วยประเภทการโจมตีหนึ่งแบบและคำใบ้ด้านขอบเขต
  • hunter agent ที่ทำหน้าที่ค้นหาบั๊กจริงมักรันพร้อมกันราว 50 ตัว และแต่ละตัวก็แตกต่อเป็น sub-agent สำหรับการสำรวจอีกไม่กี่ตัว
  • hunter แต่ละตัวเข้าถึงเครื่องมือสำหรับคอมไพล์และรันโค้ด PoC ในไดเรกทอรีชั่วคราวเฉพาะงาน
  • งานส่วนใหญ่เกิดจากการรันแบบขนานของงานแคบจำนวนมาก ไม่ใช่เอเจนต์ตัวเดียวที่ครอบคลุมทุกอย่าง

• Validate

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

• Gapfill

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

• Dedupe

  • ผลลัพธ์ที่มีรากเหตุเดียวกันจะถูกรวมเป็นเรกคอร์ดเดียว
  • การวิเคราะห์ตัวแปรเป็นฟีเจอร์ ไม่ใช่วิธีทำให้คิวพองด้วยข้อมูลซ้ำ

• Trace

  • สำหรับผลลัพธ์แต่ละรายการที่ยืนยันแล้วใน shared library tracer agent จะถูกแตกออกทีละตัวตาม consumer repository
  • มันใช้ดัชนีสัญลักษณ์ข้ามคลังเก็บเพื่อพิจารณาว่าอินพุตที่ผู้โจมตีควบคุมได้สามารถไปถึงบั๊กนั้นจากภายนอกระบบจริงหรือไม่
  • นี่คือขั้นตอนที่สำคัญที่สุดในการเปลี่ยนจาก “มีข้อบกพร่อง” ไปเป็น “มีช่องโหว่ที่เข้าถึงได้จริง”

• Feedback

  • ผลการ trace ที่เข้าถึงได้จริงจะกลายเป็นงาน hunt ใหม่ใน consumer repository ที่เปิดเผยบั๊กนั้นจริง
  • นี่เป็นการปิดลูปที่ทำให้ pipeline ดีขึ้นเรื่อย ๆ ทุกครั้งที่รัน

• Report

  • เอเจนต์จะเขียนรายงานแบบมีโครงสร้างตาม schema ที่กำหนดไว้ล่วงหน้า
  • มันแก้ข้อผิดพลาดจากการตรวจสอบ schema ได้ด้วยตัวเอง และส่งผ่าน ingest API
  • ผลลัพธ์ที่ได้จึงไม่ใช่ร้อยแก้วอิสระ แต่เป็น ข้อมูลที่นำไป query ได้

ความหมายต่อทีมความปลอดภัย

• ผู้นำด้านความปลอดภัยรายอื่นที่ได้เห็น Mythos Preview พยายามบีบวงรอบการตอบสนองด้วยการสแกนให้เร็วขึ้นและแพตช์ให้เร็วขึ้น
• อย่างน้อยหนึ่งทีมที่ Cloudflare ได้พูดคุยด้วย ดำเนินงานด้วย SLA 2 ชั่วโมง ตั้งแต่การเปิดเผย CVE จนถึงการแพตช์ใน production
• เมื่อไทม์ไลน์ของผู้โจมตีสั้นลง ไทม์ไลน์ของผู้ป้องกันก็ต้องสั้นลงเช่นกัน แต่ความเร็วเพียงอย่างเดียวยังไม่พอ
• การแพตช์ให้เร็วขึ้นไม่ได้เปลี่ยนรูปร่างของ pipeline ที่ใช้สร้างแพตช์
  • ถ้าการทดสอบ regression ใช้เวลาทั้งวัน ก็ไม่มีทางถึง SLA 2 ชั่วโมงได้โดยไม่ข้ามการทดสอบ regression
  • และบั๊กที่ปล่อยขึ้น production โดยข้าม regression test อาจแย่กว่าบั๊กเดิมที่ต้องการแก้เสียอีก
  • เมื่อให้โมเดลเขียนแพตช์โดยตรง เคยมีบางแพตช์ถูกนำไปปล่อยใช้งาน ทั้งที่แม้จะแก้บั๊กเดิมได้ แต่กลับทำให้ส่วนอื่นของโค้ดที่พึ่งพากันเสียหายแบบเงียบ ๆ
• คำถามที่ยากกว่าคือจะออกแบบสถาปัตยกรรมรอบช่องโหว่อย่างไร
  • ต้องทำให้แม้บั๊กจะมีอยู่ ผู้โจมตีก็ยังใช้ประโยชน์ได้ยาก
  • ต้องทำให้ช่วงเวลาระหว่างการเปิดเผยช่องโหว่กับการออกแพตช์มีความสำคัญน้อยลง
  • ต้องมีการป้องกันที่หน้าชั้นแอปพลิเคชันเพื่อบล็อกการเข้าถึงบั๊ก
  • ต้องออกแบบแอปพลิเคชันเพื่อไม่ให้ข้อบกพร่องในส่วนหนึ่งของโค้ดเปิดสิทธิ์ให้ผู้โจมตีเข้าถึงอีกส่วนหนึ่งได้
  • ต้องสามารถปล่อยการแก้ไขไปยังทุกตำแหน่งที่โค้ดถูกรันทันทีพร้อมกัน โดยไม่ต้องรอการ deploy ของแต่ละทีม
• ความสามารถแบบเดียวกันนี้มีสองด้าน
  • ความสามารถในการหาบั๊กในโค้ดของตัวเอง หากตกไปอยู่ในมือที่ไม่เหมาะสม ก็อาจเร่งการโจมตีต่อแอปพลิเคชันทั้งหมดบนอินเทอร์เน็ตได้เช่นกัน
  • Cloudflare ระบุว่าตนอยู่หน้าชั้นแอปพลิเคชันนับล้าน และหลักการด้านสถาปัตยกรรมข้างต้นก็คือหลักการที่ผลิตภัณฑ์ของตนถูกสร้างขึ้นมาเพื่อบังคับใช้แทนลูกค้า
• งานวิจัย Mythos Preview ดำเนินการในสภาพแวดล้อมที่ควบคุมได้กับโค้ดของ Cloudflare เอง และช่องโหว่ทั้งหมดที่พบถูกคัดกรอง ตรวจสอบ และแก้ไขตามความจำเป็น ตามกระบวนการจัดการช่องโหว่อย่างเป็นทางการของ Cloudflare

[crawler]

นึกว่าจะเป็นรายงานวิเคราะห์ว่าแก้บั๊กอะไรไปบ้างแบบ curl ที่ไหนได้เป็นแค่บทความโปรโมตล้วน ๆ สินะ?
Cloudflare เองก็มัวแต่ปั่นกระแสด้วยการทำ paywall สำหรับ AI agent โดยเฉพาะหรือไม่ก็ endpoint สำหรับสรุปเนื้อหา จนเริ่มเพี้ยนไปแล้ว

[GN⁺]

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

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

  • น่าจะหมายถึงว่ามันมีความสามารถที่ต่างออกไปในเชิงคุณภาพ จนทำให้งานด้านความปลอดภัยบางอย่างคุ้มค่าที่จะลองใช้โมเดลนี้ ไม่ได้หมายความว่า โมเดลปฏิสัมพันธ์ระหว่างมนุษย์กับ AI เปลี่ยนไป
    ก็ยังต้องใช้พร้อม harness เหมือนที่ทุกคนทำกันอยู่ และวิธีทั่วไปในการให้โมเดลมี harness ก็คงไม่ได้เปลี่ยนไปมากในอนาคต บางครั้งคนเองก็ต้องมี harness เพื่อจะทำงานบางอย่างเหมือนกัน
  • ฉันก็พยายามตีความแบบนี้เหมือนกัน
    ถ้ามองในแง่ดี อาจเป็นเพราะยังติด NDA เลยตั้งใจพูดให้คลุมเครือว่าอะไรต่างกันแน่
  • บอกว่า “แย่กว่าบล็อก Cloudflare ทั่วไปมาก” ก็ชวนสงสัยว่าไปหาค่าเฉลี่ยนั้นมาตอนไหน
    ช่วงนี้งานเขียนของ Cloudflare เกือบทั้งหมดมีกลิ่น AI แรงมาก
  • น่าจะฟังดูต่างออกไปเพราะมันไม่ใช่โพสต์บล็อกทั่วไป แต่เป็น โฆษณาแฝง
  • ตรงที่ว่า “มี guardrail ใหม่ในตัวโมเดลเอง ทำให้บางครั้งมันต่อต้านแม้แต่คำขอวิจัยด้านความปลอดภัยที่ถูกกฎหมาย แต่จากที่เราตรวจสอบ การปฏิเสธที่เกิดขึ้นเองตามธรรมชาติเหล่านี้ไม่ได้เกิดอย่างสม่ำเสมอ งานเดียวกันอาจให้ผลต่างกันอย่างสิ้นเชิงได้ หากเปลี่ยนถ้อยคำหรือบริบทที่ใช้เสนอ ดังตัวอย่างด้านล่าง” นั้นเป็นข้อมูลใหม่
    น่าแปลกที่โมเดลซึ่ง ออกแบบมาสำหรับการวิจัยด้านความปลอดภัย และเปิดให้เฉพาะผู้เชี่ยวชาญ กลับปฏิเสธคำขอที่ถูกกฎหมาย

• คาดหวังตัวเลขที่เฉพาะเจาะจงกว่านี้และผลลัพธ์ที่น่าทึ่งกว่านี้ แต่กลับดูเหมือนบทความประชาสัมพันธ์แบบพยายามบาลานซ์ และน่าจะเขียนด้วย LLM

  • ช่วงไม่กี่วันที่ผ่านมา ฉันแนะนำให้อ่านอินไซต์จากคู่แข่งอย่าง XBOW ซึ่งเพิ่มข้อมูลให้การถกเถียงได้มากกว่า
    [1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...

• คำถามจริงคือบทความนี้เขียนโดย Mythos หรือ Opus
  วลีอย่าง “ทำไมสิ่งนี้จึงสำคัญ” จริง ๆ ไม่ได้สำคัญนัก บล็อกองค์กรเดิมทีก็แทบไม่ค่อยมีน้ำเสียงของผู้เขียนคนเดียวอยู่แล้ว แต่การได้เห็นแม้แต่องค์กรใหญ่ ๆ เอาบล็อกไปจ้าง LLM เขียนก็น่าสนใจดี

  • โครงสร้างประโยคอย่าง “มันเป็นอคติที่สมเหตุสมผลสำหรับเครื่องมือสำรวจ มันเป็นอคติที่ทำลายล้างในคิวจัดประเภท...” ดูเป็น สำนวน AI ชัดเจน
    ฉันอยากยกระดับ “ทำไมสิ่งนี้จึงสำคัญ” ไปเป็น “ผลลัพธ์จาก AI กำลังกลายเป็นส่วนหนึ่งของข้อมูลฝึก” ตอนนี้เลย สักวันหนึ่งสไตล์การเขียนแบบ AI ที่ขัดเกลาแล้วแต่เยิ่นเย้ออาจกลายเป็นมาตรฐาน และถ้าไม่ใช่คนรุ่นก่อนก็คงแยกไม่ออก คล้ายกับการคิดถึงบางแง่มุมของ Usenet
  • น่าสนใจที่บางคนดูเหมือนคิดว่า ถ้าเสียดสีอะไรสักอย่างมากพอ เนื้อหาที่เป็นสาระของมันก็จะหายไปด้วย
    เหมือนกำลังจ้องปากกระบอกปืน แล้วเล่นมุกเรื่องกระดาษที่แผ่นโฆษณาปืนพิมพ์อยู่
  • นี่ไม่ใช่แค่องค์กรใหญ่ทั่วไป แต่คือ Anthropic ข้อความหลักของบริษัทนี้คือ AI ทำงานจริงได้แล้ว ถ้าพวกเขาไม่ทำตัวให้สอดคล้องกับสิ่งนั้นก็คงแปลก
    ก็คงเป็นเหตุผลว่าทำไม Claude Code ถึงมีบั๊กประหลาดเยอะ และซัพพอร์ตอาจบอกว่าคืนเงินให้แล้วทั้งที่จริง ๆ ยังไม่ได้
  • บล็อกของ Cloudflare นั้นยอดเยี่ยมมาหลายปีแล้ว ตั้งแต่นานก่อน Transformer จะถือกำเนิดเสียอีก
  • ดูไม่เหมือนเขียนโดย AI ล้วน ๆ แต่ใกล้เคียงกับงานที่ AI ช่วยแก้ไข มากกว่า หรือไม่ก็ใช้เครื่องมือทำให้ภาษาดูเป็นมนุษย์ที่ค่อนข้างดีในรอบที่สอง

• “บทเรียนสี่ข้อ” ที่อ้างว่าได้จากการรันงานนี้ในสเกลใหญ่ฟังดูตลกดี เพราะในสี่ข้อนั้นสามข้อแทบจะเหมือนกันและชัดเจนอยู่แล้ว
  ถ้าสรุปก็คือ คำขอที่ เฉพาะเจาะจงและแคบกว่า จะได้ผลดีกว่า “หาช่องโหว่ให้หน่อย” ซึ่งก็เป็นเรื่องปกติมาก ถึงอย่างนั้น การทบทวนแบบ adversarial แม้จะไม่ใช่เรื่องใหม่เลยและถูกพูดถึงใน HN มามากแล้ว ก็ยังถือว่าเป็นส่วนที่น่าสนใจและมีความแตกต่าง อย่างน้อยฉันก็ควรลองใส่มันเข้าไปใน workflow ของตัวเองให้มากขึ้น และมันอาจช่วยงานที่ไม่ใช่การเขียนโค้ดได้ด้วย
  https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...

• ประโยคที่ว่า “ปฏิกิริยาที่ใหญ่ที่สุดจากผู้นำด้านความปลอดภัยต่อ Mythos Preview คือเรื่องความเร็ว การสแกนที่เร็วขึ้น การแพตช์ที่เร็วขึ้น และการบีบวงจรการตอบสนองให้สั้นลง ในบรรดาทีมที่เราคุยด้วย มีมากกว่าสองทีมที่ทำงานด้วย SLA 2 ชั่วโมง ตั้งแต่การเปิดเผย CVE จนถึงแพตช์ใน production [...] ถ้าการทดสอบ regression ใช้เวลาหนึ่งวัน คุณก็จะไปไม่ถึง SLA 2 ชั่วโมงหากไม่ข้ามมัน และถ้าข้ามการทดสอบ regression คุณก็มีโอกาสปล่อยบั๊กที่แย่กว่าบั๊กที่ตั้งใจจะแพตช์เสียอีก” น่าประทับใจมาก
  สงสัยว่าเมื่อเวลาผ่านไป โมเดลแบบนี้จะสามารถทำ การทดสอบความสามารถในการถูกโจมตี ก่อน merge โค้ดได้ไหม เพื่อให้โดยพื้นฐานแล้วสร้างโค้ดที่ปลอดภัยขึ้น

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

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

  • อยากร่วมวงตั้งข้อสงสัยเหมือนกัน แต่ต้นบทความเขียนชัดมากว่านี่คือ การเปลี่ยนแปลงแบบขั้นบันได
    หลายคนมอง Mythos เหมือนแคมเปญสงครามจิตวิทยา แต่ฉันไม่ค่อยเข้าใจความสงสัยแบบนั้นนัก ดูเหมือนส่วนใหญ่มาจากความไม่ไว้วางใจทั่วไปต่อสิ่งที่ยังใช้กันสาธารณะไม่ได้ มีพนักงาน Anthropic บางคนอธิบาย Mythos ว่าเป็นการพัฒนาโมเดลอเนกประสงค์ แต่ส่วนนี้ยังไม่มีหลักฐานรองรับในวงกว้าง ฉันจึงยังคงสงสัยอยู่บ้าง ตราบที่จำกัดอยู่ในขอบเขตงานวิจัยด้านความปลอดภัย ฉันพอรับ narrative นี้ได้
  • เขาอธิบายไว้อย่างเป็นรูปธรรมว่า โดยทั่วไปแล้ว exploit มักถูกสร้างจากการ chaining ช่องโหว่เล็ก ๆ หลายจุดเข้าด้วยกัน
    มองแบบนั้น การปิดช่องโหว่จึงไม่เหมือนกับการหา exploit แต่ใกล้เคียงกับการเหลือช่องว่างเล็ก ๆ ให้น้อยลง จนยากขึ้นเรื่อย ๆ ที่จะประกอบ exploit ที่ใช้งานได้
  • ตอนนี้ฉันค่อนข้างเชื่อแล้วว่าโมเดลนี้มีความคิดสร้างสรรค์มากขึ้นมาก และสามารถ ทำงานเชิงเอเจนต์ได้นานขึ้น
    ดังนั้นต่อให้ “hard skill” ไม่ได้ดีขึ้นแบบถล่มทลาย มันก็ยังเอาทักษะเหล่านั้นมาผสมกันได้อย่างมีประสิทธิภาพกว่า ทุกวันนี้ช่องโหว่จำนวนมากก็ยังพอระบุได้ด้วย Opus แต่ถ้าจะพาไปจนถึง exploit ที่ซับซ้อนก็ยังต้องมีคน โดยเฉพาะคนที่ชำนาญ คอยแทรกกลางทางอยู่ดี ถ้าไม่ต้องมีคนคั่น คนทั่วไปก็จะหากับใช้ exploit ได้ง่ายขึ้นมาก
  • สัปดาห์ที่แล้ว Palo Alto Networks เปิดเผย แพตช์ CVE หลายตัวสำหรับไฟร์วอลล์ ซึ่งเกือบทั้งหมดมาจากการเข้าถึง frontier model รวมถึง Mythos
    https://security.paloaltonetworks.com
  • ผลิตภัณฑ์ใหม่ของ Anthropic ส่วนใหญ่เป็นเครื่องมือ AI ที่ไม่มีใครใช้ ดูเหมือนพวกเขาคงจะโพสต์ บทความคุณภาพต่ำ แบบนี้ต่อไป แถมช่วงหลังยังปลดคนออกเยอะด้วย เลยอาจไม่มีนักเขียนดี ๆ เหลือแล้ว

• ก็โอเคนะ แต่ไม่เข้าใจว่าทำไมถึงไม่แชร์ข้อมูลว่าเจอ ช่องโหว่ด้านความปลอดภัย จริง ๆ กี่รายการ ในจำนวนนั้นเป็นของจริงกี่รายการ และ false positive กี่รายการ

  • ฉันก็รอเรื่องนี้อยู่เหมือนกัน
    เข้าใจนะว่าอยากจัดการทุกอย่างให้เรียบร้อยก่อนเปิดเผย แต่เมื่อเห็นข้ออ้างที่แทบไม่มีข้อมูลรองรับอยู่เรื่อย ๆ ก็ไม่รู้ว่าพวกเขาคาดหวังให้คนไม่ตั้งข้อสงสัยได้อย่างไร ในทางอาชีพแล้ว ผู้เชี่ยวชาญด้านความปลอดภัยก็คือคนที่ ได้รับค่าตอบแทนเพื่อความสงสัย ตามตัวอักษรเลย

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

• ส่วนที่มันต่อต้านนี่ค่อนข้างตลก พอลองใช้เอง มันกลับขอหลักฐานว่าฉันมี สิทธิ์เข้าถึงโค้ดเบสนี้อย่างถูกกฎหมาย ก่อนที่จะยอมดำเนินการ

• ข้อความที่ว่า “สิ่งที่เปลี่ยนไปใน Mythos Preview คือ โมเดลสามารถ chain บั๊กความรุนแรงต่ำที่เดิมทีซ่อนอยู่ใน backlog ตามธรรมเนียม ให้กลายเป็น exploit ที่ร้ายแรงกว่าได้” ดูสอดคล้องพอสมควรกับการทดสอบอิสระอื่น ๆ ของ Mythos
  มันทำได้ดีมากกับ งานเชิงเอเจนต์ระยะยาว และคงถูกฝึกมาเพื่อสิ่งนั้น จึงต้องสามารถหาความเชื่อมโยงรอบข้างระหว่างหัวข้อที่เกี่ยวข้องกันอย่างหลวม ๆ ภายใน context window ได้
  [1] ที่หมายถึงหลัก ๆ คือ https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...