Chrome แก้บั๊กความปลอดภัย 1,072 ตัวใน 2 มิลสโตนล่าสุด มากกว่า 23 มิลสโตนก่อนหน้ารวมกัน — ทีม Chrome เปิดสถาปัตยกรรม multi-agent ที่หา triage และ patch ด้วย AI ทั้งสาย

30 กรกฎาคม 2026 ทีม Chrome Security ปล่อยบทความชื่อ “Stronger with every update” ที่เล่าอย่างละเอียดว่าพวกเขาเอา AI มาใส่ในวงจรชีวิตของบั๊กความปลอดภัยทุกขั้นตอนอย่างไร — ตั้งแต่หา, คัดกรอง, แก้ ไปจนถึงส่งแพตช์ถึงเครื่องผู้ใช้

ตัวเลขที่เป็นหัวใจของบทความ: ใน Chrome 149 และ 150 สองมิลสโตนล่าสุด ทีมแก้บั๊กความปลอดภัยไปแล้ว 1,072 ตัว ซึ่งมากกว่าจำนวนบั๊กความปลอดภัยที่แก้ได้ใน 23 มิลสโตนก่อนหน้ารวมกัน

นี่ไม่ใช่โพสต์การตลาด แต่เป็นเอกสารสถาปัตยกรรมที่มีรายละเอียดพอให้ทีมอื่นลอกไปใช้ได้จริง

ขั้นหา — จาก fuzzing สู่ agent harness ที่รู้จัก Chrome ทั้งตัว

ทีม Chrome ใช้ LLM มาหลายปีแล้ว ไทม์ไลน์ที่เขาเล่า: ปี 2023 ใช้ LLM เพิ่ม coverage ของ fuzzing, ปี 2024 ทำ Naptime ร่วมกับ Project Zero, ปี 2025 ทำ Big Sleep ร่วมกับ DeepMind และ Project Zero ซึ่งหาบั๊กใน V8 และ graphics stack ได้จริง

จุดเปลี่ยนคือ ต้นปี 2026 ที่พวกเขาสร้าง agent harness ใช้ Gemini กวาดหาช่องโหว่ทั่วทั้งโค้ดเบส Chrome ด้วยประสิทธิภาพสูงขึ้นและ false positive ต่ำลง หนึ่งในบั๊กที่เจอคือ sandbox escape ที่ทำให้ renderer ที่ถูกยึดหลอกให้ browser อ่านไฟล์ในเครื่องได้ — บั๊กที่ซ่อนอยู่ในโค้ดเบสมานานกว่า 13 ปี

จากนั้นพวกเขาปรับปรุง harness ด้วยสี่อย่างที่น่าลอก:

• รองรับหลายโมเดลสลับกันได้ เพื่อดึงจุดแข็งของทั้งโมเดล open-weights และโมเดล proprietary
• สร้าง knowledge base ของ Chrome ที่รวม CVE เก่าทั้งหมดและประวัติ Git ทั้งโปรเจกต์ เพื่อขยายความสามารถในการให้เหตุผลของ LLM ให้เกินข้อมูลที่มันเทรนมา
• ชวนนักพัฒนาใส่ไฟล์ SECURITY.md เพื่อให้โมเดลเข้าใจ trust boundary และมองภาพ threat model ได้ถูก
• เพิ่ม critic agent ที่มี context แยกต่างหาก ไว้อ่านไฟล์ SECURITY.md เหล่านั้นโดยเฉพาะ
• รันโมเดลหาบั๊กซ้ำหลายรอบบนโค้ดเบสเดิม เพื่อรับมือกับความไม่แน่นอนของโมเดลและการที่โมเดลเก่งขึ้นเรื่อย ๆ

ส่วนเรื่อง guardrail พวกเขาระบุชัด: AI วิเคราะห์ source code แบบ at rest เท่านั้น รันบนเครื่องที่ล็อกดาวน์ไม่มีอินเทอร์เน็ตทั่วไป มีระบบดักทุก network request ด้วย allowlist เข้มตามแอปต้นทางและปลายทาง ไม่เคยรันโมเดลในโหมดไร้ข้อจำกัด และจำกัดไม่ให้ subagent แก้ไขระบบหรือแตะไฟล์นอกไดเรกทอรีซอร์สโค้ดที่กำหนด

