GitHub เปิดตัวโมเดลตรวจจับความลับใหม่ แม่นยำขึ้นและประหยัดกว่าเดิม

ไปป์ไลน์ใหม่ของเราเทียบกับไปป์ไลน์ LLM เดิม

การสแกนความลับที่ชาญฉลาดขึ้น ในราคาเพียงเศษเสี้ยว

การยอมรับที่สูงขึ้น 11.5%

ความแม่นยำของการแจ้งเตือนแบบถ่วงน้ำหนักตามเจ้าของ

เวลาการสแกนเฉลี่ยลดลง 86%

สำหรับการสแกนหลังการ Push (Post-push scanning)

ค่าบริการลดลง 98%

เมื่อใช้โมเดลขนาดกะทัดรัดเทียบกับการเรียก LLM จากระยะไกล

การสแกนความลับจะทำงานได้ดีที่สุดเมื่อนักพัฒนามีความมั่นใจในสิ่งที่ระบบตรวจพบ หากตรวจจับได้น้อยเกินไป ข้อมูลระบุตัวตน (credentials) จริงอาจค้างอยู่ใน repository แต่ถ้าแจ้งเตือนบ่อยเกินไป นักพัฒนาก็ต้องเสียเวลาตรวจสอบสตริงที่ไม่ใช่ความลับ

ความลับแบบทั่วไป (Generic secrets) มักจะสร้างความสับสนได้ง่าย เพราะสตริงเดียวกันอาจเป็นข้อมูลระบุตัวตนจริงหรือเป็นเพียงตัวอย่างในเอกสาร (documentation placeholder) ดังนั้นการตรวจจับที่มีประสิทธิภาพจึงต้องอาศัยการทำความเข้าใจรหัสและข้อความโดยรอบ เพื่อแก้ปัญหานี้ เราได้ฝึกฝนตัวจำแนกความลับ (secret classifier) โดยเฉพาะสำหรับ GitHub เพื่อแยกแยะข้อมูลระบุตัวตนจริงออกจากสิ่งที่ดูคล้ายกัน โดยยังคงตอบโจทย์ด้านความเร็วและประสิทธิภาพในระดับสเกลใหญ่

ในบทความ Secret protection must scale with software เราได้อธิบายถึงเหตุผลที่การป้องกันความลับต้องก้าวให้ทันการพัฒนาที่เร่งด้วย AI ส่วนในบทความนี้ เราจะพาไปดูเบื้องหลังของ context-aware classifier ว่าเราออกแบบและฝึกฝนอย่างไรเพื่อให้พบความลับจริงมากขึ้นโดยมีสิ่งรบกวนน้อยลง

สิ่งที่เราทำให้เกิดขึ้น

การสแกนความลับของ GitHub ทำงานในสองช่วงเวลาสำคัญ:

• Push protection: ป้องกันไม่ให้ความลับเข้าสู่ repository โดยสแกนก่อนที่การ push จะถูกตอบรับ
• Post-push scanning: ทำงานหลังจากโค้ดถูก commit ไปแล้ว โดยสแกนเนื้อหาอย่างต่อเนื่องเพื่อสร้างการแจ้งเตือน

เราได้พัฒนาตัวจำแนกที่รวดเร็วซึ่งช่วยลดเวลาการสแกน post-push เฉลี่ยลง 86% เมื่อเทียบกับไปป์ไลน์ที่ใช้ LLM เดิม ประสิทธิภาพที่เพิ่มขึ้นนี้ทำให้เราสามารถขยายการตรวจจับความลับทั่วไปไปยัง push protection ได้จริง ช่วยแสดงผลลัพธ์ให้นักพัฒนาเห็นก่อนที่จะ push การเปลี่ยนแปลงสำเร็จ

การสแกนความลับบล็อกการ commit ด้วย push protection หลังจากโมเดลตรวจพบความลับในบรรทัดที่ 5 ของไฟล์

ทำไมความลับถึงตรวจจับได้ยาก

ข้อมูลระบุตัวตนที่มีโครงสร้างชัดเจนมักจะมีรูปแบบที่แน่นอน แต่ความลับทั่วไปอาจไม่มีไวยากรณ์พิเศษ และมักไปซ้อนทับกับตัวระบุการบิลด์ (build identifiers), checksum หรือค่าตัวอย่างต่างๆ บริบทจึงเป็นสัญญาณสำคัญในการตัดสินใจ

กรณีเหล่านี้คือ hard negatives หรือสตริงที่ตรงรูปแบบแต่ไม่ใช่ความลับจริง การใช้ตัวจำแนกที่ผ่านการเรียนรู้จะช่วยให้ระบบมองเห็นสัญญาณรอบข้าง เช่น พาธของไฟล์, ชื่อตัวแปร และรหัสที่อยู่ใกล้เคียงได้แม่นยำกว่าการใช้กฎ (rules) เพียงอย่างเดียว

นั่นคือเหตุผลที่เราเปิดตัวสแกนเนอร์ใหม่ที่ใช้ไปป์ไลน์สองขั้นตอน:

1. Candidate generation: ใช้ Regex สแกนหาความลับที่อาจเป็นไปได้ด้วย recall ที่สูงเพื่อไม่ให้พลาดเป้าหมายสำคัญ
2. Context-aware classification: ใช้ ModernBERT ที่ผ่านการ fine-tuned มาประเมินบริบทโดยรอบ เพื่อคัดกรองสัญญาณหลอก เช่น ค่า placeholder หรือตัวอย่างในเอกสาร เนื่องจากโมเดลมีขนาดเล็กจึงประเมินผลได้เร็วและมีค่าบริการถูกกว่าการใช้ LLM ขนาดใหญ่

