Secret รั่วใน repo และ pipeline: ตรวจหา หมุนเปลี่ยน และสิ่งที่ควรขอตอนส่งมอบ

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

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

เรื่อง secret ในที่นี้หมายถึงอะไร

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

คำนี้ต่างจากคำว่า credential leak ที่คนไทยมักใช้ถึงรหัสผ่านของพนักงานที่หลุดจากเหตุข้อมูลรั่วไหล ฝั่งนั้นมีบริการรองรับอยู่แล้ว เช่น Credential Leak Management System ของ ThaiCERT ที่ให้หน่วยงานขอใช้เพื่อค้นข้อมูลบัญชีผู้ใช้ที่หลุดโดยใช้โดเมนขององค์กร บริการนี้ระบุขอบเขตไว้ที่ข้อมูลบัญชีผู้ใช้สำหรับเข้าสู่ระบบ ไม่ได้พูดถึง API key หรือ token บทความนี้พูดถึงฝั่งหลัง ซึ่งไม่มีคนพิมพ์รหัสตอนเข้าสู่ระบบ จึงไม่มี MFA คั่นกลาง และมักไม่มีเจ้าของงานที่ชัดเจน

แหล่งข้อมูลระบุอะไร

แนวทางแรกคือ Secrets Management Cheat Sheet ของ OWASP ซึ่งเป็นเอกสารแนวปฏิบัติที่ชุมชนด้านความปลอดภัยแอปพลิเคชันดูแล ไม่ใช่กฎหมายหรือมาตรฐานที่บังคับใคร เนื้อหาที่เกี่ยวกับงานส่งมอบมีดังนี้ (ดูเอกสารของ OWASP)

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

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

• วิศวกรไม่ควรเข้าถึง secret ทั้งหมดในระบบจัดการ secret ควรกำหนดสิทธิ์ละเอียดทีละรายการ

• ควรบันทึกว่าใครขอ secret เมื่อไร และใช้เมื่อใด พร้อมป้องกันไม่ให้บันทึกเหล่านั้นถูกแก้หรือลบ

• ไม่ควรเขียน secret ลงในซอร์สโค้ด หรือในคำสั่ง ENV และ ARG ของ Docker แต่ควรใช้ที่เก็บ secret ของเครื่องมือ CI/CD หรือระบบจัดการ secret

• เครื่องมือ CI/CD ควรได้รับการดูแลเหมือนระบบ production และต้องดูว่าผลลัพธ์ของ pipeline ไม่ทำให้ secret หลุดออกมา รวมถึงใช้เครื่องมือตรวจจับอย่าง detect-secrets ก่อน commit

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

แหล่งที่สองคือเอกสารเรื่อง secret scanning ของ GitHub (ดูเอกสารของ GitHub) เอกสารระบุว่าการสแกนครอบคลุมประวัติ Git ทุก branch รวมถึง issue, pull request, discussion และ wiki ซึ่งหมายความว่าที่ที่ secret รั่วได้ไม่ได้มีแค่ไฟล์โค้ดปัจจุบัน เอกสารแนะนำว่าเมื่อได้รับการแจ้งเตือนให้หมุนเปลี่ยนข้อมูลรับรองที่ได้รับผลกระทบทันที และระบุว่าการลบ secret ออกจากประวัติ Git ใช้เวลามากและมักไม่จำเป็นหากเพิกถอนข้อมูลรับรองนั้นไปแล้ว ข้อความนี้กลับลำดับความคิดของหลายทีม เพราะหลายคนเริ่มจากการพยายามลบประวัติ ทั้งที่ตัวที่ต้องทำก่อนคือทำให้ key ที่รั่วใช้ไม่ได้