ขั้นคัดกรอง — และผลข้างเคียงที่ตกกับนักล่าบั๊ก

เดิมการ triage รายงานความปลอดภัยหนึ่งใบใช้เวลา 5 ถึง 30 นาทีขึ้นไป และพึ่งคนเป็นหลัก ตอนนี้เปลี่ยนเป็นระบบผสมกฎกับ AI สี่เฟส: กรอง spam และ duplicate, reproduce บั๊กบน OS/เวอร์ชันที่ได้รับผลกระทบพร้อมแนบ stack trace, เติม metadata (บั๊กเข้ามาตอนไหน ระดับความรุนแรงเท่าไร), แล้ว route ไปยัง component และเจ้าของที่ถูกต้องอัตโนมัติ

Google ประเมินว่ากระบวนการนี้ ประหยัดเวลานักพัฒนาได้หลายร้อยชั่วโมงต่อเดือน

ผลข้างเคียงที่น่าสนใจกว่า: ในเดือนมีนาคม 2026 Chrome ได้รับรายงานบั๊กมากกว่าทั้งปี 2025 รวมกัน ทำให้พวกเขาต้องปรับ Vulnerability Reward Program (VRP) ใหม่ ให้นักวิจัยโฟกัสไปที่บั๊กที่ เพิ่มเติมจากสิ่งที่ทีมหาเจอเองภายใน และอยู่ในรูปที่ระบบอัตโนมัติย่อยต่อได้

นี่คือสัญญาณที่นักล่าบั๊กควรอ่าน: เมื่อเจ้าของโค้ดเบสหาบั๊กเองได้เร็วขึ้นเป็นสิบเท่า มูลค่าของบั๊กระดับกลางที่ automation หาเจอได้ก็ลดลง

ขั้นแก้ — fixing agent วนกับ critic agent เหมือน code review

ส่วนที่ตรงกับงานประจำวันของนักพัฒนามากที่สุด คือ multi-agent workflow ที่เขาใช้แก้บั๊ก:

1. ขั้น build ดึง context จาก issue นั้น ๆ เข้ามา
2. fixing agent สร้าง candidate fix ออกมาหลายตัว
3. critic agent ประเมินว่าตัวไหนเหมาะสุด พร้อมผลิต artifact ให้นักพัฒนาใช้ตัดสิน
4. สองตัวนี้ วน loop กันเองเลียนแบบกระบวนการ code review เพื่อให้โค้ดทั้งทำงานได้และตรงตาม style guide ของ Chromium/Google รวมถึง convention ในพื้นที่นั้น
5. test-writing agent เขียนเทสต์ให้ fix โดยรับประกันว่าเทสต์ทำงานได้ครบทุกแพลตฟอร์มและ configuration ที่ Chrome รองรับ ก่อน ที่นักพัฒนาจะรีวิว — ประหยัดเวลาไปได้ถึงระดับสัปดาห์

ตอนนี้ Google บอกว่า LLM สร้าง candidate fix ให้ช่องโหว่ส่วนใหญ่แล้ว

ที่สำคัญคือ Big Sleep และ CodeMender ถูกผูกเข้ากับระบบ CI โดยตรง รันทุก 24 ชั่วโมงบน CL ทั้งหมด ผลลัพธ์: เฉพาะเดือนพฤษภาคมเดือนเดียว บล็อกช่องโหว่ไม่ให้หลุดขึ้น production ได้กว่า 20 ตัว รวมถึงบั๊กระดับ critical S1+ หนึ่งตัว

ขั้นส่ง — ไล่ปิด patch gap ถึงขั้นไม่ต้อง restart

ปัญหาที่เหลือคือ “patch gap” — ช่วงที่ fix ขึ้น open source tree แล้วแต่ยังไม่ถึงเครื่องผู้ใช้ ซึ่งผู้โจมตี reverse engineer เพื่อทำ N-day attack ได้

สิ่งที่ Chrome กำลังทำ:

