🔐 GitHub Actions เพิ่ม “ประตู” ให้ Cache แล้ว

🔐 GitHub Actions เพิ่ม “ประตู” ให้ Cache แล้ว

ความเสี่ยงของ CI ไม่ได้อยู่แค่ใน source code แต่อยู่ใน cache ด้วย: ถ้า workflow ที่ไม่น่าเชื่อถือ restore หรือ save cache ได้กว้างเกินไป ก็เพิ่มพื้นที่ให้ cache poisoning และการนำ artifact ที่ไม่ควรเชื่อถือกลับมาใช้

GitHub ทำให้ cache-mode ใช้งานได้ทั่วไปบนทุก plan แล้ว โดยกำหนดสิทธิ์ cache ระดับ workflow หรือ job ได้ 4 แบบ:

• read — restore ได้ แต่ save ไม่ได้ • write — restore และ save ได้ • write-only — save ได้ แต่ restore ไม่ได้ • none — ปิด cache ทั้งหมด

จุดสำคัญคือ job-level override ระดับ workflow และสิทธิ์จะถูกส่งต่อไปยัง reusable workflow โดย workflow ที่ถูกเรียกจะได้สิทธิ์มากกว่าที่ caller อนุญาตไม่ได้

สำหรับ event ที่ trust ต่ำ เช่น pull_request_target ค่า default ยังคงเป็น read-only แต่ถ้าประกาศ write หรือ write-only เอง GitHub จะใส่ warning เพราะอาจเพิ่มความเสี่ยง cache poisoning ส่วน workflow เดิมที่ไม่กำหนดค่า จะยังใช้ secure defaults ต่อไป

ในทางปฏิบัติ ควรเริ่มจาก read กับงานที่อ่าน cache อย่างเดียว, ให้ write เฉพาะ trusted push, ใช้ write-only เมื่อ job มีหน้าที่สร้าง cache และใช้ none กับงานที่ไม่จำเป็นต้องแตะ cache เลย การแยกสิทธิ์แบบนี้ทำให้ policy ของ CI อ่านจาก YAML ได้ชัดขึ้น และลด blast radius เมื่อ workflow ใด workflow หนึ่งถูกโจมตี

เหมาะกับทีมที่มี reusable workflows, มี pull request จาก fork หรือมี pipeline หลายระดับความน่าเชื่อถือ ข้อจำกัดคือการเปิด write ให้ event ที่ไม่ trust ไม่ได้ทำให้ปลอดภัยขึ้นเอง และต้องทบทวน cache key, dependency และ runner policy ควบคู่กัน

ลิงก์อยู่ในคอมเมนต์แรก คุณคิดว่า workflow ไหนในทีมควรถูกลดสิทธิ์ cache ก่อน? ติดตาม SynapTech AI เพื่อดูมุม Code Review ที่เอาไปใช้กับระบบจริงได้

#GitHubActions #SupplyChainSecurity #DevSecOps #CI #SynapTechAI

---

📖 อ่านบทความเต็มบน Facebook | 🔔 ติดตาม SynapTech