แหล่งที่สามคือรายงาน The State of Secrets Sprawl 2025 ของ GitGuardian ลงวันที่ 11 มีนาคม 2025 (ดูรายงานของ GitGuardian) ข้อควรรู้ก่อนอ่านตัวเลขคือ GitGuardian เป็นผู้ขายเครื่องมือตรวจจับ secret ตัวเลขในรายงานจึงเป็นสิ่งที่ตัวตรวจจับของบริษัทนั้นพบ ไม่ใช่การสำรวจทุกองค์กร ตามรายงาน มี secret รั่วบน GitHub สาธารณะ 23.8 ล้านรายการในปี 2024 เพิ่มขึ้นร้อยละ 25 จากปีก่อน secret ที่รั่วในปี 2022 ยังใช้งานได้อยู่ร้อยละ 70 เมื่อทดสอบซ้ำ ร้อยละ 35 ของ repository ส่วนตัวมี secret เทียบกับร้อยละ 4.6 ของ repository สาธารณะ ช่อง Slack ขององค์กรร้อยละ 2.4 มี secret รั่ว ตั๋วใน Jira ร้อยละ 6.1 เปิดเผยข้อมูลรับรอง และในส่วนที่ตรวจพบใน Docker ร้อยละ 98 อยู่ในชั้น (layer) ของ image

GitGuardian ออกรายงานฉบับปี 2026 แล้ว หน้าสรุปของฉบับนี้รายงานว่า repository ภายในองค์กรร้อยละ 32.2 มี secret อย่างน้อยหนึ่งตัว เทียบกับร้อยละ 5.6 ของ repository สาธารณะ และ secret ที่ยืนยันว่ายังใช้ได้ในปี 2022 ยังใช้ได้อยู่ร้อยละ 64 เมื่อผ่านไปสี่ปี ทิศทางตรงกับฉบับปี 2025 ส่วนตัวเลขเรื่อง Slack, Jira และ Docker ข้างต้นเป็นของฉบับปี 2025 เพราะเราไม่พบตัวเลขชุดนี้ในหน้าสรุปของฉบับใหม่

ข้อมูลเหล่านี้พิสูจน์อะไร และไม่พิสูจน์อะไร

ข้อมูลชุดนี้ชี้ให้เห็นสองเรื่องที่ตรงกับงานส่งมอบ เรื่องแรกคือ secret ไม่ได้อยู่แค่ในโค้ด ตัวเลขเรื่อง Slack, Jira และ Docker image บอกว่ามันไปอยู่ในแชต ตั๋วงาน และ artifact ที่สร้างจากระบบด้วย เรื่องที่สองคือ repository ส่วนตัวไม่ได้ปลอดภัยกว่าอย่างที่คนมักเข้าใจ เพราะสัดส่วนที่พบ secret ในนั้นสูงกว่า repository สาธารณะในข้อมูลของ GitGuardian เหตุผลที่เป็นไปได้คือคนรู้สึกว่าที่ปิดอยู่ปลอดภัยพอ จึงวางของที่ไม่ควรวางไว้ แต่รายงานไม่ได้ทดสอบเหตุผลนี้ เป็นเพียงข้อสังเกตของเรา

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

secret มักไปอยู่ตรงไหนบ้างที่ทีมไม่นึกถึง

เมื่อเราไล่ดูระบบเป็นรายระบบ secret มักอยู่ในที่ที่ไม่มีใครนึกถึงตอนมีคนถามครั้งแรก ไฟล์ตั้งค่าตัวอย่างที่ถูกคัดลอกมาใช้จริงแล้วไม่ได้เปลี่ยนค่า ไฟล์ .env ที่ถูก commit ไปครั้งเดียวแล้วถูกลบทีหลัง ข้อความใน log ของ pipeline ที่พิมพ์ตัวแปรสภาพแวดล้อมออกมาตอนแก้ปัญหา ข้อความในแชตกลุ่มของโปรเจกต์ที่คนส่งรหัสให้กันเพราะสะดวก ตั๋วงานที่แนบภาพหน้าจอการตั้งค่า ไฟล์สำรองของฐานข้อมูลที่มีค่าการเชื่อมต่อ และ Docker image ที่สร้างขึ้นโดยฝังค่าไว้ตอน build

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

บัญชี secret: ตารางที่คุณควรได้รับตอนส่งมอบ

