Google ระงับโครงการรางวัลบั๊กใด?

ระงับโครงการ Google Open Source Software Vulnerability Reward Program (OSS VRP) ตั้งแต่วันที่ 1 ตุลาคม 2026 เป็นต้นไป ไม่รับรายงานบั๊กของผลิตภัณฑ์ใหม่ รายงานที่ส่งก่อน 1 ตุลาคมจะดำเนินการตามปกติ โครงการ VRP อื่นและโครงการรางวัลการแก้ไขบั๊กไม่ถูกกระทบ ส่วนบั๊กของผลิตภัณฑ์บางอย่างยังอาจรับผ่าน Cloud VRP ได้

ทำไม Google ถึงระงับ OSS VRP?

Google อธิบายว่าการส่งรายงานอัตโนมัติเพิ่มขึ้นอย่างมหาศาล และส่วนใหญ่ไม่เป็นบั๊กจริง สื่อด้านความปลอดภัยชี้ว่า รายงานหลายฉบับมีเนื้อหา “hallucination” ของ AI หรือเป็นปัญหาที่ผลกระทบจริงน้อยมาก ผู้ดูแลต้องใช้เวลามากในการตรวจสอบและปฏิเสธ ทำให้ความสามารถในการจัดการบั๊กจริงลดลง

OSS VRP จะกลับมาเปิดใหม่เมื่อไหร่?

Google ระบุว่าการระงับจะต่อเนื่องอย่างน้อยจนถึงไตรมาสแรกของปี 2027 และจะประกาศอัปเดตการปรับโครงการในเวลานั้น ปัจจุบันยังไม่มีรายละเอียดกฎใหม่ที่ชัดเจน เวลาและรูปแบบการกลับมาจะขึ้นอยู่กับประกาศอย่างเป็นทางการของ Google Bug Hunters

ยังสามารถส่งรายงานบั๊กที่ใช้ AI ช่วยค้นหาได้หรือไม่?

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

รางวัลบั๊กเดิมมีไว้ให้กับผู้ที่พบปัญหาจริง เมื่อ AI สามารถสร้างรายงานดูเป็นมืออาชีพได้หลายร้อยฉบับในบ่ายเดียว ผู้ดูแลระบบต้องใช้แรงงานทั้งหมดเพียงแค่พิสูจน์ว่ารายงานเหล่านั้นผิดพลาดจนหมดแรง

Google หยุดโปรแกรมรางวัลการเปิดเผยช่องโหว่: รายงานปลอมจาก AI ทำให้ผู้ดูแลติดขัด ทำไมนักพัฒนาจากไต้หวันและทีมพัฒนาต้องปรับตัว

เช้าวันจันทร์หนึ่ง ผู้ดูแลโปรเจกต์โอเพ่นซอร์สเปิดอีเมลและพบว่ามีรายงานช่องโหว่ใหม่หลายสิบใบ ทุกใบมีรูปแบบเรียบร้อย มีคะแนน CVSS, ขั้นตอนการทำซ้ำ, และข้อเสนอแนะแก้ไข ผู้ดูแลใช้เวลาตลอดเช้าเพื่อตรวจสอบแต่ละใบ ผลลัพธ์ส่วนใหญ่ชี้ไปที่ฟังก์ชันที่ไม่มีอยู่จริงหรืออธิบายพฤติกรรมปกติว่าเป็นการ越界หน่วยความจำ รายงานที่แท้จริงที่ควรแก้ไขมีเพียงหนึ่งใบและเคยได้รับการรายงานมาก่อนแล้ว

การทำงานเช่นนี้ซ้ำ ๆ ทำให้ Google ตัดสินใจปิดประตู

เหตุการณ์เบื้องหลัง

โปรแกรมรางวัลการเปิดเผยช่องโหว่ของ Google (OSS VRP) เปิดตัวในปี 2022 เพื่อส่งเสริมผู้วิจัยด้านความปลอดภัยให้รายงานช่องโหว่ในโปรเจกต์โอเพ่นซอร์สของ Google เช่น Go, Angular, Bazel, Protocol Buffers ฯลฯ หากพบช่องโหว่จริงจะได้รับรางวัล

ในต้นเดือนตุลาคม Google ประกาศผ่านบัญชีผู้ล่าอุบัติการณ์และหน้ากฎของโปรแกรมว่า ตั้งแต่วันที่ 1 ตุลาคม 2026 จะหยุดรับรายงานช่องโหว่ผลิตภัณฑ์ OSS VRP เหตุผลที่ให้คือการส่งรายงานอัตโนมัติเพิ่มขึ้นอย่างมากและส่วนใหญ่ไม่เป็นจริง หลายสื่อด้านความปลอดภัยอ้างว่า รายงานหลายใบมีเนื้อหาฮอลูซิเนชันหรือเป็นปัญหาที่มีผลกระทบเล็กน้อย

