ข้ามไปยังเนื้อหา
Trail of Bits ชำแหละเบนช์มาร์ก AI ปะช่องโหว่ของ 1Password — เลข 26% รวมการทดลองที่ 'สั่งให้ปะผิด' 22% และที่ห้ามรันโค้ดอีก 36%
งานวิจัย

Trail of Bits ชำแหละเบนช์มาร์ก AI ปะช่องโหว่ของ 1Password — เลข 26% รวมการทดลองที่ 'สั่งให้ปะผิด' 22% และที่ห้ามรันโค้ดอีก 36%

อ่าน 8 นาที ที่มา: Trail of Bits

วันที่ 15 ก.ย. 2026 Trail of Bits เผยแพร่บทความที่ตรวจสอบรายงาน FLAWED ของ 1Password ซึ่งออกเมื่อ 6 ส.ค. 2026 และมีพาดหัวที่ถูกอ้างต่อกันมาทั้งเดือนว่า โมเดล AI ปะช่องโหว่ได้สะอาดเพียง 26% ของเวลาทั้งหมด ผู้เขียนคือ Anish Naik, Dan Guido, Benjamin Samuels และ Marcelo Morales

ข้อสรุปของพวกเขาตรงและแรง: ตัวเลข 26% นั้น “includes experiments that deliberately instructed agents to apply the wrong fix, along with experiments in which agents could not compile or test their patches” และ “Defenders should not take 1Password’s headline rate seriously as a measure of AI patching ability.” ความกังวลที่ระบุไว้คือรายงานอาจทำให้ฝ่ายตั้งรับ ทำงานได้แย่ลง เพราะเลิกใช้เครื่องมือที่ช่วยปิดช่องโหว่ได้จริง

สี่ทางเลือกที่ทำให้เลข 26% ไม่สะท้อนงานปะช่องโหว่ทั่วไป

  1. กลุ่มตัวอย่างถูกเลือกเพราะปะยาก — ผู้เขียนเลือกช่องโหว่หกรายการเพราะการแก้ซับซ้อน อัตรา clean fix ของแต่ละรายการกระจายตั้งแต่ 3% ถึง 60% ค่าเฉลี่ยจึงขึ้นกับว่าเลือกช่องโหว่ไหนเข้ามาอย่างมาก เชิงอรรถของ Trail of Bits ระบุเพิ่มว่าค่าเฉลี่ยจากหกเป้าหมายมี standard error ราว 9 จุดเปอร์เซ็นต์ ซึ่งรายงานไม่ได้เปิดเผย
  2. พรอมป์ตสองตัวสั่งให้เอเจนต์ปะผิด — คิดเป็น 22% ของข้อมูล การเอามารวมกับความพยายามซ่อมปกติ ทำให้อัตราที่รายงานขึ้นอยู่กับว่านักวิจัยเลือกให้คำแนะนำผิดบ่อยแค่ไหน
  3. มากกว่าหนึ่งในสามของการทดลองห้ามทดสอบ — โหมดประเมินหนึ่งกันไม่ให้เอเจนต์ build หรือรันโค้ด คิดเป็น 36% ของข้อมูล แล้วถูกเฉลี่ยรวมกับการทดลองที่เอเจนต์ทดสอบแพตช์และแก้ตามผลได้
  4. โมเดลรันคนละระดับ reasoning — GPT-5.5 รันที่ medium ส่วน Opus 4.8 รันที่ high ซึ่งเป็นค่าเริ่มต้นของเครื่องมือ แต่ไม่มีตัวไหนถูกทดสอบที่ระดับสูงสุด และรายงานไม่ได้วัดว่าการเพิ่ม effort เปลี่ยนผลอย่างไร

เมื่อ Trail of Bits วิเคราะห์ข้อมูลของ 1Password เองใหม่ โดยเก็บเฉพาะการทดลองที่เอเจนต์รันโค้ดได้และไม่ได้ถูกสั่งให้ปะผิด (และตัดรันที่งานวิจัยจัดว่าไปดู upstream fix มาแล้ว) ผลคือ แพตช์ 2,634 จาก 3,067 ชิ้น (86%) บล็อก exploit ที่ให้มาได้ พร้อมข้อจำกัดที่พวกเขาเขียนเองว่า การบล็อก exploit นั้นไม่ได้พิสูจน์ว่าซ่อมครบ

