สรุปสั้น
บริษัท Google หยุดรับรายงานช่องโหว่ประเภท “ช่องโหว่ผลิตภัณฑ์” (product vulnerability) ผ่านโครงการ Open Source Software Vulnerability Reward Program (OSS VRP) ตั้งแต่วันที่ 1 ตุลาคม 2569 ทำให้นักวิจัยไม่สามารถส่งช่องโหว่ในโค้ดของโครงการโอเพนซอร์สของ Google อย่าง Go, Angular และ Protocol Buffers เพื่อรับรางวัลผ่านช่องทางนี้ได้อีก Google โพสต์บน X ว่าเป็นการหยุดชั่วคราว เนื่องจาก “รายงานอัตโนมัติเพิ่มขึ้นอย่างมีนัยสำคัญ ซึ่งส่วนใหญ่ไม่ถูกต้อง” แต่ไม่ได้ให้ตัวเลข และไม่ได้ระบุว่ารายงานเหล่านั้นสร้างด้วยเครื่องมือ AI หรือไม่
กฎของโครงการมีประกาศว่า Google จะอัปเดตความคืบหน้าในไตรมาสแรกของปี 2570 ระหว่างปรับโครงสร้างส่วนนี้ แต่ไม่ได้กำหนดวันกลับมารับรายงาน รายงานที่ส่งก่อน 1 ตุลาคมไม่ได้รับผลกระทบ และรางวัลสำหรับช่องโหว่ห่วงโซ่อุปทาน เช่น ช่องทางที่ทำให้แก้ไขซอร์สโค้ดหรือแพ็กเกจที่เผยแพร่ได้ ยังคงอยู่ตามเดิม รวมถึงปัญหาความปลอดภัยอื่นอย่างข้อมูลรับรองที่รั่วจนเขียนโค้ดได้ ส่วนนักวิจัยที่พบช่องโหว่ผลิตภัณฑ์ถูกแนะนำให้ไปใช้ Cloud VRP, Patch Rewards Program หรือโครงการรางวัลอื่นของ Google แทน
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 6 ตุลาคม 2569 ว่า Google เพิ่มประกาศการหยุดรับรายงานลงในกฎของ OSS VRP โดยการเปลี่ยนแปลงเดียวกันนี้ลบอัตรารางวัลของช่องโหว่ผลิตภัณฑ์ออก ซึ่งเดิมอยู่ที่ 500 ถึง 7,500 ดอลลาร์สำหรับโครงการระดับ flagship และ 101 ถึง 3,133.7 ดอลลาร์สำหรับระดับ important การแก้ไขนี้ถูกเผยแพร่ในสำเนากฎบน GitHub สาธารณะของ Google เมื่อวันที่ 30 กันยายน หนึ่งวันก่อนโพสต์บน X
ตามกฎ ช่องโหว่ผลิตภัณฑ์หมายถึงข้อบกพร่องด้านการออกแบบหรือการเขียนโค้ดในซอฟต์แวร์โอเพนซอร์สของ Google ที่กระทบความลับหรือความถูกต้องของข้อมูลผู้ใช้ในซอฟต์แวร์ที่สร้างจากโค้ดนั้นอย่างมีนัยสำคัญ ตัวอย่างเช่น memory corruption ในตัวแยกวิเคราะห์รูปแบบไฟล์ และ path traversal โครงการแบ่งรีโพสิทอรีเป็น 4 ระดับตามความอ่อนไหว รายการล่าสุดเมื่อกลางเดือนกันยายนมีรีโพสิทอรีระดับ flagship 26 รายการ เช่น Go, Angular, Flutter, Bazel และ Protocol Buffers และระดับ important 47 รายการ
| ประเภท | Flagship | Important | Standard |
|---|---|---|---|
| ช่องโหว่ห่วงโซ่อุปทาน | 3,133.7–31,337 ดอลลาร์ | 1,337–13,337 ดอลลาร์ | 500–3,133.7 ดอลลาร์ |
| ช่องโหว่ผลิตภัณฑ์ | ไม่มี (เดิม 500–7,500 ดอลลาร์) | ไม่มี (เดิม 101–3,133.7 ดอลลาร์) | ไม่มี |
| ปัญหาความปลอดภัยอื่น | 1,000 ดอลลาร์ | 500 ดอลลาร์ | ไม่มี |
ระดับที่สี่สำหรับโครงการที่มีความสำคัญต่ำไม่มีรางวัลอยู่แล้ว ทั้งโพสต์และประกาศไม่ได้บอกว่า Google จะยังรับรายงานช่องโหว่ผลิตภัณฑ์แบบไม่มีรางวัลหรือไม่
รายละเอียดการเปลี่ยนแปลง
ประกาศของ Google ระบุช่องทางสำรอง 3 ทาง ทางแรกคือ Cloud VRP ซึ่งอาจยังรับรายงานช่องโหว่ผลิตภัณฑ์ของรีโพสิทอรี Google Cloud บางแห่งที่กระทบผลิตภัณฑ์คลาวด์ แต่ไม่ได้ระบุว่าแห่งใด และตามกฎ Cloud VRP ช่องโหว่ในรีโพสิทอรีโอเพนซอร์สที่ Google Cloud ดูแลจะถูกจัดระดับสูงสุดที่ IT3b ซึ่งเป็นระดับสำหรับผลิตภัณฑ์ที่ซื้อกิจการมาหรือมีความสำคัญต่ำ ทางที่สองคือ Patch Rewards Program ซึ่งจ่าย 100 ถึง 15,000 ดอลลาร์สำหรับแพตช์ความปลอดภัย ไม่ใช่สำหรับรายงานช่องโหว่ โดยแพตช์ต้องได้รับการยอมรับจากผู้ดูแลโครงการและอยู่ในโค้ดครบหนึ่งเดือนก่อนส่ง และแพตช์ที่แก้ช่องโหว่เพียงรายการเดียวจะพิจารณาเป็นรายกรณี ทางที่สามคือโครงการรางวัลอื่นของ Google เช่น AI VRP สำหรับโครงการที่ผูกกับผลิตภัณฑ์ AI
นโยบายของแต่ละโครงการเองก็ชี้ไปคนละทาง Go รับรายงานทางอีเมลของทีมความปลอดภัยของตนเอง นโยบายความปลอดภัยในองค์กร GitHub ของ Google ส่งผู้รายงานไปที่ g.co/vulnz ขณะที่นโยบายของ Angular ณ วันที่ 6 ตุลาคม ยังระบุว่า Angular อยู่ใน OSS VRP ส่งรายงานไปที่เว็บไซต์ Bug Hunters และไม่ได้ระบุช่องทางอื่น ซึ่งอาจทำให้นักวิจัยสับสนว่าควรส่งรายงานที่ใด
การเปลี่ยนแปลงครั้งนี้ต่อยอดจากมาตรการก่อนหน้า OSS VRP เปิดตัวในเดือนสิงหาคม 2565 และในเดือนมีนาคม 2569 Google เริ่มกำหนดให้บางระดับต้องแนบหลักฐานที่หนักแน่นขึ้น เช่น แพตช์ที่ถูก merge เข้าโครงการแล้ว เพื่อกรองรายงานคุณภาพต่ำ InfoWorld รายงานในตอนนั้นว่าทีมกังวลเรื่องรายงานที่สร้างด้วย AI ซึ่งหลายฉบับแต่งรายละเอียดวิธีกระตุ้นช่องโหว่ขึ้นเอง ส่วนโครงการ Go ก็เพิ่มหัวข้อเรื่องรายงานจาก LLM ลงในนโยบายความปลอดภัยเมื่อต้นเดือนกันยายน ระบุว่า LLM เก่งทั้งการหาบั๊กความปลอดภัยจริงและการรายงานบั๊กที่ไม่มีอยู่จริง และผู้ที่ส่งต่อผลลัพธ์ LLM ที่ไม่ได้กรองจำนวนมากจะไม่ได้รับเครดิต
ผลกระทบ
ผลกระทบโดยตรงตกอยู่กับนักวิจัยความปลอดภัยที่ทำงานกับโครงการโอเพนซอร์สของ Google ซึ่งเสียแรงจูงใจทางการเงินในการรายงานช่องโหว่ผลิตภัณฑ์ อย่างน้อยจนถึงต้นปี 2570 ความเสี่ยงที่ตามมาคือช่องโหว่บางส่วนอาจไม่ถูกรายงาน หรือถูกส่งไปยังตลาดอื่นที่ให้ค่าตอบแทน ขณะที่ช่องทางสำรองแต่ละทางมีเงื่อนไขแคบกว่าเดิม เช่น Patch Rewards ที่ต้องเขียนแพตช์เองและรอให้อยู่ในโค้ดหนึ่งเดือน
ในภาพกว้าง ข่าวนี้สะท้อนปัญหาที่โครงการบั๊กบาวน์ตีหลายแห่งเผชิญ คือรายงานที่สร้างจากเครื่องมืออัตโนมัติหรือ LLM จำนวนมากที่ดูน่าเชื่อแต่ใช้ไม่ได้ ทำให้ทีมคัดกรองเสียเวลาและอาจพลาดรายงานจริงที่ปนอยู่ การที่ผู้ให้รางวัลรายใหญ่อย่าง Google เลือกปิดหมวดนี้แทนที่จะคัดกรองต่อ แสดงว่าต้นทุนการคัดกรองสูงจนกระทบการทำงาน ผู้ดูแลโครงการโอเพนซอร์สรายอื่นที่ไม่มีทรัพยากรเท่า Google ก็มีแนวโน้มเผชิญปัญหาเดียวกัน ส่วนที่ Google ยังคงไว้คือรางวัลด้านห่วงโซ่อุปทาน ซึ่งชี้ว่าบริษัทยังให้น้ำหนักกับความเสี่ยงที่ผู้โจมตีจะแก้ไขโค้ดหรือแพ็กเกจที่ผู้ใช้จำนวนมากดาวน์โหลด
คำแนะนำ
- นักวิจัยที่พบช่องโหว่ในโครงการโอเพนซอร์สของ Google ให้ตรวจนโยบาย SECURITY.md ของแต่ละโครงการก่อนส่ง และใช้ช่องทางของโครงการโดยตรง เช่น อีเมลทีมความปลอดภัยของ Go หรือ g.co/vulnz
- ตรวจว่าช่องโหว่เข้าข่ายโครงการรางวัลอื่นหรือไม่ เช่น Cloud VRP สำหรับรีโพสิทอรีที่กระทบ Google Cloud หรือ AI VRP สำหรับโครงการที่ผูกกับผลิตภัณฑ์ AI
- ผู้ที่ใช้ LLM ช่วยค้นหาช่องโหว่ ควรยืนยันผลด้วยตนเองและแนบ PoC ที่ทำซ้ำได้ก่อนรายงาน เพื่อไม่ให้รายงานถูกมองเป็นรายงานคุณภาพต่ำ
- ผู้ดูแลโครงการโอเพนซอร์สควรกำหนดนโยบายรับรายงานจาก AI ให้ชัด และกำหนดหลักฐานขั้นต่ำ เช่น PoC หรือแพตช์ เพื่อลดภาระการคัดกรอง
- องค์กรที่พึ่งพา Go, Angular, Protocol Buffers หรือโครงการอื่นของ Google ควรติดตามประกาศความปลอดภัยของโครงการโดยตรง และใช้เครื่องมือตรวจ dependency อย่างต่อเนื่อง