FlawDetector-LLM V1.0: การทดลองซ้ำ 1,000 ครั้ง และสิ่งที่ความแปรปรวนบอกเรา

ค่าเฉลี่ยตัวเดียวเปลี่ยนเบนช์มาร์กให้กลายเป็นการตลาด

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

ถ้าข้อบกพร่องที่เป็นระดับวิกฤตในวันจันทร์หายไปในวันศุกร์ ไม่ว่าอัตราตรวจพบจะเป็น 94% หรือ 97% ทีมก็เลิกเชื่อผลลัพธ์ไปแล้ว ประสบการณ์ที่คำตัดสินเปลี่ยนทั้งที่โค้ดไม่เปลี่ยนเพียงครั้งเดียวก็เพียงพอ สิ่งแรกที่เราตัดสินใจในการออกแบบการทดลอง V1.0 จึงไม่ใช่ “จะดันค่าเฉลี่ยขึ้นอย่างไร” แต่เป็น “จะวัดอย่างไรว่าอินพุตเดียวกันให้คำตอบเดียวกัน”

การออกแบบการทดลอง: อะไรถูกทำซ้ำ 1,000 ครั้ง

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

การทดลองซ้ำทำกับตัวอย่างที่สุ่มแบบแบ่งชั้นจำนวน 1,200 ราย โดยแต่ละรายทำซ้ำมากกว่า 1,000 ครั้ง รวมคำตัดสินกว่า 1.2 ล้านครั้ง เหตุผลของขนาดนี้ตรงไปตรงมา เมื่ออัตราความไม่สอดคล้องลดต่ำกว่า 1% การทำซ้ำ 100 ครั้งไม่สามารถแยกมันออกจากสัญญาณรบกวนในช่วงความเชื่อมั่นที่ใช้ประโยชน์ได้

ตัวเลขสรุปของ FlawDetector-LLM V1.0

ตัวเลข 3.2% ไม่ใช่ค่าดิบ ผลรอบแรกจากเอนจินมีอัตราผลบวกลวง 5.8% แล้วการตัดซ้ำและการจัดอันดับตามการเข้าถึงได้จึงลดลงมาเหลือ 3.2% เราเปิดเผยทั้งสองค่าเพราะการให้เฉพาะค่าหลังการประมวลผลทำให้เปรียบเทียบไม่ได้

ความแปรปรวนอยู่ตรงไหน

ค่ารวม 99.1% ซ่อนการกระจายที่กว้างระหว่างตระกูลข้อบกพร่อง จุดที่น่าสนใจในตารางด้านล่างคืออัตราตรวจพบกับความสม่ำเสมอขยับไปด้วยกัน ตระกูลที่เราตรวจได้แย่ที่สุดก็คือตระกูลที่คำตัดสินสั่นมากที่สุด

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

ทำไมจึงสั่น

เราสุ่มกรณีไม่สอดคล้องราวหนึ่งหมื่นกรณีมาจำแนกสาเหตุ สามข้ออธิบายได้เกือบทั้งหมด

1. 01ขอบของชังก์ (54%) — ตรรกะตรวจสอบกับจุดใช้งานถูกตัดแยกไปคนละชังก์ โมเดลจึงตัดสินจากครึ่งที่ตัวเองเห็น และครึ่งไหนที่เห็นก็ขยับเล็กน้อยในแต่ละรอบ
2. 02การตัดบริบท (29%) — ในไฟล์ขนาดใหญ่ ส่วน import และการตั้งค่าด้านบนถูกตัดทิ้ง โมเดลจึงไม่รู้ว่าไลบรารีใดมีการป้องกันมาให้แล้ว ผลบวกลวงแบบ “ORM ผูกพารามิเตอร์ให้อยู่แล้วแต่ถูกมองว่าเป็น raw SQL” เกิดขึ้นตรงนี้
3. 03ความไวต่อลำดับ (13%) — ชุดชังก์เดียวกันแต่ลำดับการนำเสนอต่างกันทำให้คำตัดสินพลิก โดยมักปรากฏเป็นระดับความรุนแรงขยับขึ้นลงหนึ่งขั้น

เราเปลี่ยนอะไรบ้าง

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

1. 01

   Anchored chunking — จัดขอบให้ตรงกับโครงสร้างโค้ด

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

2. 02

   Symbol-graph prepass — วาดแผนที่ก่อนอ่าน

   ก่อนเรียก LLM เราให้ตัวแยกวิเคราะห์แบบสถิตสร้างกราฟการเรียกและบทสรุปการไหลของข้อมูล แล้วแนบเป็นส่วนหัวของแต่ละชังก์ โมเดลจึงรู้เสมอว่าฟังก์ชันนี้ถูกเรียกจากสามที่และสองในนั้นเป็นจุดเข้าจากภายนอก ความสม่ำเสมอ 98.0% → 98.7%

3. 03

   โหวตสามครั้ง — ดูดซับการสั่นที่เหลือ

   เฉพาะรายการที่มีแนวโน้มความรุนแรงสูงขึ้นไป เราสลับลำดับการนำเสนอชังก์แล้วตัดสินสามครั้งและถือเสียงข้างมาก เนื่องจากจำกัดขอบเขตไว้ที่รายการเหล่านั้น เวลารวมจึงเพิ่มเพียง 9% ความสม่ำเสมอ 98.7% → 99.1%

ผลบวกลวงลดลงเป็นผลพลอยได้ เมื่อ prepass ทำให้การป้องกันที่มากับเฟรมเวิร์กมองเห็นได้ ผลบวกลวงต่อโค้ดที่ใช้ ORM เทมเพลตเอนจิน และมิดเดิลแวร์ตรวจสอบก็ลดลงอย่างเห็นได้ชัด จาก 5.8% เหลือ 4.1% ในผลรอบแรก และ 3.2% หลังการประมวลผลเพิ่มเติม

คอขวดที่เหลือ และ V1.1

ความสม่ำเสมอถูกซื้อมาด้วยเวลาแฝง การเพิ่ม prepass เปลี่ยนรูปร่างของการสแกนไป

ผลของ prepass จะไม่เปลี่ยนหากไฟล์ไม่เปลี่ยน มันจึงเป็นการคำนวณที่แคชได้ แต่ V1.0 กลับทำใหม่ทุกครั้ง แคชแบบเพิ่มหน่วยจึงเป็นการปรับปรุงที่แน่นอนที่สุดใน V1.1 และยิ่งสแกนซ้ำบ่อยเท่าไรผลตอบแทนยิ่งมาก สภาพแวดล้อม CI จึงได้ประโยชน์มากที่สุด

ห้าคำถามสำหรับอ่านเบนช์มาร์กความปลอดภัย

ใช้กับตัวเลขของเราเองได้เท่ากับของคนอื่น ห้าคำถามนี้กรองการกล่าวเกินจริงออกไปได้เกือบหมด

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

สรุป

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

ทุกรายการถูกจัดการเป็นเอกสารเกณฑ์การทดสอบภายใน และรายงานฉบับเต็มซึ่งรวมองค์ประกอบคลังข้อมูลและโปรโตคอลการทำซ้ำ สามารถขอรับได้