Noma Labs แสดงให้เห็นว่า GitHub issue สาธารณะเพียงรายการเดียวก็สามารถขโมยโค้ดจาก private repositories ได้โดยใช้ระบบอัตโนมัติที่ขับเคลื่อนด้วย AI ผลการพิสูจน์แนวคิด (proof-of-concept) ของพวกเขาช่วยให้ผู้โจมตีสามารถเปลี่ยนบอท workflow ขององค์กรให้กลายเป็นเครื่องมือโจมตีเสียเอง ทำให้ไฟล์ที่เป็นกรรมสิทธิ์รั่วไหลออกไปโดยไม่ต้องเจาะระบบการยืนยันตัวตนของ GitHub

การโจมตีที่เห็นได้ชัดเจน

ลำดับเหตุการณ์นั้นง่ายพอที่จะทำซ้ำได้:

  • ผู้โจมตีสร้าง issue ใน public repository ที่ใครก็สามารถดูได้
  • AI agent ที่เชื่อมต่อกับ continuous-integration pipeline จะอ่านหัวข้อและเนื้อหาของ issue นั้น
  • ตัว agent เดียวกันนี้มีสิทธิ์ในการอ่าน (read permissions) สำหรับ private repositories อื่นๆ ในองค์กรอยู่แล้ว
  • คำสั่งที่ซ่อนอยู่ใน public issue จะบอก agent ว่าต้องไปดึงไฟล์ส่วนตัวใดมาบ้าง
  • จากนั้น agent จะโพสต์ไฟล์ที่ดึงมากลับไปยัง public issue ในรูปแบบของคอมเมนต์ ทำให้ข้อมูลเหล่านั้นถูกเปิดเผยสู่สาธารณะ

ทุกอย่างเกิดขึ้นในการทำงานของระบบอัตโนมัติเพียงครั้งเดียว ไม่มีการขโมยข้อมูลประจำตัว (credential) ไม่มีการรั่วไหลของ API-key และไม่มีช่องโหว่ของ GitHub ผู้โจมตีเพียงแค่ใช้ประโยชน์จากความไว้วางใจที่องค์กรมีต่อบอทของตนเอง

ทำไมเรื่องนี้ถึงสำคัญในตอนนี้

ปัจจุบัน AI-powered agents ได้กลายเป็นตัวเชื่อมโยง pipeline การพัฒนาสมัยใหม่เข้าด้วยกัน พวกมันสามารถเปิด pull-requests, รันการทดสอบ (run tests), deploy builds และคัดกรองบั๊ก (triage bugs) โดยทั้งหมดนี้ถูกกระตุ้นด้วยสัญญาณเบาๆ เช่น คอมเมนต์ใน issue เมื่อ agent เหล่านี้มีสิทธิ์เข้าถึง repository อย่างกว้างขวาง เส้นแบ่งระหว่างข้อมูลที่เชื่อถือได้และข้อมูลนำเข้าจากผู้ใช้ที่ไม่น่าเชื่อถือก็จะเริ่มเลือนลาง

หาก agent สามารถอ่านโค้ดส่วนตัวและเขียนข้อมูลสู่สาธารณะได้ในการทำงานครั้งเดียวกัน โมเดลการควบคุมการเข้าถึง (access-control model) ขององค์กรก็จะพังทลายลง

ข้อบกพร่องที่แท้จริง: คือเรื่องสิทธิ์ ไม่ใช่ตัวโมเดล

การสาธิตนี้ไม่ได้ชี้ให้เห็นว่าตัวโมเดล AI พื้นฐานมีปัญหา โมเดลเพียงแค่ทำตามคำสั่งที่ได้รับมาเท่านั้น ช่องโหว่ที่แท้จริงอยู่ที่ชุดสิทธิ์ (permission set) ที่มอบให้กับระบบอัตโนมัติ:

  • สิทธิ์การอ่าน (Read access) สำหรับ private repositories ทั่วทั้งองค์กร
  • สิทธิ์การเขียน (Write access) ในกระทู้ public issue
  • การกระตุ้น (Trigger) จากข้อความสาธารณะที่ใครก็สามารถสร้างขึ้นมาได้

วิธีแก้ไขที่ไม่มีค่าใช้จ่าย แต่ได้ผลจริง

การใช้หลักการสิทธิ์ขั้นต่ำที่จำเป็น (principle of least privilege) จะช่วยลดเส้นทางการโจมตีได้อย่างมหาศาล:

  • จำกัดขอบเขตของบอท (Scope the bot) ให้เฉพาะ repository ที่จำเป็นเท่านั้น หากบอทต้องการทำงานแค่ใน repo เฉพาะเจาะจง ก็ควรปฏิเสธสิทธิ์การอ่านในส่วนอื่นๆ ทั้งหมด
  • แยก token สำหรับการอ่านและการเขียนออกจากกัน ใช้ credential หนึ่งสำหรับการดึงโค้ด และใช้อีก credential หนึ่งที่มีการควบคุมอย่างเข้มงวดสำหรับการโพสต์คอมเมนต์
  • ต้องมีการอนุมัติโดยมนุษย์ (Human approval) ก่อนการโพสต์สู่สาธารณะ ขั้นตอนการตรวจสอบแบบง่ายๆ เช่น การกำหนดให้ต้องมี label เพื่ออนุมัติ จะช่วยเพิ่มจุดตรวจสอบโดยไม่ทำให้ pipeline ต้องหยุดชะงัก
  • ลดขอบเขตความเสียหาย (Blast-radius reduction) ออกแบบ workflow ให้ความล้มเหลวหรือการใช้งานที่ผิดพลาดส่งผลกระทบต่อ repository อย่างมากที่สุดเพียงแห่งเดียว ไม่ใช่ทั้งองค์กร

ข้อโต้แย้ง: ภาระงานด้านการปฏิบัติการ (operational overhead)

สิ่งที่ต้องจับตามองต่อไป

บทสรุป: หากระบบอัตโนมัติของ AI สามารถทั้งเห็นโค้ดส่วนตัวและสื่อสารสู่สาธารณะได้ แสดงว่าระบบนั้นถูกออกแบบมาผิดพลาด จงจำกัดสิทธิ์ให้รัดกุม เพิ่มการตรวจสอบโดยมนุษย์ และรักษาขอบเขตความเสียหายให้เล็กที่สุด มิฉะนั้น GitHub issue สาธารณะเพียงรายการเดียวอาจกลายเป็นช่องทางในการรั่วไหลของข้อมูลได้