รหัสผ่านหลุด GitHub คือปัญหาที่นักพัฒนาเผลอฝังรหัสผ่าน คีย์ API หรือข้อมูลเข้าฐานข้อมูลไว้ในโค้ด แล้วอัปโหลดขึ้น GitHub แบบสาธารณะ ใครก็ค้นเจอและนำไปใช้เข้าระบบได้ บทความนี้เหมาะกับเจ้าของธุรกิจที่จ้าง outsource ทำเว็บหรือแอป ฝ่ายไอที และ DPO จะได้รู้ว่าความเสี่ยงใหญ่แค่ไหน และต้องเขียนอะไรในสัญญา
ลองนึกภาพบริษัท 20 คนที่จ้างฟรีแลนซ์ทำระบบหลังบ้าน งานส่งมอบเรียบร้อย แต่ในโค้ดเวอร์ชันแรก ๆ มีรหัสเข้าฐานข้อมูลลูกค้าติดอยู่ และ repository นั้นเปิดเป็นสาธารณะมาสองปี งานวิจัยล่าสุดเรื่องรหัสผ่านหลุด GitHub บอกว่าภาพนี้เกิดขึ้นแล้วหลายแสนครั้ง
สรุปสั้น: Truffle Security สแกน GitHub สาธารณะ 224 ล้าน repository พบข้อมูลยืนยันตัวตนที่ยังใช้งานได้ 543,699 รายการ เปิดค้างเฉลี่ย (ค่ากลาง) 784 วัน และกว่าครึ่งเป็นประเภทที่ระบบกันของ GitHub ไม่บล็อก ฝั่งไทย สกมช. ชี้ว่าเหตุรั่วของรัฐมาจากรหัสผ่านที่หลุด บริษัทที่จ้าง outsource จึงควรห้ามเก็บ secret ในโค้ดไว้ในสัญญา และสแกน repository ก่อนรับมอบงาน
รหัสผ่านหลุด GitHub คืออะไร งานวิจัยพบอะไร
รหัสผ่านหลุด GitHub ในงานวิจัยนี้หมายถึงข้อมูลยืนยันตัวตน (credentials) ที่ยังใช้งานได้จริงและอยู่ในไฟล์บน GitHub สาธารณะ BleepingComputer รายงานเมื่อ 30 กันยายน 2569 ว่า Truffle Security สแกน 224 ล้าน repository และไฟล์กว่า 58,000 ล้านไฟล์ พบรายการที่ยังใช้ได้ 543,699 รายการ ใน 1.1 ล้านไฟล์
ตัวเลขที่น่าห่วงคือระยะเวลา ค่ากลางที่ข้อมูลเหล่านี้เปิดเผยต่อสาธารณะคือ 784 วัน และราว 10% เก่ากว่า 6.3 ปี ส่วน 51.8% เป็นประเภทที่ระบบ Push Protection ของ GitHub ไม่บล็อก เช่น database connection string และ Google API key
| ประเด็น | ข้อเท็จจริงตามข่าว |
|---|---|
| ขอบเขตการสแกน | 224 ล้าน repository · ไฟล์กว่า 58,000 ล้านไฟล์ |
| ที่ยังใช้ได้ | 543,699 รายการ ใน 1.1 ล้านไฟล์ |
| เปิดค้าง | ค่ากลาง 784 วัน · ราว 10% เก่ากว่า 6.3 ปี |
| ระบบกันไม่บล็อก | 51.8% เช่น connection string, Google API key |
| Google Cloud service account | ยังใช้ได้ 69,041 จาก 126,963 รายการ |
| ฝั่งไทย | สกมช. ชี้เหตุรั่วของรัฐมาจากรหัสผ่านที่หลุด เตรียมสำรวจ 300 กรมและบังคับ MFA (Daily News, 6 ส.ค. 2569) |
รหัสผ่านหลุด GitHub กระทบธุรกิจไทยอย่างไร
รหัสผ่านหลุด GitHub กระทบธุรกิจไทยที่มีทีมพัฒนาเองหรือจ้าง outsource เพราะช่องโหว่แบบเดียวกันเปิดอยู่ทุกที่ที่มีคนเก็บ connection string หรือ API key ไว้ในโค้ด ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน
บทเรียนจากรัฐไทยคืออะไร
บทเรียนจากรัฐไทยคือการรั่วส่วนใหญ่ไม่ได้มาจากแฮกเกอร์เก่ง แต่มาจากรหัสผ่านที่หลุดออกไปแล้วไม่มีใครเปลี่ยน Daily News รายงานเมื่อ 6 สิงหาคม 2569 ว่าเลขาธิการ สกมช. ระบุว่าเหตุข้อมูลรั่วของหน่วยงานรัฐเกิดจากการเข้าระบบโดยมิชอบด้วย username/password ที่หลุด และรัฐเตรียมสำรวจ 300 กรมพร้อมบังคับใช้ MFA
บริษัทที่จ้าง outsource ต้องรับผิดไหม ถ้าคีย์หลุดจากโค้ดของผู้รับจ้าง
บริษัทที่จ้าง outsource ยังต้องรับผิดในฐานะผู้ควบคุมข้อมูล เพราะ PDPA มาตรา 37(1) วางหน้าที่จัดมาตรการรักษาความมั่นคงปลอดภัยไว้ที่ผู้ควบคุมข้อมูล ถ้าข้อมูลลูกค้ารั่วเพราะคีย์ในโค้ดของผู้รับจ้าง ลูกค้าและ สคส. จะถามบริษัทก่อน แล้วบริษัทค่อยไปไล่เบี้ยกับผู้รับจ้างตามสัญญา ถ้าสัญญาไม่ได้เขียนไว้ การไล่เบี้ยก็ยากขึ้นมาก
ข้อสัญญาที่ควรมีคือ ห้ามเก็บ secret ไว้ในโค้ด ต้องสแกน repository รวมประวัติย้อนหลังก่อนส่งมอบ และต้องเปลี่ยนคีย์ทันทีเมื่อพบว่าหลุด ดูแนวคิดการคุมผู้ให้บริการภายนอกเพิ่มได้ที่ 44 รัฐสหรัฐฯ ปรับ Labcorp $2.3M เพราะ vendor ทำข้อมูลรั่ว บทเรียน Vendor Governance ที่ธุรกิจไทยใช้ได้ทันที
สตาร์ทอัพที่ให้ AI เขียนโค้ดเสี่ยงเพิ่มไหม
สตาร์ทอัพที่ให้ AI ช่วยเขียนโค้ดควรระวังเป็นพิเศษ เพราะโค้ดที่สร้างเร็วมักถูกอัปโหลดเร็วโดยไม่มีคนตรวจ ความเสี่ยงแบบเดียวกันเคยเกิดกับฐานข้อมูลที่เปิดโล่ง อ่านได้ที่ ฐานข้อมูล Supabase กว่า 16,000 ชุดเปิดโล่ง ส่วนใหญ่สร้างด้วย Vibe Coding สตาร์ทอัพไทยที่ให้ AI เขียนแอปต้องเช็กอะไร
ทำไมเครื่องมือของ GitHub อย่างเดียวไม่พอ
เครื่องมือของ GitHub อย่างเดียวไม่พอ เพราะ 51.8% ของรายการที่พบเป็นประเภทที่ Push Protection ไม่บล็อก ผู้เขียนมองว่ารหัสที่หลุดแล้วใช้ได้นานกว่า 2 ปีโดยเฉลี่ยบอกว่าปัญหาอยู่ที่กระบวนการ การหมุนเวียนรหัสและการตั้ง secret ให้หมดอายุอัตโนมัติจึงควรเขียนไว้ในนโยบายความปลอดภัยขององค์กร
ถ้าไม่ทำอะไรเลย จะเสี่ยงอะไร
ถ้าไม่ทำอะไรเลยเรื่องรหัสผ่านหลุด GitHub คีย์ที่หลุดไปแล้วจะยังเปิดประตูเข้าระบบได้ต่อไปเรื่อย ๆ เพราะไม่มีใครเปลี่ยน ถ้าคีย์นั้นเข้าถึงฐานข้อมูลลูกค้า ธุรกิจต้องรับภาระแจ้งเหตุตาม PDPA และตอบคำถามว่ามีมาตรการรักษาความปลอดภัยที่เหมาะสมหรือไม่ ทั้งที่ต้นเหตุคือบรรทัดเดียวในโค้ด และถ้าสัญญากับ outsource ไม่ได้เขียนเรื่องนี้ไว้ ความเสียหายทั้งหมดก็ตกที่ผู้ว่าจ้าง
บริษัทที่มีทีมพัฒนาหรือจ้าง outsource ควรทำอะไรตอนนี้
บริษัทที่มีทีมพัฒนาหรือจ้าง outsource ควรรับมือรหัสผ่านหลุด GitHub โดยเริ่มจากหา secret ที่หลุดอยู่แล้วก่อน แล้วค่อยปิดช่องในสัญญาและนโยบาย เพื่อไม่ให้รหัสผ่านหลุด GitHub ซ้ำอีก
- 1. สแกนหา secret ในทุก repository รวมประวัติย้อนหลัง ใช้เครื่องมือสแกน secret ไล่ทั้ง repository ภายในและที่เคยเปิดสาธารณะ
- 2. เปลี่ยนทุกคีย์ที่พบภายใน 7 วัน อย่าแค่ลบบรรทัดออกจากโค้ด เพราะประวัติเก่ายังเก็บคีย์เดิมไว้
- 3. เพิ่มข้อสัญญากับผู้พัฒนาภายนอก ห้ามเก็บ secret ในโค้ด ต้องสแกนก่อนส่งมอบ และต้องร่วมเปลี่ยนคีย์เมื่อพบว่าหลุด
- 4. เขียนนโยบาย rotation และวันหมดอายุของ secret กำหนดรอบเปลี่ยนคีย์ และใช้ secret ที่หมดอายุเองเมื่อทำได้
- 5. เปิด MFA ให้บัญชีผู้ดูแลระบบทุกบัญชี เพื่อให้รหัสผ่านที่หลุดอย่างเดียวเข้าระบบไม่ได้
ถ้าต้องการคนช่วยตรวจสัญญาจ้างพัฒนาซอฟต์แวร์และนโยบายความปลอดภัย ดูรายละเอียดได้ที่ บริการ AI Governance และ PDPA ของ Kooru และอ่านประเด็นกฎหมายเทคโนโลยีอื่นได้ที่ หมวด Tech Law & IP
มุมมองผู้เชี่ยวชาญ
เวลาตรวจสัญญาจ้างพัฒนาซอฟต์แวร์ ผมเห็นข้อเรื่องทรัพย์สินทางปัญญายาวหลายหน้า แต่เรื่องรหัสลับในโค้ดแทบไม่มีใครเขียน คีย์ที่หลุดไม่ได้หมดอายุเองเหมือนนมในตู้เย็น มันใช้ได้จนกว่าจะมีคนเปลี่ยน ข้อสัญญาสามบรรทัดเรื่องห้ามเก็บ secret สแกนก่อนส่งมอบ และหน้าที่เปลี่ยนคีย์ ใช้ต้นทุนเกือบศูนย์ แต่เปลี่ยนคนที่ต้องรับผิดได้ทั้งหมด
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
คำถามที่พบบ่อยเกี่ยวกับรหัสผ่านหลุด GitHub
มีรหัสผ่านหลุดบน GitHub ที่ยังใช้งานได้กี่รายการ
งานวิจัยของ Truffle Security ที่ BleepingComputer รายงาน พบข้อมูลยืนยันตัวตนที่ยังใช้งานได้ 543,699 รายการ ใน 1.1 ล้านไฟล์ จากการสแกน 224 ล้าน repository สาธารณะ
ลบรหัสผ่านออกจากโค้ดแล้ว ปลอดภัยหรือยัง
ยังไม่ปลอดภัย เพราะประวัติของ repository ยังเก็บเวอร์ชันเก่าที่มีรหัสอยู่ วิธีที่ถูกคือเปลี่ยนรหัสหรือคีย์นั้นใหม่ทันที ให้ตัวเก่าใช้ไม่ได้อีก
ระบบกันรหัสหลุดของ GitHub ช่วยได้แค่ไหน
ช่วยได้บางส่วน งานวิจัยพบว่า 51.8% ของรายการที่ยังใช้ได้เป็นประเภทที่ Push Protection ของ GitHub ไม่บล็อก เช่น database connection string และ Google API key องค์กรจึงควรสแกนเพิ่มเองและวางกระบวนการเปลี่ยนคีย์
จ้าง outsource เขียนโค้ดแล้วข้อมูลรั่ว ใครรับผิด
ผู้ว่าจ้างในฐานะผู้ควบคุมข้อมูลยังมีหน้าที่จัดมาตรการรักษาความมั่นคงปลอดภัยตาม PDPA มาตรา 37(1) การไล่เบี้ยกับผู้รับจ้างขึ้นอยู่กับสัญญา จึงควรเขียนหน้าที่เรื่อง secret ไว้ให้ชัดตั้งแต่ต้น
แหล่งอ้างอิง
- BleepingComputer (อ้างงานวิจัย Truffle Security) — (อ่านต้นฉบับ) — อ่านรายงานที่ BleepingComputer
- Daily News — (อ่านต้นฉบับ) — อ่านข่าว สกมช. ที่ Daily News
อ่านหลักการคัดเลือกและตรวจสอบข่าวของเราได้ที่ นโยบายบรรณาธิการ
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