สิ่งแรกที่เราแนะนำให้ขอคือตารางหนึ่งหน้า ที่ตอบได้ว่าระบบมี secret อะไรบ้าง โดยไม่ต้องมีค่าจริงของ secret อยู่ในตารางนั้น สำหรับแต่ละรายการ ควรมีข้อมูลต่อไปนี้

• ชื่อและหน้าที่ เช่น รหัสผ่านฐานข้อมูลของระบบหลัก หรือ API key ของผู้ให้บริการส่งอีเมล เพื่อให้คนอ่านรู้ว่ามันเปิดอะไรให้

• ที่เก็บจริง เช่น ระบบจัดการ secret ที่เก็บค่าจริงอยู่ และที่ใดบ้างที่อ่านค่าไปใช้ตอนรัน

• ผู้เป็นเจ้าของ คือคนหรือบทบาทที่รับผิดชอบเมื่อต้องเปลี่ยน ไม่ใช่ชื่อบุคคลที่อาจย้ายงาน

• ใครอ่านค่าได้ ตามหลักที่ OWASP แนะนำว่าสิทธิ์ควรละเอียดทีละรายการ และไม่ควรมีใครเข้าถึงทั้งหมด

• หมุนเปลี่ยนครั้งล่าสุดเมื่อไร และรอบถัดไปเมื่อไร

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

• ผลกระทบหากรั่ว ว่า secret นี้เปิดทางไปยังข้อมูลหรือบริการใดบ้าง เพื่อจัดลำดับความสำคัญวันที่ต้องรับมือ

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

สิ่งที่ควรขอจากผู้พัฒนาตอนส่งมอบ

นอกจากตาราง เรามีรายการสิ่งที่ผู้ว่าจ้างควรระบุไว้ในสัญญาหรือรายการตรวจรับงาน

1. ไม่มี secret ในซอร์สโค้ดและประวัติ ผู้พัฒนายืนยันเป็นลายลักษณ์อักษรว่าได้สแกน repository ทั้งประวัติด้วยเครื่องมือตรวจจับ และแนบผลสแกนพร้อมวันที่

2. การสแกนอัตโนมัติใน pipeline ทุกครั้งที่มีการ commit หรือ merge จะมีการตรวจหา secret ก่อนโค้ดเข้าสาขาหลัก ตามที่ OWASP ระบุว่าใช้เครื่องมืออย่าง detect-secrets ก่อน commit ถ้าใช้ GitHub ให้เปิด push protection ซึ่งบล็อก push ที่มี secret ก่อนเข้า repository และระบุในสัญญาว่าใครมีสิทธิ์ข้ามการบล็อก เพราะเอกสารของ GitHub ระบุว่าโดยค่าเริ่มต้น ทุกคนที่มีสิทธิ์ write ข้ามได้ด้วยการเลือกเหตุผล เช่น "I'll fix it later" แต่ละครั้งที่ข้ามจะสร้าง alert และบันทึกใน audit log ควรกำหนดด้วยว่าใครเป็นคนตรวจ alert เหล่านั้น

3. ที่เก็บ secret ที่ตกลงกันไว้ ระบบจัดการ secret หรือที่เก็บ secret ของเครื่องมือ CI/CD ที่บัญชีเป็นขององค์กรคุณ ไม่ใช่บัญชีส่วนตัวของผู้พัฒนา

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

5. การควบคุมไม่ให้ secret หลุดใน log ผลลัพธ์ของ pipeline และ log ของระบบต้องไม่พิมพ์ค่า secret ซึ่งสอดคล้องกับที่ OWASP เตือนเรื่องผลลัพธ์ของ pipeline ส่วนเรื่องระยะเวลาเก็บ log และการเก็บข้อมูลส่วนบุคคลใน log เราเขียนไว้ในบทความเรื่องการเก็บ log

6. แผนรับมือเมื่อ key รั่วที่ซ้อมแล้ว เอกสารสั้น ๆ ที่ระบุว่าใครตัดสินใจ ใครเพิกถอน ใครแจ้งผู้เกี่ยวข้อง และบันทึกอะไรไว้