นี่ไม่ใช่ครั้งแรก curl, เครื่องมือส่งข้อมูลโอเพ่นซอร์ส, ปิดโปรแกรมรางวัลบน HackerOne เนื่องจากรายงาน AI ปริมาณมาก Malwarebytes ยังกล่าวว่า Intel ไม่ตั้งรางวัลในโปรแกรม Intigriti เพื่อหลีกเลี่ยงปัญหานี้ ในเดือนมีนาคมของปีนี้ Anthropic, Google, Microsoft, GitHub, OpenAI และ AWS ได้สัญญาให้เงิน 12.5 ล้านดอลลาร์กับ Alpha-Omega และ OpenSSF เพื่อจัดการปริมาณงานของผู้ดูแลโอเพ่นซอร์ส

จุดสำคัญของครั้งนี้

หยุดอะไร: ตั้งแต่วันที่ 1 ตุลาคม OSS VRP จะไม่รับรายงานช่องโหว่ผลิตภัณฑ์อีกต่อไป
ไม่กระทบ: รายงานที่ส่งก่อนวันที่ 1 ตุลาคมจะได้รับการดำเนินการตามปกติ; โปรแกรม VRP อื่น ๆ และโปรแกรมรางวัลการแก้ไข (Patch Rewards Program) ไม่ได้รับผลกระทบ และบางช่องโหว่ผลิตภัณฑ์อาจยังรับผ่าน Cloud VRP
ระยะเวลา: อย่างน้อยจนถึงไตรมาสแรกของปี 2027 Google จะประกาศแนวทางการปรับปรุง
ไม่มีข้อมูล: Google ไม่ได้เปิดเผยปริมาณการรับหรืออัตราส่วนของรายงานที่ไม่เป็นจริง

การวิเคราะห์ผลกระทบต่อตลาด

นักวิจัยความปลอดภัยในไต้หวัน

นักวิจัยสีขาวในไต้หวันมีส่วนร่วมในโปรแกรมรางวัลช่องโหว่ระดับสากลอย่างต่อเนื่อง หลายคนสร้างผลงานจากรางวัลของ Google และ Microsoft การหยุดชั่วคราวนี้ทำให้มีเวทีน้อยลงในระยะสั้น แต่ในระยะยาวอาจทำให้เกณฑ์เข้มขึ้น: การมี PoC ที่ทำซ้ำได้, คำอธิบายผลกระทบที่แม่นยำ, ความพร้อมในการสื่อสารกับผู้ดูแล จะกลายเป็นข้อกำหนดพื้นฐาน ไม่ใช่แค่ข้อได้เปรียบ

การใช้ AI ช่วยค้นหาช่องโหว่ไม่ใช่ปัญหา; เครื่องมือการทดสอบเจาะอัตโนมัติอย่าง XBOW เป็นวิธีที่ถูกต้อง ปัญหาคือ “AI บอกว่ามีแล้วส่งตรง” ฉันแนะนำอย่างง่าย ๆ: ก่อนส่งรายงาน ให้ลองรัน PoC ในสภาพแวดล้อมสะอาด หากไม่สามารถทำได้ ไม่ควรส่ง

การใช้งานในองค์กร

องค์กรในไต้หวันที่มีช่องทางการเปิดเผยช่องโหว่ (VDP) หรือมีรางวัลบนแพลตฟอร์มควรคาดหวังว่ารายงาน AI จะเพิ่มขึ้น ในการปฏิบัติจริง สามารถทำได้สามอย่าง: กำหนดให้แนบ PoC ที่สามารถรันได้ก่อนเข้าสู่การตรวจสอบด้วยมือ, ตั้งขีดจำกัดการส่งจากบัญชีเดียวกัน, ให้ทีมความปลอดภัยใช้กฎหรือโมเดลเพื่อกรองรายงานในรอบแรก Malwarebytes ยังแนะนำว่า การกรองรายงาน AI แล้วส่งเฉพาะผลที่ผ่านการตรวจสอบให้กับวิศวกรเป็นแนวทางที่ทำได้

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

