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

การสร้างรายงานช่องโหว่ที่ดูน่าเชื่อถือมีต้นทุนลดลงเรื่อย ๆ ส่งผลให้ผู้ดูแลซอฟต์แวร์และทีมรักษาความปลอดภัยต้องเผชิญผลกระทบที่รุนแรงขึ้น ในเดือนกรกฎาคม 2026 มีการเผยแพร่ช่องโหว่และความเสี่ยงทั่วไป (CVE) จำนวน 6 รายการที่ระบุว่าเกี่ยวข้องกับ SQLite และ 2 รายการในนั้นได้รับคะแนนความรุนแรง 9.8 รายงานเหล่านี้ดูน่าเชื่อถือ โดยอธิบายข้อบกพร่องด้านความปลอดภัยของหน่วยความจำ พร้อมคำอธิบายทางเทคนิคและโค้ดพิสูจน์แนวคิด

แต่ นักวิจัยของ JFrog พบว่าฟังก์ชันบางส่วนที่รายงานเหล่านี้กล่าวถึงไม่มีอยู่ในเวอร์ชันที่ได้รับผลกระทบ ยิ่งไปกว่านั้น ไม่มีโค้ดพิสูจน์แนวคิด (PoC) ชิ้นใดที่ทำให้เกิดช่องโหว่ตามที่กล่าวอ้างได้จริง ขณะนี้หน้า CVE ของ SQLite ระบุว่ารายงานทั้ง 6 รายการนี้ไม่ใช่ข้อบกพร่อง และต่อมาระเบียน CVE เหล่านี้ก็ถูกปฏิเสธ

ปัญหานี้ไม่ได้จำกัดอยู่แค่ SQLite แดเนียล สเตนเบิร์ก ผู้ดูแล curl ประเมินเมื่อปีที่แล้วว่า รายงานด้านความปลอดภัยที่ส่งเข้ามาราว 20% เป็นผลงานจากเนื้อหาขยะที่สร้างด้วย AI หน่วยงานกำหนดหมายเลข CVE (CNA) ของ GitHub ได้รับคำขอ CVE เกือบ 4,000 รายการในเดือนพฤษภาคม 2026 ซึ่งมีปริมาณเพิ่มขึ้นราว 10 เท่าเมื่อเทียบกับปีก่อนหน้า GitHub ไม่ได้ระบุว่า AI เป็นสาเหตุของการเพิ่มขึ้นนี้ และไม่ได้กล่าวว่าคุณภาพการส่งรายงานลดลง แต่ปริมาณที่เพิ่มขึ้นมหาศาลสะท้อนให้เห็นว่ากระบวนการเปิดเผยช่องโหว่กำลังรับภาระหนักเกินไป

AI ช่วยให้การสร้างข้อกล่าวอ้างเกี่ยวกับช่องโหว่ที่มีรายละเอียดทำได้ง่ายขึ้น แต่การตรวจสอบว่าข้อกล่าวอ้างเหล่านั้นถูกต้องหรือไม่นั้นใช้เวลามาก และเมื่อ CVE เข้าไปอยู่ในฟีดข้อมูลด้านความปลอดภัยและฐานข้อมูลสาธารณะแล้ว การแก้ไขระเบียนต้นทางก็ไม่ได้หมายความว่าสำเนาทุกชุดจะได้รับการแก้ไขโดยอัตโนมัติ จึงยิ่งจำเป็นต้องแยกแยะระหว่างช่องโหว่ที่มีผู้รายงานกับช่องโหว่ที่ผ่านการตรวจสอบทางเทคนิคแล้ว

CVE “ปลอม” คืออะไร?

ผู้คนมักใช้คำว่า “CVE ปลอม” เพื่อกล่าวถึง CVE ที่น่าจะมีการรายงานผิดพลาด แต่คำว่า “ปลอม” ไม่ได้หมายความว่ามีเจตนาหลอกลวงเสมอไป เรื่องนี้อาจเกิดจากการวิเคราะห์แบบสถิตที่มองข้ามการตรวจสอบความถูกต้อง หรือเข้าใจผิดว่าผู้โจมตีควบคุมข้อมูลนำเข้าได้ รายงานอาจอธิบายฟังก์ชันที่มีอยู่จริง แต่กล่าวอ้างเส้นทางการโจมตีที่ใช้ไม่ได้ อาจมีการกำหนดตัวระบุ (CVE ID) ให้แล้ว แต่ภายหลังถูกยกเลิก หากเงื่อนไขที่รายงานนั้นไม่ใช่ช่องโหว่จริง ซึ่งแตกต่างจากรายงานที่แต่งขึ้นโดยเจตนา

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

เหตุใด CVE ปลอมจึงเป็นปัญหา

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

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

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

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

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

รับมือด้วยระบบอัตโนมัติ

ผู้ตรวจสอบจำนวนมากยังคงคัดกรองรายงานด้วยตนเองเพื่อรับมือกับรายงานที่หลั่งไหลเข้ามาใหม่ แต่แนวทางนี้ไม่ยั่งยืน ระบบอัตโนมัติเป็นเครื่องมือช่วยตรวจสอบข้อกล่าวอ้างเกี่ยวกับช่องโหว่ โดยเทียบกับรุ่นและการกำหนดค่าที่ได้รับผลกระทบจริงได้อย่างมีประสิทธิภาพ ต่อไปนี้คือคำถาม 5 ข้อที่ควรถาม:

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

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

รับมือกับปัญหาล้นมือในระบบนิเวศ CVE

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

ทีมรักษาความปลอดภัยและผู้จำหน่ายต้องมุ่งตรวจสอบหลักฐาน คะแนน CVE ระดับวิกฤตไม่ได้บอกว่าเส้นทางที่มีช่องโหว่สามารถเข้าถึงได้ในสภาพแวดล้อมของตนหรือไม่ การที่ PoC ใช้งานไม่ได้ไม่ได้หมายความว่าทุกอย่างปลอดภัย และการได้รับ CVE ID ก็ไม่ได้เป็นข้อยกเว้นให้ทีมละเว้นงานด้านเทคนิคที่จำเป็นต่อการทำความเข้าใจปัญหา

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