7. การส่งต่อสิทธิ์เมื่อสิ้นสุดงาน เมื่อผู้พัฒนาออกจากโครงการ ต้องหมุนเปลี่ยน secret ทุกตัวที่เขาเคยเข้าถึง และถอดสิทธิ์ของเขาออกจากที่เก็บ secret และ repository

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

วันที่ key รั่วจริง ควรทำอะไรตามลำดับ

ลำดับต่อไปนี้ประกอบจากแนวทางของ OWASP และ GitHub ที่เปิดอ่านแล้ว ไม่ใช่ขั้นตอนเฉพาะของระบบใด ทีมของคุณควรปรับให้ตรงกับระบบจริงและซ้อมก่อนวันนั้น

1. เพิกถอน secret ที่รั่วทันที ทำให้ตัวที่หลุดออกไปใช้ไม่ได้ก่อนเป็นอย่างแรก เพราะตราบที่มันยังใช้ได้ การลบร่องรอยไม่ช่วยอะไร การ restart แอปพลิเคชันไม่นับเป็นการเพิกถอน ซึ่ง OWASP ระบุไว้ตรง ๆ และถ้าสิ่งที่หลุดคือไฟล์ทั้งไฟล์ เช่น .env ให้ถือว่าทุกค่าในไฟล์นั้นหลุดพร้อมกัน ไม่ใช่เฉพาะตัวที่มีคนสังเกตเห็น

2. ออกตัวใหม่และอัปเดตบริการที่ใช้ ถ้ามีขั้นตอนหมุนเปลี่ยนอัตโนมัติอยู่แล้ว ขั้นนี้จะเร็วและพลาดน้อยกว่าการแก้ทีละที่

3. ดูประวัติการใช้งานของตัวที่รั่ว ตามที่ OWASP ระบุว่าผู้ตอบสนองต่อเหตุการณ์ควรเข้าถึงประวัติว่าใครใช้เมื่อไร เพื่อดูว่ามีการใช้ที่ไม่ใช่ของระบบหรือไม่ ถ้ามี ให้ถือเป็นเหตุการณ์ละเมิดข้อมูลที่ต้องประเมินต่อ และถ้า log เก็บย้อนหลังไม่ถึงช่วงที่ค่าหลุด ข้อสรุปที่ซื่อตรงคือ "ไม่รู้" ไม่ใช่ "ไม่มีการใช้"

4. ลบตัวที่รั่วออกจากโค้ด log และระบบอื่น รวมถึงแชต ตั๋วงาน และไฟล์สำรอง การลบจาก log ต้องรักษาความสมบูรณ์ของ log ไว้ตามที่ OWASP ระบุ

5. พิจารณาล้างประวัติ Git เป็นลำดับสุดท้าย GitHub ระบุว่าทำได้ยากและมักไม่จำเป็นเมื่อเพิกถอนไปแล้ว จึงตัดสินใจตามความเสี่ยงจริง ไม่ใช่ทำเพราะรู้สึกว่าต้องทำ

6. บันทึกเหตุการณ์และหาสาเหตุ ว่า secret เข้าไปอยู่ตรงนั้นได้อย่างไร และจะป้องกันไม่ให้เกิดซ้ำที่จุดไหน

ถ้า secret ที่รั่วเปิดทางถึงข้อมูลส่วนบุคคล เรื่องนี้จะเป็นเรื่องกฎหมายด้วย พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37(4) กำหนดให้ผู้ควบคุมข้อมูลแจ้งเหตุละเมิดต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) โดยไม่ชักช้า และภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่จะทำได้ เว้นแต่เหตุนั้นไม่มีความเสี่ยงที่จะกระทบสิทธิและเสรีภาพของบุคคล ถ้ามีความเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาด้วย แบบฟอร์มแจ้งเหตุละเมิดดาวน์โหลดได้จากเว็บไซต์ของ สคส. secret รั่วไม่ได้แปลว่าข้อมูลส่วนบุคคลถูกละเมิดทุกครั้ง และเราไม่ได้ให้คำแนะนำทางกฎหมายในบทความนี้ แต่การประเมินว่าเข้าข่ายหรือไม่ ควรเริ่มในวันที่รู้ ไม่ใช่วันที่ตรวจ log เสร็จ จึงควรให้ผู้รับผิดชอบด้านกฎหมายอยู่ในแผนรับมือตั้งแต่แรก