วิธีสังเกตรายงานที่น่าสงสัย? จากประสบการณ์ของผู้ดูแลหลายคน มีลักษณะทั่วไป: ชื่อฟังก์ชันหรือเส้นทางไฟล์ที่อ้างอิงไม่พบในโปรเจกต์; ระดับความรุนแรงสูงแต่คำอธิบายผลกระทบยังอยู่ที่ “อาจทำให้เกิด”; ขั้นตอนการทำซ้ำเป็นเพียงคำอธิบายข้อความ ไม่มีสคริปต์ที่รันได้; บัญชีเดียวกันส่งรายงานที่มีโครงสร้างใกล้เคียงกันในโปรเจกต์ต่าง ๆ ในช่วงเวลาสั้น ๆ สัญญาณเหล่านี้แยกกันอาจไม่ชัดเจน แต่ถ้ารวมกันก็สมควรจัดเป็นคิวความสำคัญต่ำก่อน ไม่ให้วิศวกรผู้มีประสบการณ์ต้องหยุดงานเพื่อทำตาม

นักพัฒนา

ถ้าคุณดูแลโปรเจกต์โอเพ่นซอร์ส เหตุการณ์นี้เป็นโอกาสให้คุณทบทวนไฟล์ SECURITY.md: ระบุหลักฐานที่ต้องการอย่างชัดเจน, ไม่ยอมรับผลการสแกนอัตโนมัติที่ยังไม่ได้ตรวจสอบ, วิธีติดต่อคืออะไร การที่โปรเจกต์ถูกพุ่งน้ำท่วมมักเป็นเพราะกฎไม่ได้ระบุไว้ล่วงหน้า

การใช้ตัวแทนเช่น Claude Code ในการตรวจสอบโค้ดก็เหมือนกัน: “ข้อสงสัยว่ามีช่องโหว่” ควรถือเป็นเบาะแส ไม่ใช่ข้อสรุป ทีมสามารถนำกระบวนการเข้ามาใช้ตามตัวอย่างของเราใน AI โปรแกรมตรวจสอบโค้ด เพื่อทำให้ขั้นตอนการยืนยันด้วยมือเป็นขั้นตอนที่แน่นอน

แนวโน้มในอนาคต

ระบบรางวัลช่องโหว่มีพื้นฐานว่า “การค้นหาช่องโหว่ยาก ดังนั้นจึงควรจ่ายเงิน” AI ทำให้ “รายงานที่ดูเหมือนช่องโหว่” ถูกสร้างได้อย่างอ่อนแอ ทำให้พื้นฐานนี้ถูกท้าทาย ฉันคาดว่าโปรแกรมในอนาคตจะมีการปรับเปลี่ยนหลายรูปแบบ: การยืนยันตัวตนหรือเกณฑ์ความน่าเชื่อถือก่อนส่ง, การบังคับให้แนบ PoC ที่ทำซ้ำได้, การระงับบัญชีสำหรับรายงานที่ไม่เป็นจริง, หรือแม้กระทั่งการเก็บเงินมัดจำเล็กน้อย

ในขณะเดียวกัน AI ยังช่วยค้นหาช่องโหว่จริงได้จริง จึงไม่ควรปิดกั้นทั้งหมด ความสำคัญคือ “มีคนรับผิดชอบผลลัพธ์หรือไม่” Google อาจจะมีกฎใหม่ในไตรมาสแรกของปี 2027 ที่จะกลายเป็นแบบอย่างสำหรับโปรแกรมใหญ่ ๆ อื่น ๆ และควรได้รับความสนใจจากวงการความปลอดภัยในไต้หวัน

สรุปและความคิดเห็นของ TheAI Academy

AI ทำให้การค้นหาช่องโหว่เร็วขึ้น แต่ทำให้ “ปลอมว่าพบช่องโหว่” เกิดขึ้นได้ฟรีแทบ; ค่าบริการสุดท้ายคือผู้ดูแลที่ต้องจ่าย

ถามเพื่อนที่ดูแลโปรเจกต์โอเพ่นซอร์ส ฉันพบว่าความกลัวที่ใหญ่ที่สุดคือการได้รับรายงานที่ดูเป็นมืออาชีพแต่จริง ๆ แล้วไม่มีอยู่จริง คุณต้องใช้เวลามากกว่าผู้ส่งหลายเท่าเพื่อพิสูจน์ว่ามันไม่มี Google หยุดชั่วคราวเพื่อปกป้องเวลาของผู้ดูแล สำหรับผู้อ่านในไต้หวัน นักวิจัยควรให้ PoC เป็นมารยาทพื้นฐาน, องค์กรควรสร้างระบบกรองรายงาน AI, นักพัฒนาควรเขียนกฎการเปิดเผยอย่างชัดเจน เครื่องมือจะแข็งแกร่งขึ้น แต่ “ฉันได้ตรวจสอบแล้ว” ควรเป็นคำพูดของมนุษย์

แหล่งข้อมูล

บทความนี้จัดทำจากข้อมูลสาธารณะ ขอบเขตการหยุด, ช่องทางการรับ, และกำหนดการฟื้นฟูตามประกาศอย่างเป็นทางการของ Google Bug Hunters.