ปัญหาของคนตรวจ: เมื่อผู้ให้เกรดไม่ตรงกันเอง 36.8%

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

  • กฎหยุดกับเกณฑ์ให้คะแนนขัดกัน — เอเจนต์ถูกสั่งให้หยุดเมื่อแพตช์เอาชนะ PoC ที่ให้มา แต่ผู้ให้เกรดกลับไปประเมินเส้นทางที่ exploit นั้นไม่ได้แตะ
  • ให้คะแนนลบกับการเปลี่ยนพฤติกรรมที่ตั้งใจ — เอเจนต์ถูกสั่งห้ามแตะเทสต์เดิม ทั้งที่การแก้ที่ถูกต้องบางครั้งต้องอัปเดตเทสต์ Trail of Bits พบว่า 8% ของคำตัดสินในกรณี ActiveMQ ลงโทษการเปลี่ยนพฤติกรรมที่ตั้งใจว่าเป็น regression
  • เกรดอัตโนมัติไม่ตรงกับมนุษย์ — โมเดลที่ให้เกรดแพตช์ของตัวเองตรงกับผู้ตรวจที่เป็นคนบนผลลัพธ์ห้าหมวดเต็มเพียง 65.9% ของเคสที่รีวิว (ตรงกัน 87.7% เฉพาะคำถามว่าบั๊กเดิมถูกแก้ไหม และ 70.5% เฉพาะคำถามว่ามีบั๊กใหม่ไหม — Table 24)
  • เปลี่ยนคนตรวจแล้วผลเปลี่ยน — โมเดลสองตัวให้ผลต่างกันบนแพตช์ชิ้นเดียวกัน 36.8% และพาดหัวใช้ค่าเฉลี่ยของทั้งสอง (Table 20)
  • แพตช์อ้างอิงของ Linux เองมีช่องโหว่ — ผู้เขียนพบแพตช์ที่โมเดลสร้าง 248 ชิ้น ที่ทำ off-by-one ซ้ำรอย upstream fix แต่ผู้ให้เกรดอัตโนมัติจับได้เพียง 24 ชิ้น (Section 4.4)
  • ผู้ให้เกรดฝั่ง Chromium ปล่อยการซ่อมที่ไม่ครบผ่าน — ทำเครื่องหมายว่าสะอาดทั้งที่ยังเหลือ use-after-free ใน callback (Section 4.9)

ตัวเลขฐานของมนุษย์ที่หายไปจากทุกบทสนทนา

ข้อมูลที่ Trail of Bits เปิดครั้งนี้และหาที่อื่นไม่ได้ คืออัตราที่นักพัฒนาซ่อมผิดตั้งแต่ครั้งแรก พวกเขาย้อนดูการแก้ครั้งแรกของช่องโหว่ 2,265 รายการ จากการตรวจสอบความปลอดภัย 236 งาน ระหว่างปี 2024–2026 เจ้าของโค้ดเป็นคนแก้เอง มีรายงานละเอียดอยู่ในมือ และรู้ว่าจะถูกรีวิว — เงื่อนไขที่เอื้อที่สุดเท่าที่จะเป็นไปได้

ผลคือ 283 รายการ (12.5% หรือหนึ่งในแปด) แก้ครั้งแรกไม่ครบ ช่วงความเชื่อมั่น 95% อยู่ที่ 10.5%–14.5% พร้อมหมายเหตุว่าตัวเลขนี้อาจต่ำกว่าจริง เพราะบางครั้งทีมทักท้วงแบบไม่เป็นทางการก่อนถึงรอบรีวิว ซึ่งไม่ถูกบันทึก และพวกเขาย้ำเองว่า “A direct comparison with agents would require the same tasks and working conditions”

ฝั่งงานภาคสนาม จาก Patch the Planet (โครงการร่วมกับ OpenAI) มี PR ที่ maintainer ตัดสินแล้วถึง 14 ก.ย. 2026 รวม 186 รายการ — merge 126 รายการ (67.7%) ในจำนวนนั้น 91 รายการ (72.2%) รับแพตช์ความปลอดภัยเดิมโดยไม่มีการแก้เชิงความปลอดภัย อีก 33 รายการ (26.2%) รับแต่มีการแก้ ส่วน 60 รายการที่ปิดโดยไม่ merge ส่วนใหญ่ (36 รายการ) ถูกงานอื่นแทนที่ และมีเพียง 4 รายการ (6.7%) ที่ถูกปฏิเสธด้วยเหตุผลทางเทคนิคโดยตรง

