GitHub Public Monitoring เพิ่มตรวจ Token ยังใช้ได้ พร้อม REST API และ Webhook

GitHub Public Monitoring เพิ่มการจัดคิว alert ตรวจ token validity อัตโนมัติ REST API และ enterprise webhooks ตามประกาศวันที่ 23 ตุลาคม 2026 ช่วยให้ทีมความปลอดภัยนำ finding ของความลับที่รั่วบนพื้นที่สาธารณะเข้าสู่ incident pipeline ได้สะดวกขึ้น ฟีเจอร์ยังเป็น public preview สำหรับ GitHub Enterprise Cloud ตามเงื่อนไขที่ประกาศ

ปิด Alert ไม่ได้ยกเลิก Credential

ผู้ดูแล dismiss เปิดใหม่ และดู timeline ของ alert ได้ พร้อมกรองตามข้อมูลที่เกี่ยวข้อง ประกาศย้ำว่าการปิด alert เปลี่ยนสถานะสำหรับ enterprise เท่านั้น ไม่ได้ revoke credential และไม่ได้ลบค่าที่รั่วออกจาก public repository ความต่างนี้ควรอยู่ใน runbook อย่างชัดเจนเพื่อไม่ให้สถานะบน dashboard ถูกใช้แทนการปิดความเสี่ยงจริง

ระบบตรวจ validity ต่อเนื่องสำหรับ secret types ที่รองรับ โดยแสดง Active, Inactive หรือ Unknown สถานะ Unknown จึงไม่ควรถูกแปลว่า token ใช้ไม่ได้แล้ว ทีมต้องอ่านความหมายของ provider และชนิด secret นั้นเพิ่มเติม รวมถึงยืนยันการหมุนหรือยกเลิก credential จากระบบเจ้าของโดยตรง

เชื่อม Incident Pipeline อย่างไร

REST endpoint ที่ประกาศคือ GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts และ webhook event ชื่อ secret_scanning_public_monitoring_alert ที่ระดับ enterprise การเชื่อมต่อควรเริ่มจากระบบรับเหตุที่เก็บ metadata เท่าที่จำเป็น ไม่ส่ง secret ที่พบต่อไปใน ticket หรือแชตโดยไม่มีข้อกำหนดการเข้าถึง

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

จัดลำดับด้วยหลักฐานที่มี

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

GitHub ระบุว่ารวม Public Monitoring ใน license GitHub Advanced Security หรือ Secret Protection ตามเงื่อนไขของบริการ ผู้ดูแลควรตรวจสิทธิ์และ eligibility ขององค์กรจริงก่อนวาง rollout เกณฑ์สำเร็จคือเวลาจากตรวจพบถึงจำกัดความเสี่ยงและยืนยันผล ไม่ใช่จำนวน alert ที่ปิด การมี API และ webhook ช่วยลดงานส่งต่อ แต่การยืนยันว่าความลับถูกจัดการแล้วต้องมาจากกระบวนการตอบสนองที่ครบถ้วน

แหล่งข่าว: ประกาศทางการวันที่ 23 ตุลาคม 2026