Anthropic เปิด Cyber Mission และ OSS Scanner ฟรี—รายงานเร็วขึ้นแต่ไม่มีคนรีวิวทุกชิ้น

Anthropic เปิดตัว Anthropic Cyber Mission เมื่อ 8 ตุลาคม 2026 โดยเริ่มสองแนวรบพร้อมกัน: Critical Infrastructure Defense Program นำโมเดล วิศวกร onsite และงานวิจัยภัยคุกคามไปช่วยทีมที่ดูแลระบบไฟฟ้า น้ำ การขนส่งและภาครัฐ; อีกฝั่งคือ OSS Scanner บริการสแกนช่องโหว่เป็นระยะให้โครงการ open source ที่สมัครใจโดยไม่คิดค่าใช้จ่ายครับ

หัวใจที่ต้องอ่านให้ครบคือรายงานจาก OSS Scanner จะเป็น model-generated output และ ไม่มี human review/triage ก่อนส่งทุกชิ้น Anthropic บอกข้อดีคือส่งได้เร็วและถี่ขึ้น แต่ยอมรับว่า report อาจผิดหรือประเมิน threat model คลาดเคลื่อน ผู้ดูแลโครงการจึงไม่ได้รับ “คำตัดสินช่องโหว่สำเร็จรูป” แต่ได้รับกอง candidate พร้อม reproducer, คำอธิบาย และ patch ที่ต้องตรวจอีกชั้น

สรุป 30 วินาที

• OSS Scanner เป็น opt-in สำหรับ core maintainer ของโครงการที่เข้าเกณฑ์ คล้ายเกณฑ์ผลกระทบของ OSS-Fuzz และสแกนเป็นระยะฟรี
• Anthropic ระบุว่าหกเดือนก่อนเปิดตัวพบ candidate มากกว่า 29,000 รายการ แต่คน review/triage ได้ราว 6,000 รายการ จึงเปิด fast-track ให้โครงการที่ยอมรับ raw reports
• รายงานอาจมี reproducer, จุดที่บั๊กเริ่มเข้ามา และ candidate patch แต่ไม่ได้รับ human verification ทุกใบ
• Anthropic อ้างผลทดลอง 97 รายการระดับ high/critical ใน 48 โครงการ: 85 รายการผ่านเกณฑ์ CVD, อีก 11 เป็นปัญหาจริงแต่ซ้ำ และหนึ่งรายการ invalid; นี่เป็น sample ที่บริษัทเลือกประเมิน ไม่ใช่ guarantee ทุก repo
• โปรแกรม critical infrastructure มีพันธมิตรหลายราย แต่ Axios ระบุว่ายังไม่ชัดว่าใครรับค่า compute และจะทดสอบ/ลง patch โดยไม่กระทบสาธารณูปโภคอย่างไร

ทำไมเรื่องนี้เกี่ยวกับคุณ

ซอฟต์แวร์แทบทุกองค์กรยืนบน open source แต่ maintainer จำนวนมากไม่มี security team ประจำ การได้รับ scanner ฟรีอาจช่วยพบช่องโหว่ก่อนผู้โจมตี ขณะเดียวกัน report หลายร้อยใบที่เข้าพร้อมกันอาจกลายเป็นงานกองใหม่ ถ้าทีมรีบเปิด issue สาธารณะหรือ merge patch ที่โมเดลเสนอโดยไม่ reproduce ก็อาจเผยช่องโหว่ก่อน fix พร้อมหรือทำ regression

ให้นึกถึงร้านข้าวที่ได้รับวัตถุดิบจากรถตรวจคุณภาพอัตโนมัติ รถชี้ถุงต้องสงสัยได้เร็วมาก แต่พ่อครัวยังต้องดูว่าเป็นของเสียจริงหรือเป็นกลิ่นปกติของวัตถุดิบชนิดนั้น และต้องแยกถุงก่อนประกาศเรียกคืน OSS Scanner เพิ่มกำลัง “หา” แต่ขั้นยืนยัน severity, exploitability, affected versions และ safe patch ยังเป็นงานของ maintainer กับผู้เชี่ยวชาญ

สำหรับทีมที่ไม่ได้สมัคร scanner ข่าวนี้ยังสำคัญ เพราะ dependency ที่เราใช้ อาจได้รับรายงานและออก security release เร็วขึ้น ต้องมี inventory/SBOM, owner และช่องทางติดตาม advisory มิฉะนั้นความเร็ว upstream ไม่ช่วย downstream ที่ไม่รู้ว่าตัวเองใช้เวอร์ชันใด

ทำงานยังไง: สายพานค้นหาเร็วกับด่านมนุษย์ที่เลือกได้

รายละเอียดการเปิดบริการของ Anthropic บอกว่าโครงการสมัครผ่าน pull request ตาม template และถูกคัดกรองเป็นกรณี ๆ ไป โมเดลสแกน repository หา candidate แล้วสร้างรายงานที่พยายาม self-contained: วิธี reproduce, คำอธิบาย, bisection เมื่อทำได้ และ patch candidate

เส้นทางปกติของ coordinated vulnerability disclosure ยังใช้ human-verified report โดยเฉพาะโครงการที่ไม่มีทรัพยากร triage ส่วน fast-track เปิดให้ maintainer ที่ขอรับทุกอย่างเห็น raw output เร็วขึ้น ความต่างเหมือนโรงพยาบาลมีช่องผล lab preliminary กับผลที่แพทย์รับรอง ผู้รับต้องรู้ป้ายสถานะ มิฉะนั้นเอาค่า preliminary ไปประกาศเป็น diagnosis

ตัวเลข 29,000 candidate เทียบกับ review ราว 6,000 อธิบาย bottleneck: model throughput โตเร็วกว่าความสามารถมนุษย์ในการยืนยัน Anthropic ระบุว่าได้ส่งเกือบ 5,000 reports โดยตรงให้ maintainer ที่ขอรับทั้งหมดแล้ว ตัวเลขนี้แสดง demand บางส่วน แต่ไม่ได้บอกว่า report เหล่านั้น valid กี่เปอร์เซ็นต์ในทุกโดเมน

ฝั่ง Critical Infrastructure Defense Program ไม่ใช่ scanner ตัวเดียว แต่รวม frontier models, onsite engineers และ threat research ให้บริษัทที่ดูแล operational technology ตาม รายงาน Axios พันธมิตรเริ่มต้นมีทั้งที่ปรึกษา ผู้ผลิตระบบ และบริษัท security เป้าหมายคือช่วยหาและแก้ช่องโหว่ในระบบลูกค้า แต่ OT มีข้อจำกัดด้าน availability, safety certification และ maintenance window สูงกว่าระบบเว็บทั่วไป

เงินและผลกระทบ

คำว่า “ฟรี” ครอบคลุมการสแกนที่ Anthropic ประกาศ ไม่ได้ทำให้ต้นทุน triage, reproduce, patch, backport, release และแจ้งผู้ใช้เป็นศูนย์ โครงการเล็กอาจได้ report คุณภาพสูงแต่ไม่มี CI หลายแพลตฟอร์มหรือทีมออก CVE การระดมทุน maintainer, bug bounty, security response retainer และบริการ backport ยังจำเป็น

รายงานเร็วขึ้นอาจลดช่วงที่บั๊กไม่ถูกพบ แต่ถ้าส่ง raw exploit detail ผ่านช่องทางผิดก็เพิ่ม disclosure risk โครงการต้องมี private reporting channel, access control, retention และ embargo policy ก่อนสมัคร ไม่ควรเอา report เข้า public issue tracker อัตโนมัติ และ candidate patch จากโมเดลต้องผ่าน review/test/fuzz/regression เหมือน patch อื่น

สำหรับ critical infrastructure ต้นทุนหยุดระบบสำคัญมาก Patch ที่ถูกในเชิงโค้ดอาจทำให้ PLC, historian หรือ safety system ทำงานสะดุด การ rollout ต้องมี lab/digital twin, vendor approval, rollback, segmented access และคนปฏิบัติการร่วมตัดสิน AI ไม่ควรมีทางแก้ production โดยตรงเพียงเพราะพบปัญหาได้เร็ว

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

Anthropic ให้ตัวเลขผลทดลองละเอียดและ feedback จากบางโครงการ แต่เป็นข้อมูลที่บริษัทคัดเลือกและรายงานเอง ยังไม่มี benchmark อิสระที่สะท้อนทุกภาษา ขนาด repo หรือ threat model ตัวเลข 88% ของชุด high/critical 97 รายการไม่ควรถูกแปลงเป็น precision 88% สำหรับ report ทุกระดับ และ 11 รายการที่ซ้ำยังสร้างภาระ triage แม้บั๊กจริง

หน้าเปิดตัวบอกบริการไม่มีค่าใช้จ่ายสำหรับโครงการที่เข้าเกณฑ์ แต่ Axios ระบุว่ายังไม่ชัดว่า critical-infrastructure partners จะได้ model access ฟรีหรือใครจ่าย compute สองเรื่องไม่ได้ขัดกันตรง ๆ เพราะเป็นคนละโปรแกรม แต่ headline “Cyber Mission ฟรี” อาจทำให้ผู้อ่านเหมารวม จึงต้องแยก OSS Scanner ฟรีออกจากโครงสร้างค่าใช้จ่าย CIDP ที่ยังไม่เปิดครบ

Anthropic บอก report จะไม่มี human review ก่อนส่ง ขณะที่ quote ของ early testers บางรายบอกคุณภาพสูงมาก ประสบการณ์จากกลุ่มแรกเป็นสัญญาณบวก ไม่ใช่การรับประกัน repo ของเรา โมเดลอาจเข้าใจ permission model ผิด, severity สูงเกิน, เสนอ patch แคบเกิน หรือสร้าง reproducer ที่พึ่ง environment เฉพาะ

ยังไม่ชัดเรื่อง SLA, ความถี่ scan ต่อโครงการ, เวลากักข้อมูล, model/data-use policy รายละเอียด, การจัดลำดับคิวเมื่อพบจำนวนมาก และขั้นตอน dispute severity ในทุกกรณี ผู้สมัครต้องอ่าน FAQ/terms ล่าสุดและขอคำตอบก่อนให้ repository หรือ report ที่เป็นความลับเข้าระบบ

แล้วเราควรทำอะไร

Maintainer ที่สนใจควรเตรียม SECURITY.md, private intake, triage owner, severity rubric, supported-version matrix และ test/rollback ก่อนสมัคร กำหนดว่า raw report ใครเห็นได้, จะยืนยันใน environment แยกอย่างไร, เมื่อใดจึงขอ CVE/แจ้ง downstream และห้าม automation เปิด issue สาธารณะหรือ merge patch เอง

องค์กรผู้ใช้ dependency ควรสร้าง SBOM ที่อัปเดตได้ ผูก package กับ owner ติดตาม advisory/release และซ้อม emergency update อย่ารอ scanner ส่งถึงเราโดยตรง เพราะบริการเน้น upstream project เมื่อมี patch ต้องพิสูจน์ว่า artifact ที่ deploy จริงรับ fix แล้ว ไม่ใช่แค่แก้ branch ต้นทาง

ทีม OT/critical infrastructure ควรแยก discovery จาก remediation ใช้ read-only assessment ก่อน, ห้าม model เชื่อม production network หรือ credential โดย default, ทดสอบใน lab, ขอ vendor sign-off, วาง maintenance window และมี manual kill switch ทุก action ที่เปลี่ยน state ต้องมีผู้ดูแลระบบจริงอนุมัติ

หากได้รับ report ให้ reproduce โดยไม่ใช้ production data, ตรวจ affected range, หา duplicate, review exploit precondition, เขียน regression test แล้วประเมิน patch ทางเลือก เก็บ raw model output เป็น untrusted input เพราะคำสั่งหรือไฟล์ใน repo อาจพยายาม prompt-inject scanner และ report เองอาจมี payload อันตราย

Recap

• แยก raw model report ออกจาก human-verified advisory ให้ชัด
• เตรียม private disclosure และ triage owner ก่อนสมัคร
• reproduce ใน environment แยกและเขียน regression test ก่อน patch
• ห้ามเปิด issue หรือ merge candidate patch อัตโนมัติ
• จำกัดสิทธิ์ scanner, retention, network และ secret ตาม least privilege
• ฝั่งผู้ใช้ dependency ต้องมี SBOM และ owner เพื่อรับ security release
• ระบบ OT ต้องทดสอบใน lab มี vendor approval และ rollback
• อย่าใช้สถิติ sample ของบริษัทเป็น guarantee ทุกโครงการ

OSS Scanner อาจเพิ่มกำลังค้นหาช่องโหว่ได้มากจริง แต่ผลลัพธ์ที่มีค่าจะเกิดเมื่อโครงการมี “ด่านรับของ” ที่พร้อมครับ ความเร็วของสายพานไม่ควรบังคับให้ maintainerเลือกระหว่างปล่อยรายงานค้างกับรีบแก้แบบเสี่ยง