ข้อมูลการเข้าสู่ระบบ 39 ล้านรายการรั่วไหลในหนึ่งปี
รายงาน Octoverse 2024 ของ GitHub พบว่า มี secret รั่วไหล 39 ล้านรายการ บน GitHub ในปี 2024 นั่นคือ เพิ่มขึ้น 25% เมื่อเทียบปีต่อปี จากปี 2023 secret รวมถึง API keys, database strings, auth tokens และ cloud credentials
สาเหตุนั้นรู้จักกันดี นักพัฒนา commit โค้ดที่มี secret อยู่ภายใน secret มาจาก debug sessions หรือถูก hardcode แทนที่จะเก็บใน environment variables ที่ 39 ล้านครั้งของการรั่วไหล นี่ไม่ใช่เรื่องหายาก แต่เป็นเรื่องปกติ
เครื่องมือ AI เพิ่มช่องทางการรั่วไหลที่สอง
การวิจัยของ GitGuardian ปี 2025 พบว่า 67% ของนักพัฒนาเคยเปิดเผย secret ในโค้ดโดยไม่ตั้งใจ นิสัยเดียวกันที่ทำให้เกิดการรั่วไหลบน GitHub ก็ทำให้เกิดการรั่วไหลผ่านเครื่องมือ AI ด้วย
นักพัฒนาวาง paste โค้ดลงใน Claude, ChatGPT หรือผู้ช่วย AI อื่นๆ เพื่อขอความช่วยเหลือ โค้ดนั้นมักมี credentials จริงอยู่ด้วย โมเดล AI ได้รับ secret นั้น อาจเก็บไว้ในประวัติการสนทนา ส่งไปยังเซิร์ฟเวอร์ของผู้ให้บริการ นักพัฒนาสูญเสียการควบคุม โดยไม่มีคำเตือน
สามตัวอย่าง:
การ debug ฐานข้อมูล นักพัฒนา paste stack trace ซึ่งมี connection string อยู่ด้วย AI อ่าน password นั้นด้วย
การตรวจสอบ pipeline นักพัฒนาแชร์สคริปต์ data pipeline สคริปต์มี AWS access key และ secret key AI ได้รับทั้งสองอย่าง
การตรวจสอบ API integration นักพัฒนาขอความคิดเห็นเกี่ยวกับ integration โค้ดมี API key ของ partner จริง key นั้นออกจากเครือข่ายของนักพัฒนา
ในแต่ละกรณี เป้าหมายคือการขอความช่วยเหลืออย่างถูกต้องตามกฎหมาย การรั่วไหล credential เป็นผลพลอยได้จากการให้บริบทเพียงพอแก่ AI รูปแบบนี้เหมือนกับการรั่วไหลบน GitHub ไม่ใช่การกระทำที่มุ่งร้าย แต่เป็นเรื่องปกติ
CI/CD Pipelines เผชิญความเสี่ยงเดียวกัน
การรั่วไหล secret ใน CI/CD pipeline เพิ่มขึ้น 34% ในปี 2024 Build scripts, deployment configs และไฟล์ infrastructure-as-code ต่างผ่านการตรวจสอบโดย AI ในปัจจุบัน ไฟล์เหล่านี้มักมี cloud credentials และ service account tokens
เมื่อเครื่องมือ AI ครอบคลุมวงจรการพัฒนามากขึ้น ทั้งการตรวจสอบ เอกสาร การ debug การปรับแต่ง พื้นที่การเปิดเผยก็เพิ่มขึ้นตามมา
วิธีที่สถาปัตยกรรม MCP บล็อกการรั่วไหล
สำหรับทีมที่ใช้ Claude Desktop หรือ Cursor IDE สถาปัตยกรรม MCP server จะวาง credential filter ในเส้นทางระหว่างนักพัฒนาและโมเดล AI
MCP server จัดการข้อความทุกชิ้นที่ผ่าน session โค้ดที่ paste, stack traces, config files, debug context ทั้งหมดผ่านขั้นตอนการทำให้ไม่ระบุตัวตนก่อนที่โมเดลจะเห็น
เครื่องมือค้นหารูปแบบ credential: รูปแบบ API key, database strings, OAuth tokens, private key headers และรูปแบบที่กำหนดเองที่ทีมรักษาความปลอดภัยของคุณกำหนด การจับคู่แต่ละรายการจะถูกแทนที่ด้วย token ก่อนการส่ง
สิ่งนี้มีลักษณะอย่างไรในทางปฏิบัติ:
นักพัฒนา paste stack trace ที่มี database connection string MCP server แทนที่ string ด้วย `[DB_CONNECTION_1]` AI เห็น trace ที่มี token แทน ให้ความช่วยเหลือในการ debug ตาม version ที่ทำให้ไม่ระบุตัวตน credential จริงไม่เคยออกจากเครือข่ายภายใน
สิ่งนี้หยุดเวกเตอร์การรั่วไหลเดียวกับที่เติม GitHub ด้วย secret ช่องทางแตกต่างกัน ซึ่งเป็นเครื่องมือ AI ไม่ใช่ git commits แต่การแก้ไขทำงานในลักษณะเดียวกัน: บล็อกก่อนที่จะส่ง
ดูที่ ภาพรวมความปลอดภัย ของเราสำหรับวิธีที่ anonym.legal จัดการเรื่องนี้ในเครื่องมือ AI และเวิร์กโฟลว์เอกสาร และ ศูนย์การปฏิบัติตาม สำหรับการควบคุมการตรวจสอบ
การตรวจจับหลังเหตุการณ์สายเกินไป
บางทีมใช้การสแกนหลัง commit เพื่อตรวจจับ secret ที่รั่วไหล GitGuardian และ truffleHog ทำงานได้ดีสำหรับช่องทาง GitHub แต่ไม่ครอบคลุม AI tool sessions
เมื่อ secret ไปถึงเซิร์ฟเวอร์ของผู้ให้บริการ AI การเปิดเผยนั้นเสร็จสิ้นแล้ว การสแกนพบหลังจากนั้น การทำให้ไม่ระบุตัวตนในระดับ MCP หยุดมันไม่ให้ถึงโมเดลเลย
การรั่วไหล 39 ล้านรายการบน GitHub บันทึกช่องทางหนึ่ง การเปิดเผยผ่านเครื่องมือ AI เป็นปัญหาเดียวกันในช่องทางที่มีการตรวจสอบน้อยกว่าและไม่มีเส้นทางการตรวจสอบ การป้องกันก่อนการส่งครอบคลุมทั้งสองอย่าง