GitHub Actions, 캐시 보안 강화로 악용 경로 차단
신뢰할 수 없는 트리거(Untrusted Triggers)에 대한 읽기 전용 캐시 토큰(Read-only Cache Token)을 기본 브랜치에 발급하여 보안 강화
이전에는 모든 워크플로우 이벤트에 읽기/쓰기 토큰 발급으로 인한 캐시 포이즈닝(Cache Poisoning) 취약점 존재
최소 권한 원칙(Least Privilege Principle) 적용으로 악의적 코드 실행 및 프로덕션 비밀 유출 경로 차단
일부 워크플로우에서 캐시 쓰기 기능 회귀(Regression) 발생 가능성, 별도 워크플로우 구성으로 해결 필요
캐시 포이즈닝(Cache Poisoning) 취약점 분석
기존 GitHub Actions는 `pull_request_target`, `issue_comment` 등 외부 기여자가 트리거할 수 있는 이벤트에 대해서도 기본 브랜치 캐시에 대한 읽기/쓰기 권한(Read-write Permissions)을 부여했습니다. 이로 인해 악의적인 사용자가 워크플로우 코드에 영향을 주거나, 스크립트 인젝션(Script Injection)을 통해 캐시를 오염시킬 수 있었습니다. 이후 `push`나 `schedule`과 같이 신뢰도가 높은 워크플로우가 이 오염된 캐시를 복원할 경우, 임의 코드 실행(Arbitrary Code Execution)이나 프로덕션 비밀 유출(Production Secret Exfiltration)로 이어질 수 있는 심각한 보안 위협이 존재했습니다. 이러한 권한 상승 경로(Privilege Escalation Path)는 심각한 보안 사고로 이어질 수 있어 즉각적인 조치가 필요했습니다.
읽기 전용 캐시 토큰(Read-only Cache Token) 도입 배경
이번 변경은 최소 권한 원칙(Least Privilege Principle)을 캐시 접근에 적용하기 위한 조치입니다. GitHub는 두 가지 조건이 충족될 때 읽기 전용 캐시 토큰을 발급하도록 정책을 변경했습니다. 첫째, 워크플로우를 트리거하는 이벤트가 신뢰할 수 없는 외부 사용자에 의해 시작될 수 있어야 합니다. 둘째, 워크플로우 실행 컨텍스트와 캐시 범위가 공유 기본 브랜치 SHA(Shared Default-branch SHA)를 기반으로 해야 합니다. 이 두 조건을 만족하는 경우, 해당 워크플로우는 캐시를 읽을 수는 있지만 수정할 수는 없게 되어 캐시 포이즈닝 공격을 원천적으로 차단합니다.
영향받는 워크플로우 및 해결 방안
이번 변경으로 인해 기본 브랜치 SHA 컨텍스트에서 캐시에 쓰기를 시도하는 일부 신뢰할 수 없는 워크플로우의 캐싱 기능이 회귀(Regression)될 수 있습니다. 이러한 워크플로우에서는 `actions/cache`가 경고 로그를 남기고 캐시 저장을 건너뛰게 됩니다. 하지만 캐시 복원 기능은 영향을 받지 않습니다. 이 워크플로우에서 캐시의 이점을 계속 활용하려면, `push`와 같이 읽기/쓰기 캐시 접근 권한이 있는 이벤트로 트리거되는 별도의 워크플로우를 구성해야 합니다. 이 워크플로우에서 캐시를 저장하면, 이후 읽기 전용 권한을 가진 다른 워크플로우들이 해당 캐시를 성공적으로 복원하고 사용할 수 있게 됩니다. 이는 캐시 데이터의 무결성(Cache Data Integrity)을 보장하면서도 필요한 워크플로우에서 캐시를 활용할 수 있도록 하는 절충안입니다.
보안 강화 조치의 중요성
GitHub Actions에서 캐시를 통한 권한 상승 공격(Privilege Escalation Attack)은 심각한 보안 위협입니다. 특히 오픈 소스 프로젝트나 외부 기여가 많은 저장소에서는 이러한 공격 벡터에 노출될 가능성이 높습니다. 이번 업데이트는 데이터 격리 아키텍처(Data Isolation Architecture)의 원칙을 캐시 관리에 적용하여, 각 워크플로우 컨텍스트에 필요한 최소한의 권한만 부여함으로써 시스템의 전반적인 보안 태세를 강화하는 데 기여합니다. 데이터 미저장 정책(Zero-Retention Policy)과 함께 이러한 접근 제어 강화는 민감한 정보 유출을 방지하고 CI/CD 파이프라인의 신뢰성을 높이는 데 필수적입니다.