เคสที่น่าอ่านที่สุดคือ freenginx ซึ่ง 1Password ยกมาเป็นกรณีศึกษาว่าแพตช์ของ Trail of Bits แย่ Trail of Bits ตอบว่า “The paper’s criticism of our patch is correct” — แพตช์ของเอเจนต์เหลือเส้นทางหนึ่งไม่ได้ปิด และสร้าง crash ใหม่ตอน cleanup แต่ประเด็นอยู่ที่ประโยคถัดไป: maintainer ปิด PR นั้นแล้วเขียนแพตช์ของตัวเอง ซึ่งปิดครบทั้งสามเส้นทาง แต่สร้าง crash เดียวกันตอน cleanup คนกับเอเจนต์ทำงานแยกกัน แล้วตกหลุมเดียวกันบนบั๊กเดียวกัน

พวกเขายังไล่ดู commit ที่ตามมาราว 33,500 รายการ ในโปรเจกต์ที่เคยส่งแพตช์ เพื่อหาว่าแพตช์ของตัวเองสร้างปัญหาอะไรไว้บ้าง พบบั๊กเชิงฟังก์ชันอย่างน้อย 10 รายการ บั๊กของ build/test/release automation 4 รายการ และบั๊กด้านประสิทธิภาพ 1 รายการ — ไม่พบช่องโหว่ความปลอดภัยที่ใช้โจมตีได้

agent skill สองตัวที่ปล่อยพร้อมบทความ

พร้อมบทความนี้ Trail of Bits ปล่อย skill สองตัว — post-patch-validation ช่วยให้เอเจนต์ทดสอบแพตช์ความปลอดภัยก่อนส่งรีวิว และ review-walkthrough ช่วยวิศวกรรีวิวการเปลี่ยนแปลงโค้ด เราตรวจสอบแล้วว่าทั้งสองอยู่จริงใน repo trailofbits/skills (ราว 7,100 ดาว) ภายใต้ plugins/post-patch-validation/ และ plugins/review-walkthrough/ โดยมาพร้อม eval case และเทสต์ของตัวเอง

จุดที่ควรอ่านให้ชัด: บทความเขียนกำกับเองว่า post-patch-validation “was not used in the Patch the Planet work described above” — เป็นสกิลใหม่ที่เขียนขึ้นจากบทเรียน ไม่ใช่เครื่องมือที่ผลิตตัวเลข 67.7% ข้างต้น ขั้นตอนที่มันบังคับก็ตรงกับข้อวิจารณ์ที่พวกเขามีต่อ 1Password พอดี คือให้เอเจนต์เขียนเช็กที่ ต้อง fail บนโค้ดเดิมและ pass บนโค้ดที่ปะแล้ว (เทสต์ที่ผ่านทั้งสองเวอร์ชันพิสูจน์อะไรไม่ได้) และให้ทดสอบเส้นทางอื่นที่นำไปสู่ความล้มเหลวเดียวกันอย่างน้อยหนึ่งเส้น

มุมมอง AI Curator

ก่อนอื่นต้องพูดให้ตรง: ไม่มีฝ่ายไหนในเรื่องนี้เป็นกรรมการกลาง Trail of Bits รัน Patch the Planet ร่วมกับ OpenAI ซึ่งเป็นเจ้าของโมเดลที่ถูกวัด ส่วน 1Password ก็มีผลิตภัณฑ์ความปลอดภัยของตัวเอง ตัวเลข 67.7% กับ 26% ไม่ได้ขัดแย้งกันด้วยซ้ำ เพราะมันวัดคนละสิ่งคนละเงื่อนไข — อันหนึ่งคือแพตช์ที่วิศวกรกำกับ เลือกเป้าหมายเอง และผ่านสายตา maintainer อีกอันคือเอเจนต์รันเดี่ยวบนช่องโหว่ที่คัดมาเพราะยาก ใครหยิบเลขใดเลขหนึ่งไปสรุปว่า “AI ปะช่องโหว่ได้/ไม่ได้” ก็ผิดเท่ากัน

