빌드 캐시는 같은 의존성을 매번 내려받지 않게 해 주는 속도 장치입니다. 하지만 외부 기여자가 영향을 줄 수 있는 작업이 캐시에 파일을 저장하고, 나중에 배포 권한을 가진 작업이 그 파일을 믿고 실행하면 공급망 공격 통로가 됩니다. GitHub는 2026년 9월 10일 cache-mode를 일반 제공해 캐시 권한을 작업 단위로 나누었습니다.
캐시는 실행 사이를 건너가는 저장소
GitHub Actions의 한 작업은 끝나면 실행환경이 사라지지만 캐시는 다음 실행에서 다시 쓰도록 남습니다. 공격자가 낮은 권한의 풀리퀘스트 작업에서 악성 의존성을 캐시에 넣으면, 이후 push나 배포 작업이 같은 키로 복원할 수 있습니다. 이때 공격 코드는 더 높은 권한과 비밀정보를 만납니다.
OWASP와 Cloud Security Alliance는 이런 캐시 오염을 CI/CD 공급망 위험으로 설명해 왔습니다. 캐시는 단순 속도 기능이 아니라 신뢰 수준이 다른 실행 사이를 잇는 저장 경계입니다.
네 가지 권한으로 쓰기와 읽기를 분리
새 cache-mode는 read, write, write-only, none 네 가지입니다. read는 기존 캐시를 읽되 저장하지 못하고, write는 둘 다 허용합니다. write-only는 새 캐시를 저장하지만 과거 캐시는 읽지 않으며, none은 완전히 차단합니다.
외부 입력을 다루는 검증 작업은 read나 none으로 제한하고, 신뢰된 기본 브랜치 작업만 write를 갖게 할 수 있습니다. 권한 선택은 워크플로 전체나 개별 job에 놓을 수 있고 job 설정이 더 우선합니다.
재사용 워크플로에도 권한 상한이 전달된다
조직은 공통 배포 절차를 재사용 워크플로로 묶습니다. 호출받은 워크플로가 더 넓은 캐시 권한을 가질 수 있다면 중앙 템플릿이 우회 통로가 됩니다. GitHub는 호출자가 준 cache-mode보다 재사용 워크플로의 권한이 커지지 않도록 제한합니다.
낮은 신뢰 이벤트인 pull_request_target에는 읽기 전용이 기본입니다. 관리자가 명시적으로 write나 write-only를 주면 경고가 붙지만 실행 자체를 막지는 않습니다. 경고를 무시하면 보호막도 사라집니다.
설정 하나로 끝나지 않는 공급망 방어
cache-mode는 캐시 쓰기와 읽기 경로를 줄이지만 사용자 입력을 셸 명령에 넣는 문제, 과도한 토큰 권한, 검증되지 않은 액션 버전과 아티팩트 공유까지 해결하지는 않습니다. 각 작업이 어떤 입력과 비밀정보를 접하는지 함께 봐야 합니다.
도입할 때는 외부 이벤트, AI 에이전트와 자동화가 실행되는 job을 먼저 찾고 기본을 read 또는 none으로 좁히는 편이 안전합니다. 성능이 떨어지는 구간만 근거를 남겨 권한을 늘리면 됩니다. 빠른 빌드보다 신뢰 경계를 먼저 설계하는 변화입니다.