• ย้ายไปใช้ รอบมิลสโตนใหญ่ทุก 2 สัปดาห์ พร้อมอัปเดตความปลอดภัยรายสัปดาห์
• นำร่องปล่อย security release สัปดาห์ละ 2 ครั้ง
• กำลังทำ automation สร้าง release note และคำบรรยาย CVE จากตัว fix เอง เพื่อลดคอขวดที่ต้องใช้คน
• ลงทุนใน “dynamic patching” ที่จะตัดความจำเป็นในการ restart browser ทั้งตัว โดยอาศัยสถาปัตยกรรม multi-process ของ Chrome ทยอยสลับ child process (Renderer, GPU) เป็นไบนารีใหม่แบบ on the fly

ข้อสุดท้ายน่าสนใจเพราะมันยอมรับตรง ๆ ว่า เมื่อขั้น triage-fix-test-release เหลือ 1–2 วัน ตัวถ่วงที่ใหญ่ที่สุดกลายเป็นการที่ผู้ใช้ไม่ยอม restart เบราว์เซอร์

มุมมอง AI Curator

โพสต์นี้อ่านสนุกในฐานะข่าวความปลอดภัย แต่มีค่ากว่ามากในฐานะ case study ของ multi-agent system ที่รันจริงในระดับ production ที่ใหญ่ที่สุดชุดหนึ่งในโลก — และมันยืนยันรูปแบบเดียวกับที่ทีมเล็ก ๆ ควรใช้

สังเกตว่า Chrome ไม่ได้ใช้ “agent ตัวเดียวที่เก่งมาก” แต่ใช้การแบ่งบทบาทที่ชัด: หา / วิจารณ์ / แก้ / วิจารณ์ / เขียนเทสต์ และที่สำคัญคือ critic agent มี context แยกจาก fixing agent ซึ่งเป็นรายละเอียดที่คนมักข้าม — agent ที่เพิ่งเขียนโค้ดมาเองไม่ใช่คนที่เหมาะจะตัดสินว่าโค้ดนั้นดีไหม เพราะ context เดียวกันทำให้มันเห็นด้วยกับตัวเอง

อีกจุดที่ควรลอกทันทีโดยไม่ต้องมีทีมขนาด Google คือ SECURITY.md ไอเดียที่ว่าโมเดลไม่รู้ว่าอะไรคือ trust boundary ในโค้ดเบสของคุณเว้นแต่คุณจะเขียนบอกมัน เป็นเรื่องจริงกับทุกโปรเจกต์ ทีมไทยที่รัน AI code review อยู่แล้วสามารถเพิ่มไฟล์นี้ได้พรุ่งนี้เลย ต้นทุนเกือบศูนย์ เช่นเดียวกับการเอา CVE เก่าและประวัติ Git มาทำ knowledge base ให้โมเดล — สองอย่างนี้คือการชดเชยข้อจำกัดว่าโมเดลไม่รู้จักโค้ดเบสเฉพาะของคุณ

แต่ข้อที่ควรคิดต่อคือด้านมืดของสมการเดียวกัน ถ้า Gemini หา sandbox escape อายุ 13 ปีเจอได้ในโค้ดเบสที่ถูกตรวจหนักที่สุดในโลก โค้ดเบสของคนอื่นที่ไม่มีทีมความปลอดภัยขนาดนี้ก็ถูกกวาดด้วยเครื่องมือแบบเดียวกันได้เหมือนกัน และฝั่งผู้โจมตีไม่ต้องรอ patch cycle ประโยคที่ Chrome เขียนว่า “ในสภาพที่การโจมตีขับเคลื่อนด้วย AI และเคลื่อนที่เร็ว จังหวะการส่งของเราต้องเร็วขึ้นอีก” ไม่ใช่คำโฆษณา แต่เป็นการยอมรับว่าเกมนี้เร่งขึ้นทั้งสองฝั่ง

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

แหล่งข่าว

• Stronger with every update: How we’re making Chrome and the web safer in the AI Era — Google Blog (30 ก.ค. 2026)
• Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models — Google Project Zero (20 มิ.ย. 2024)
• Chrome Vulnerability Reward Program