สิ่งที่มีค่าที่สุดจากบทความนี้จึงไม่ใช่ข้อโต้แย้ง แต่เป็น ตัวเลขสองตัวที่ย้ายไปใช้ที่อื่นได้จริง ตัวแรกคือ 12.5% — หนึ่งในแปดของการแก้ครั้งแรกโดยมนุษย์เจ้าของโค้ดเองไม่ครบ ภายใต้เงื่อนไขที่ดีที่สุด เลขนี้คือเส้นฐานที่หายไปจากทุกการถกเถียงเรื่องเอเจนต์ปะช่องโหว่ในรอบปี เพราะเรามักเทียบ AI กับความสมบูรณ์แบบในจินตนาการ แทนที่จะเทียบกับสิ่งที่มันแทนที่จริง ๆ ตัวที่สองคือ 36.8% — อัตราที่โมเดลผู้ให้เกรดสองตัวตัดสินแพตช์ชิ้นเดียวกันไม่ตรงกัน และ 65.9% ที่เกรดอัตโนมัติตรงกับคนเต็มห้าหมวด

เลขตัวหลังนี้ควรถูกจำไว้ให้ดีที่สุด เพราะมันเกินขอบเขตเรื่องปะช่องโหว่ไปไกล ทุกวันนี้ทีมไทยจำนวนมากใช้ LLM-as-judge ในไปป์ไลน์ eval ของตัวเอง แล้วรายงานตัวเลขทศนิยมหนึ่งตำแหน่งให้ผู้บริหารดู ถ้าผู้ตัดสินสองตัวไม่ตรงกันหนึ่งในสามของเวลา ความต่าง 3–5 จุดเปอร์เซ็นต์ระหว่างโมเดลสองตัวในตารางของคุณก็ไม่มีความหมาย — และข้อนี้สอดคล้องกับที่ BenchMIRT ของ AI2 และ งานที่พบว่าเทคนิคเทสต์ของเอเจนต์ไม่ได้ผลอย่างที่คิด ชี้ไว้ก่อนหน้า วิธีแก้ไม่ใช่เลิกใช้ผู้ตัดสินที่เป็นโมเดล แต่คือ รายงานอัตราที่ผู้ตัดสินไม่ตรงกันควบคู่ไปกับคะแนนเสมอ ถ้าไม่มีเลขนั้น อย่าเชื่อคะแนน

เรื่องที่สามที่ควรเก็บไปใช้คือรายการเช็กที่ Trail of Bits เสนอว่าเบนช์มาร์กที่มีประโยชน์ควรทำ — แยกรายงานพรอมป์ตที่ให้คำแนะนำผิดและการทดลองที่จำกัดเครื่องมือออกจากกัน ทำความถูกต้องให้ตรวจสอบได้ รายงานผลรายช่องโหว่และความแปรปรวนระหว่างการรันซ้ำ และวัดว่าเอเจนต์เพิ่มอะไรให้กระบวนการเทียบกับนักพัฒนาที่ทำงานภายใต้เงื่อนไขเดียวกัน สี่ข้อนี้เอาไปใช้ออกแบบ eval ภายในองค์กรได้ตรง ๆ โดยไม่ต้องสนใจว่าใครถูกในศึกครั้งนี้ และสำหรับทีมที่ให้เอเจนต์ปะช่องโหว่อยู่แล้ว ข้อที่ลงมือได้วันนี้คือติดตั้ง post-patch-validation แล้วบังคับกฎข้อเดียวของมัน: เทสต์ที่ผ่านทั้งก่อนและหลังแพตช์ ไม่ใช่หลักฐานว่าอะไรถูกซ่อม

แหล่งข่าว

บทความนี้เรียบเรียงจากแหล่งข่าวต้นทาง — Trail of Bits

เนื้อหาบน blog นี้สร้างโดย AI โดยมีการกำกับบรรณาธิการจากมนุษย์

อ่านเพิ่มในหมวด งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง

ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง

· อ่าน 4 นาที
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
งานวิจัย

Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'

Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล

· อ่าน 4 นาที
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
งานวิจัย

QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS

ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS

· อ่าน 3 นาที