เรื่องที่ไม่ควรทำ

ในมุมของเรา มีสามเรื่องที่พบได้บ่อยและควรเลี่ยง เรื่องแรกคือลบ secret ออกจากไฟล์ล่าสุดแล้วถือว่าจบ เพราะประวัติ Git ยังเก็บไว้ และเอกสารของ GitHub ก็ระบุว่าการสแกนครอบคลุมประวัติทุก branch ตราบที่ key ยังใช้ได้ ใครก็ตามที่ดูประวัติเจอก็ใช้ได้ เรื่องที่สองคือส่ง secret ผ่านแชตหรืออีเมลเพราะรีบ แม้ตั้งใจจะลบทีหลัง ตัวเลขเรื่อง Slack และ Jira ของ GitGuardian ชี้ว่านี่เป็นช่องทางที่เกิดขึ้นจริง ถ้าจำเป็นต้องส่งต่อ ให้ใช้ระบบจัดการ secret แล้วแชร์สิทธิ์เข้าถึง ไม่ใช่แชร์ค่า เรื่องที่สามคือเปลี่ยนค่าที่ production โดยไม่ผ่านขั้นตอนการเปลี่ยนแปลงปกติ เพราะการหมุนเปลี่ยนกระทบทุกบริการที่ใช้ secret นั้น และควรทดสอบก่อน ซึ่งเราเขียนไว้ในบทความเรื่องการจัดการ release บน production ยกเว้นวันที่ต้องเพิกถอนฉุกเฉิน ซึ่งควรมีขั้นตอนลัดที่ซ้อมไว้แล้ว

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. ขอให้ผู้พัฒนาสแกน repository ทั้งประวัติ แล้วดูผล ถ้าพบ secret ที่ยังใช้ได้ ให้เพิกถอนและหมุนเปลี่ยนก่อนทำอย่างอื่น

2. ทำตารางบัญชี secret หนึ่งหน้า โดยเริ่มจากฐานข้อมูล บริการส่งอีเมลหรือ SMS ผู้ให้บริการชำระเงิน และบัญชี Cloud แล้วเติมให้ครบทีละระบบ

3. ย้าย secret ไปไว้ในที่เก็บที่บัญชีเป็นขององค์กรคุณ และถอดสิทธิ์ของบุคคลที่ไม่ได้อยู่ในโครงการแล้ว

4. เปิดการสแกนใน pipeline เพื่อให้ secret ใหม่ที่เข้ามาถูกพบก่อนเข้าสาขาหลัก

5. ซ้อมการหมุนเปลี่ยนหนึ่งตัวในสภาพแวดล้อมทดสอบ บันทึกว่าบริการใดต้องอัปเดตตาม และใช้เวลาเท่าไร

6. ใส่รายการในสัญญาและรายการตรวจรับ เพื่อให้ผู้พัฒนารายถัดไปส่งมอบสิ่งเหล่านี้ตั้งแต่ต้น

สรุป

แนวทางของ OWASP ระบุให้รวมศูนย์ จำกัดสิทธิ์ หมุนเปลี่ยน และเพิกถอนทันทีเมื่อรั่ว เอกสารของ GitHub ย้ำว่าการเพิกถอนต้องมาก่อนการลบประวัติ และข้อมูลของ GitGuardian ซึ่งเป็นผู้ขายเครื่องมือตรวจจับ ชี้ว่า secret ไปอยู่ทั้งใน repository ส่วนตัว แชต ตั๋วงาน และ Docker image ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ขอตารางบัญชี secret หนึ่งหน้าจากผู้พัฒนาที่ดูแลระบบของคุณ โดยไม่มีค่าจริงอยู่ในตาราง ตารางนั้นบอกได้ว่าวันที่ key รั่ว คุณต้องเพิกถอนอะไร ใครทำ และระบบจะกระทบอย่างไร

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส