GitHub ให้ AI ดักรหัสลับก่อน push เร็วขึ้น 86% แต่ยังต้องมีคนตัดสิน

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

ส่วนการบล็อกรหัสลับทั่วไปก่อนรับ push ยังอยู่ใน private preview ตามประกาศของ GitHub วันที่ 7 ตุลาคม 2026 ซึ่งวางแผนขยายให้แก่องค์กรที่มี GitHub Secret Protection บน Enterprise Cloud หรือ GitHub Teams ภายในเดือนนั้น และระบุว่าการตรวจส่วนนี้จะใช้ AI credits ตัวจำแนกประเมินชุดค่าที่สงสัยได้ภายในเวลาไม่ถึงสองมิลลิวินาที แต่ความเร็วของโมเดลไม่ได้ตัดงานของผู้ดูแลออก Erin Havens ผู้จัดการผลิตภัณฑ์ของ GitHub สรุปภาระเมื่อรหัสหลุดไว้ว่า “remediation still scales with people”

ตัวจำแนกแยกรหัสจริงจากค่าตัวอย่างอย่างไร

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

ระบบใหม่แบ่งการตรวจเป็นสองช่วง ช่วงแรกใช้กฎ regex คัดข้อความที่อาจเป็นโทเคน คีย์ หรือรหัสผ่านอย่างกว้าง เพื่อส่งค่าที่เข้าข่ายไปตรวจต่อ ช่วงที่สองให้ ModernBERT ซึ่งปรับแต่งสำหรับงานนี้อ่านค่าที่สงสัยพร้อมชนิดของรหัส ชื่อไฟล์ ชื่อตัวแปร และโค้ดหรือข้อความใกล้เคียง จากนั้นระบบใช้คะแนนของตัวจำแนกตัดสินว่าจะส่งผลตรวจพบต่อหรือระงับค่าที่น่าจะเป็นผลบวกลวง

บริบทของไฟล์ทำให้ข้อความหน้าตาเหมือนกันมีน้ำหนักต่างกัน รหัสผ่านข้าง URL ของฐานข้อมูลใช้งานจริงชวนให้สงสัยมากกว่าค่ารูปทรงเดียวกันในชุดข้อมูลทดสอบ เช่นเดียวกับ connection string ในไฟล์ตั้งค่าการติดตั้งที่ต่างจากตัวอย่าง localhost ในคู่มือ ระบบจึงพิจารณาทั้งตำแหน่งและข้อความรอบค่า ไม่ได้ตัดสินจากความซับซ้อนของตัวอักษรเพียงอย่างเดียว

GitHub ยกตัวอย่างค่า changeme ที่ใช้แทนรหัสในตัวอย่าง และค่าที่ดูคล้ายรหัสใน URL ฐานข้อมูล ไฟล์ Kubernetes Secret หรือ Dockerfile คำว่า changeme เป็นเบาะแสว่าผู้เขียนต้องการให้เปลี่ยนค่าในภายหลัง แต่เบาะแสเดียวไม่พอสำหรับยกเว้นทุกกรณี หากมีผู้ใช้ค่าลักษณะนี้เป็นข้อมูลรับรองที่ระบบยอมรับจริง ความเสี่ยงก็ยังอยู่

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

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

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

ความเร็ว 86% วัดตรงไหนของเส้นทางตรวจ

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

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

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

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

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

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

ก่อนรับ push กับหลัง commit ให้ผลต่างกัน

Push protection ตรวจการเปลี่ยนแปลงก่อน GitHub ยอมรับ push เข้าคลังระยะไกล หากพบค่าที่เข้าข่าย ระบบสามารถหยุดการส่งเพื่อให้ผู้ส่งนำค่าออกจาก commit ที่กำลังส่ง จังหวะนี้สำคัญเพราะข้อมูลรับรองยังไม่เข้าสู่ประวัติของคลังบน GitHub แม้นักพัฒนาอาจสร้าง commit ไว้ในเครื่องตนเองแล้วก็ตาม

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

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

ขอบเขตการเปิดใช้ก็ต่างกัน องค์กรที่ใช้การตรวจรหัสด้วย AI หลัง push ถูกย้ายไปใช้โมเดลใหม่แล้วตามประกาศผลิตภัณฑ์ ส่วนการตรวจรหัสลับทั่วไปใน push protection ยังต้องอยู่ภายใต้ private preview และการตั้งค่าของผู้ดูแล สิทธิ์ใช้ GitHub Secret Protection กับการเปิดใช้คุณสมบัติใหม่นี้จึงเป็นคนละเรื่องที่ทีมต้องแยกให้ชัด

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

• ระบบทำอัตโนมัติ: คัดค่าที่คล้ายข้อมูลรับรอง อ่านบริบท ระงับค่าที่น่าจะเป็นตัวอย่าง และส่งผลที่มีความเสี่ยงไปยังการบล็อกหรือรายการแจ้งเตือนตามจุดตรวจ
• ส่วนที่ต้องมีสิทธิ์และเปิดใช้: การบล็อกรหัสทั่วไปก่อนรับ push อยู่ใน private preview โดยแผนขยายการเข้าถึงผูกกับ GitHub Secret Protection และ AI credits
• ส่วนที่ยังต้องตัดสิน: ผู้ดูแลต้องกำหนดนโยบายข้อยกเว้น ตรวจเหตุผลของการขอผ่านการบล็อก และประสานการจัดการรหัสที่เข้าสู่คลังแล้ว

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

ข้อยกเว้นแบบใดที่คนยังต้องตัดสิน

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

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

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

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

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

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

อ่านเพิ่มเติม:

• กัน API key หลุดบน GitHub: Push Protection ข้ามไฟล์เกิน 50 MB
• ต่อ GitHub Actions เข้า AWS ด้วย OIDC: จำกัดสิทธิ์ถึง repo และ branch
• Cursor หรือ GitHub Copilot: ค่ารายเดือนต่ำไม่ได้ล็อกค่าเอเจนต์