รหัสลับหลุดในโค้ดตรวจยากเพราะอะไร: GitHub ใช้โมเดล AI ขนาดเล็กอ่านบริบทรอบโค้ด เจอรหัสลับจริงมากขึ้น เตือนผิดน้อยลง และตรวจได้ตั้งแต่ก่อน push

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

รหัสลับหลุดเข้าโค้ดได้อย่างไร

รหัสลับ (secret) คือข้อมูลที่ให้สิทธิ์เข้าถึงระบบ เช่น รหัสผ่านฐานข้อมูล กุญแจ API ของบริการคลาวด์ หรือโทเค็นของระบบชำระเงิน มักหลุดเข้าโค้ดเพราะความเร่ง เช่น ใส่รหัสไว้ในไฟล์ตั้งค่าตอนทดสอบแล้วลืมเอาออก หรือเผลอ commit ไฟล์ .env ไปด้วย ปัญหาคือเมื่อ push ขึ้นไปแล้ว รหัสจะอยู่ในประวัติของ repository แม้ลบในรุ่นถัดไปก็ยังค้นเจอได้ ทางแก้จริงจึงต้องเปลี่ยนรหัสใหม่ ไม่ใช่แค่ลบบรรทัดนั้น

ทำไมตรวจด้วยรูปแบบตัวอักษรอย่างเดียวไม่พอ

รหัสลับบางชนิดตรวจง่าย เพราะมีคำนำหน้า ความยาว หรือรหัสตรวจสอบที่เป็นเอกลักษณ์ แต่รหัสลับทั่วไป เช่น รหัสผ่านที่ตั้งเอง หน้าตาเหมือนสตริงอื่นในโค้ดแทบทุกอย่าง ทั้งหมายเลข build ค่า checksum และค่าตัวอย่าง ถ้าใช้ regex (กฎค้นหาตามรูปแบบตัวอักษร) กว้างพอจะจับรหัสจริง ก็จะจับของปลอมมาด้วยจำนวนมาก ถ้าเพิ่มข้อยกเว้นเพื่อลดคำเตือนผิด ก็เสี่ยงซ่อนรหัสจริงไปด้วย GitHub สรุปว่าสิ่งที่ตัดสินได้จริงคือบริบท รหัสผ่านที่อยู่ข้างที่อยู่ฐานข้อมูลของระบบจริงน่าจะเป็นของจริง ส่วนค่าเดียวกันในไฟล์ทดสอบน่าจะไม่มีอันตราย

แนวทางของ GitHub: ค้นให้กว้างก่อน แล้วกรองด้วยบริบท

ระบบใหม่แบ่งงานเป็นสองขั้น ขั้นแรกใช้ regex หาตัวเลือกให้ครบที่สุด ซึ่งเร็วและให้ผลเหมือนเดิมทุกครั้ง ขั้นที่สองส่งตัวเลือกแต่ละตัวให้โมเดลจำแนกที่ปรับจาก ModernBERT (โมเดลภาษาขนาดเล็กที่ถนัดอ่านและจัดประเภทข้อความ) โดยส่งค่าที่พบ ที่อยู่ไฟล์ ชนิดของรหัส และโค้ดรอบ ๆ ในช่วงจำกัด โมเดลเรียนรู้สัญญาณอย่างคำว่า example, dummy หรือ replace-me ซึ่งลดความเสี่ยง และการกำหนดค่าให้ตัวแปรสภาพแวดล้อมในไฟล์ deploy ซึ่งเพิ่มความเสี่ยง จุดสำคัญคือโมเดลไม่ได้แทน regex แต่ช่วยตัดสินผลของ regex แล้วแปลงเป็นรูปแบบ ONNX บีบขนาดเหลือ 8 บิต จึงรันได้ถูกและเร็วกว่าการเรียกโมเดลภาษาขนาดใหญ่มาก

ข้อมูลฝึกมาจากไหน

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

ทีมพัฒนาควรทำอะไรต่อ

• เปิด push protection ให้ระบบบล็อกตั้งแต่ก่อนรหัสเข้า repository ซึ่งแก้ง่ายกว่าตามลบภายหลังมาก
• เก็บรหัสไว้นอกโค้ด ใช้ตัวแปรสภาพแวดล้อมหรือระบบจัดการรหัสลับของคลาวด์ และใส่ .env ใน .gitignore ตั้งแต่วันแรก
• ค่าตัวอย่างให้เห็นชัดว่าเป็นตัวอย่าง เช่น replace-me ช่วยทั้งคนอ่านและเครื่องตรวจ
• ถ้าหลุดแล้ว ให้ยกเลิกและออกรหัสใหม่ก่อน แล้วค่อยลบออกจากโค้ด เพราะประวัติ commit ยังเก็บของเดิมไว้
• แจ้งคำเตือนผิดกลับไป GitHub ระบุว่าจะนำผลตอบรับจากการใช้งานจริงไปฝึกโมเดลรุ่นถัดไป

ทีมพัฒนาไทยจำนวนมากยังส่งรหัสผ่านกันในแชตหรือใส่ไว้ในไฟล์ตั้งค่าใน repository ซึ่งเสี่ยงทั้งข้อมูลลูกค้าและค่าใช้จ่ายคลาวด์ที่อาจถูกนำไปใช้ ดูตัวอย่างความเสียหายจริงได้ที่กุญแจ AWS หลุดกว่า 9,300 ชุดที่ยังใช้งานได้ และGitHub บล็อกการรวม pull request ที่มีความลับหลุด ทีมงาน Smart Cyber Tech วางระบบ CI/CD ที่ตรวจรหัสลับให้อัตโนมัติ พร้อมย้ายรหัสเดิมออกจากโค้ดอย่างปลอดภัย ปรึกษาได้ที่ แบบฟอร์มติดต่อ