ปิดช่องทาง cache poisoning ใน GitHub Actions ด้วย cache-mode: ให้แต่ละงานอ่านเขียน cache ได้เท่าที่จำเป็น

GitHub เปิดให้ใช้ cache-mode กับ GitHub Actions ทุกแผนเมื่อวันที่ 10 กันยายน 2026 ฟีเจอร์นี้แก้ความเสี่ยงที่หลายทีมไม่รู้ตัว คือ workflow ที่รันโค้ดจากคนนอกอาจแอบฝังของอันตรายไว้ใน cache แล้วรอให้ workflow ที่เชื่อถือได้อย่างงาน build สำหรับปล่อยจริงดึงไปใช้ บทความนี้อธิบายว่า cache poisoning เกิดขึ้นอย่างไร ค่าทั้งสี่แบบของ cache-mode ต่างกันอย่างไร และควรตั้งค่าอย่างไรกับ pipeline ของทีม

cache ใน GitHub Actions ทำหน้าที่อะไร

cache ของ GitHub Actions ใช้เก็บสิ่งที่สร้างซ้ำได้แต่เสียเวลา เช่น แพ็กเกจที่ติดตั้งแล้วหรือผลลัพธ์ของการ build ครั้งก่อน เพื่อให้รอบถัดไปดึงกลับมาใช้แทนการสร้างใหม่ ช่วยให้ pipeline เร็วขึ้นมาก แต่ความสะดวกนี้แลกมาด้วยการที่หลาย workflow ใช้ข้อมูล cache ร่วมกัน

cache poisoning เกิดขึ้นอย่างไร

cache poisoning คือการที่ผู้โจมตีทำให้ข้อมูลอันตรายถูกบันทึกลง cache แล้วรอให้ workflow ที่มีสิทธิ์สูงกว่าดึงไปใช้ ตัวอย่างที่เสี่ยงชัดเจนคือ workflow ที่ทริกเกอร์ด้วย pull_request_target ซึ่งทำงานในบริบทของ branch หลักแม้จะเริ่มจาก pull request ของคนนอก ถ้า workflow แบบนี้เขียน cache ได้และมีขั้นตอนที่รันโค้ดจาก pull request ผู้โจมตีอาจทำให้ไฟล์ที่ถูกดัดแปลงถูกบันทึกลง cache ภายใต้คีย์เดียวกับที่งาน build หลักใช้อยู่

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

ค่าทั้งสี่แบบของ cache-mode

ประกาศ cache-mode ได้ทั้งระดับ workflow และระดับ job โดยค่าระดับ job มีผลเหนือค่าระดับ workflow สิทธิ์นี้บังคับใช้โดยบริการ cache เอง ไม่ใช่แค่ข้อตกลงในไฟล์ และส่งต่อไปถึง reusable workflow ด้วย workflow ที่ถูกเรียกใช้จะไม่มีทางได้สิทธิ์ cache มากกว่าที่ workflow ต้นทางอนุญาต

ค่าเริ่มต้นที่ปลอดภัย และกับดักของการประกาศเอง

workflow ที่ไม่ได้ตั้ง cache-mode ยังใช้ค่าเริ่มต้นที่ปลอดภัยแบบเดิม คือ read สำหรับเหตุการณ์ความเชื่อถือต่ำอย่าง pull_request_target และ write สำหรับเหตุการณ์ที่เชื่อถือได้อย่าง push แต่เมื่อประกาศ cache-mode เองอย่างชัดเจน ค่านั้นจะมีผลเหนือค่าเริ่มต้นแบบอ่านอย่างเดียวของเหตุการณ์ความเชื่อถือต่ำด้วย ถ้าตั้ง write หรือ write-only ให้เหตุการณ์ประเภทนี้ GitHub Actions จะแสดงคำเตือนในผลการรัน เพราะเพิ่มความเสี่ยง cache poisoning โดยตรง

กับดักจึงอยู่ตรงนี้ ทีมที่คัดลอกไฟล์ workflow มาจากโปรเจกต์อื่นแล้วเห็นว่าตั้ง cache-mode ไว้ อาจยกเลิกการป้องกันเริ่มต้นไปโดยไม่รู้ตัว ถ้าเจอคำเตือนเรื่องสิทธิ์เขียน cache ในผลการรัน ให้ถือว่าเป็นเรื่องที่ต้องตรวจทันที ไม่ใช่คำเตือนที่ปล่อยผ่านได้

แนวทางตั้งค่าที่ทีมงานแนะนำ

ใช้หลักสิทธิ์น้อยที่สุด (least privilege) ไล่ตามหน้าที่ของแต่ละ job งานที่ไม่ได้ใช้ cache เลย เช่น งานประกาศผลหรืองานตรวจที่เร็วอยู่แล้ว ให้ตั้ง none งานทดสอบของ pull request ให้ตั้ง read เพื่อได้ความเร็วจาก cache แต่เขียนทับไม่ได้ และจำกัดสิทธิ์ write ไว้กับ job บน branch หลักที่เชื่อถือได้เท่านั้น

ค่า write-only เหมาะกับงานเตรียม cache ที่ต้องการสร้างใหม่จากศูนย์ เพราะไม่ดึง cache เดิมมาใช้เลย จึงไม่ต่อยอดจาก cache ที่อาจถูกปนเปื้อนมาก่อน หลังตั้งค่าแล้วควรไล่ตรวจ workflow เดิมที่ใช้ pull_request_target ทุกไฟล์ เพราะเป็นกลุ่มที่เสี่ยงที่สุด

cache poisoning เป็นส่วนหนึ่งของความเสี่ยงห่วงโซ่อุปทานซอฟต์แวร์ (software supply chain) ที่ถูกโจมตีบ่อยขึ้นเรื่อย ๆ เช่นเดียวกับการรั่วของ secret ใน pull request ซึ่ง GitHub เพิ่งเพิ่มความสามารถบล็อกไม่ให้ merge pull request ที่มี secret หลุดไปในสัปดาห์เดียวกัน

ทีมงาน Smart Cyber Tech วางระบบ DevOps และ CI/CD ปล่อยงานอัตโนมัติ โดยกำหนดสิทธิ์ของทุกขั้นตอนใน pipeline ตามหลักสิทธิ์น้อยที่สุดตั้งแต่เริ่ม และตรวจ workflow เดิมเพื่อหาจุดเสี่ยงให้ได้ ปรึกษาได้ที่ แบบฟอร์มติดต่อ