GitHub เพิ่มตัวตนผู้ Push Commit ที่ยืนยันได้ แยกจาก Author และ Committer

GitHub ประกาศวันที่ 12 ตุลาคม 2026 ว่าจะบันทึกตัวตนของผู้ที่ push commit เข้า repository ในฐานะข้อมูลที่ผ่านการยืนยันตัวตน แยกจากชื่อ author และ committer ที่อยู่ใน commit เดิม พร้อมกฎใหม่ Committer must match pusher สำหรับ repository ruleset ความสามารถนี้อยู่ใน limited public preview สำหรับลูกค้า GitHub Enterprise จึงยังไม่ควรเขียนแผน rollout โดยสมมติว่าทุกองค์กรเปิดใช้ได้ทันที

ทำไม author กับ committer ไม่พอ

ใน Git commit มีฟิลด์ author และ committer ที่ client ส่งมาเป็นข้อความชื่อกับอีเมล ผู้มีสิทธิ์เขียน repository สามารถตั้งค่าฟิลด์เหล่านี้เองได้ ในการร่วมพัฒนาแบบปกตินี่เป็นเรื่องจำเป็น เช่น ผู้เขียน patch อาจไม่ใช่คนกด merge แต่ในมุม audit ฟิลด์นี้ไม่ใช่หลักฐานว่าบัญชีใดเป็นผู้ส่ง commit ไปยัง GitHub หากบัญชีสิทธิ์ต่ำถูกยึด ผู้โจมตีอาจตั้งชื่อ committer ให้ดูเหมือนผู้ดูแลที่เชื่อถือได้ แล้วทำให้คนตรวจโค้ดหรือระบบรายงานสับสน

GitHub ยืนยันตัวตนผู้ push อยู่แล้วตอนรับข้อมูล แต่ประกาศใหม่นี้ทำให้ข้อมูล pusher ถูกผูกกับ commit อย่างคงทนและแสดงใน UI กับ API ควบคู่กับ author/committer ทีม security จึงตรวจได้ว่า “ใครอ้างว่าเขียน” กับ “บัญชีใดส่งขึ้นมา” เป็นคนเดียวกันหรือไม่ โดยไม่ต้องไล่หา event ใน audit log ช่วงเวลาหนึ่งอย่างเดียว ข้อมูลนี้เป็นอีกมิติของ provenance ไม่ได้พิสูจน์ว่าผู้ push เป็นผู้พิมพ์โค้ดทุกบรรทัด และไม่ได้แทน code review

กฎใหม่ทำงานอย่างไร

Repository ruleset สามารถใช้เงื่อนไข Committer must match pusher เพื่อปฏิเสธ push เมื่อ committer metadata ไม่ตรงกับอีเมลที่ยืนยันแล้วของบัญชีผู้ push การนำไปใช้ต้องระวัง workflow ที่ถูกต้องตามงาน เช่น bot, service account, merge automation, การ cherry-pick หรือทีมที่ commit ในนามผู้อื่น หากเปิดกฎโดยไม่สำรวจ flow เหล่านี้ อาจบล็อก pipeline หรือรอบ release ได้ ควรเริ่มด้วยการเก็บตัวอย่าง commit จริงและแยกกรณีที่เจตนาถูกต้องก่อน

มาตรการนี้มุ่งลดการปลอม committer จากบัญชีที่มีสิทธิ์ push ไม่ได้แก้ทุกทางของ supply-chain attack หากบัญชี maintainer จริงถูกขโมย ผู้โจมตียังใช้ตัวตนที่ตรงตามกฎได้ จึงต้องใช้ MFA, การจำกัดสิทธิ์, branch protection, การตรวจ PR และการเฝ้าดูเหตุผิดปกติร่วมกัน การเห็น pusher identity ช่วยให้การสืบสวนเร็วขึ้น แต่ไม่ควรใช้แทนการตรวจว่าการเปลี่ยนโค้ดได้รับอนุมัติตามนโยบายหรือไม่

แนวทางทดลองในองค์กร

ลูกค้า Enterprise ที่ต้องการเข้า preview ต้องติดต่อ account team ตามประกาศ ก่อนทดลองควรเลือก repository ที่มีรูปแบบการ push ชัดเจน ตรวจ commit จากนักพัฒนาและ bot แล้วบันทึกว่าข้อมูล pusher ปรากฏตรงไหนใน UI/API เตรียม dashboard หรือขั้นตอน spot-check สำหรับกรณี author/committer ดูผิดปกติ จากนั้นค่อยกำหนด ruleset เฉพาะ repository ที่ไม่มีข้อยกเว้นซับซ้อน หากจำเป็นต้องยกเว้น automation ควรทำโดยมีเจ้าของและเหตุผลชัดเจน

เมื่อพบ commit น่าสงสัย ให้ใช้ pusher identity เป็นจุดเริ่มต้นถามต่อว่าบัญชีนั้นใช้ token ใด push, มีการอนุมัติ PR หรือไม่ และมีการแก้ workflow file หรือ secret หรือไม่ การสรุปจากชื่อ author อย่างเดียวไม่พอ และการสรุปจาก pusher อย่างเดียวก็ยังไม่ครบ เพราะ credential อาจถูกใช้โดยผู้อื่น ข่าวนี้จึงสำคัญต่อทีมที่ต้องพิสูจน์ที่มาของการเปลี่ยนโค้ดโดยเฉพาะ ไม่ใช่แค่เพิ่มอีกคอลัมน์ในหน้ารายการ commit

อ่านประกาศต้นทางวันที่ 12 ตุลาคม 2026: GitHub Changelog — Push attribution for commits in limited public preview