ผลกระทบที่เกิดขึ้น:

• การยอมรับของผู้ใช้ดีขึ้น 11.5% ช่วยลด false positives
• เวลาการสแกน post-push เร็วขึ้น 86%
• ประหยัดค่าใช้จ่ายได้มากกว่า 98%

ไปป์ไลน์ของเราทำงานอย่างไร

ระบบจะเริ่มจากใช้ Regex กวาดหาข้อมูลที่ดูเหมือนข้อมูลระบุตัวตนในวงกว้าง จากนั้นจะส่งต่อให้ ModernBERT วิเคราะห์ร่วมกับพาธไฟล์และชื่อตัวแปร หากมีความมั่นใจสูงระบบจะสร้างการแจ้งเตือนทันที ส่วนสิ่งที่ดูคล้ายแต่ไม่ใช่ความลับจะถูกกรองออก

ขั้นตอนการทำงาน (How our pipeline works)

1. สแกน: ครอบคลุมเนื้อหาใน Repository, commit และ pull request
2. สร้างผู้สมัคร: ใช้ Regex ระบุโทเค็นและคีย์ที่อาจเป็นความลับ
3. จำแนกประเภท: ModernBERT ประเมินผู้สมัครร่วมกับบริบทเพื่อระบุความเป็นไปได้
4. แจ้งเตือนหรือระงับ: ส่งต่อเฉพาะสิ่งที่มั่นใจสูง และกรอง false positives ทิ้ง

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

โมเดลตัวจำแนกพยายามอย่างเต็มที่เพื่อแยกแยะความลับจริงออกจากข้อมูลที่ดูคล้ายกัน

ปัญหา Hard-negative: ความลับที่ดูเกือบจะจริง

False positives ส่วนใหญ่คือ hard negatives เช่น placeholder ในเอกสาร หรือ ID ที่ไม่ละเอียดอ่อน ซึ่งยากที่ระบบ Rule-based จะแยกแยะได้โดยไม่ทำให้ความลับจริงหลุดรอดไป

ModernBERT เข้ามาช่วยได้เพราะสามารถเข้าใจบริบทได้ใกล้เคียงกับ LLM แต่ไม่มีความล่าช้า (latency) สูง ตัวอย่างเช่น หากพบคำว่า "example" หรือ "dummy" อยู่ใกล้ๆ สตริงนั้นจะถูกมองว่ามีความเสี่ยงต่ำทันที โดยที่เราไม่ต้องเขียนกฎข้อยกเว้นใหม่ทุกครั้ง

เราเลือก ModernBERT เพราะขนาดกะทัดรัดและมีประสิทธิภาพสูงในการจำแนกข้อความที่อยู่ติดกับโค้ด ซึ่งเหมาะสมกว่าการใช้ LLM อเนกประสงค์ทั้งในแง่ของทรูพุต (throughput) และการปรับแต่งขอบเขตการตัดสินใจให้เข้ากับงานเฉพาะทาง

วิธีที่เราฝึกฝน

เราใช้ข้อมูลจากสามแหล่งหลักในการฝึกฝนโมเดล:

• ตัวอย่างจริงจาก GitHub repositories ที่ผ่านการตรวจสอบโดยมนุษย์
• ข้อมูลจาก Regex ที่มี recall สูงเพื่อขยายการครอบคลุม
• ตัวอย่างสังเคราะห์ (Synthetic examples) สำหรับกรณีที่หายาก เช่น ความลับในไฟล์เอกสารหรือคู่คีย์สาธารณะ

ข้อมูลทั้งหมดจะถูกจัดกลุ่มเพื่อป้องกันข้อมูลซ้ำซ้อนระหว่างการฝึกและการประเมินผล นอกจากนี้เรายังเน้นให้โมเดลเห็นตัวอย่างที่น่าสับสนบ่อยๆ เพื่อให้เรียนรู้ลักษณะของ false positive ในบริบทจริง โดยโมเดลที่ฝึกสำเร็จจะถูกส่งออกในรูปแบบ ONNX พร้อมทำ 8-bit quantization เพื่อการอนุมานที่รวดเร็วที่สุด

ผลการประเมิน

จากการทดสอบ A/B พบว่าไปป์ไลน์ใหม่ไม่เพียงแต่ทำงานได้เร็วขึ้น แต่ยังมีความแม่นยำ (precision) และการครอบคลุม (recall) ที่สูงขึ้นอย่างมีนัยสำคัญเมื่อเทียบกับระบบ LLM เดิม

บทสรุปและก้าวต่อไป

ความแม่นยำที่สูงขึ้นหมายถึงการรบกวนนักพัฒนาน้อยลง และต้นทุนที่ต่ำลงทำให้เราสามารถขยายการปกป้องให้ครอบคลุมทุกขั้นตอนการทำงานได้มากขึ้น ระบบไฮบริดที่รวมพลังของ Regex และ ModernBERT จึงเป็นคำตอบที่ลงตัวที่สุดสำหรับ GitHub

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

กิตติกรรมประกาศ

ขอขอบคุณทีมวิศวกรรม วิทยาศาสตร์ และผลิตภัณฑ์ทั่วทั้ง GitHub และ Microsoft ที่มีส่วนร่วมในการพัฒนาเครื่องสแกนความลับรุ่นใหม่นี้