깃허브 액션 'pull_request_target', 12월 2일부터 기본 차단 — 공개 저장소 운영자는 11월 9일 전에 뭘 확인해야 하나?
깃허브가 11월 2일, 공개 저장소에서 pull_request_target 트리거를 12월 2일부터 기본으로 막는다고 발표했습니다. 원래 11월 2일 예정이던 시행을 한 달 미룬 것이고, 11월 9일과 16일에는 2시간씩 미리 막아 보는 '브라운아웃'이 있습니다. 공개 저장소에 이 트리거를 쓰는 워크플로가 있다면 지금 확인할 차례입니다.
무슨 일인가
pull_request_target은 외부 기여자의 풀 리퀘스트(PR)가 들어올 때 포크가 아닌 원본 저장소의 권한과 비밀 값(secrets)으로 워크플로를 실행하는 트리거입니다. 깃허브는 12월 2일부터 GitHub Free·Team·Enterprise Cloud의 공개 저장소에서 이 이벤트를 기본 차단합니다. 액션 이벤트 정책에서 명시적으로 허용한 경우만 예외이고, 비공개·내부 저장소와 GitHub Enterprise Server는 대상이 아닙니다.
지금은 '평가 모드'라 막힐 실행을 보여 주기만 합니다. 11월 9일과 16일 16:00~18:00 UTC(한국 시각 다음 날 새벽 1~3시)에는 실제로 막혀, 해당 워크플로가 실행되지 않고 오류 주석이 달린 실패 기록이 남습니다. 브라운아웃이 끝나면 다시 경고만 남기는 평가 모드로 돌아갑니다.
평가 모드·경고만
1차 브라운아웃
2차 브라운아웃
공개 저장소 기본 차단
왜 중요한가
이 트리거는 원본 저장소의 비밀 값에 접근할 수 있어서, 워크플로가 포크에서 온 코드를 받아 실행하면 PR 하나로 배포 키·토큰을 빼 갈 수 있습니다. 깃허브는 이 위험 때문에 기본값 자체를 바꿨습니다. 반대로 라벨 자동 붙이기나 PR 댓글 봇처럼 정상적으로 쓰던 워크플로도 아무것도 안 하면 12월 2일부터 멈춥니다.
기본 차단 유지 (권장)
- 포크 코드를 체크아웃해 빌드·테스트하는 워크플로
- 비밀 값이 필요 없는 검사 → pull_request 트리거로 전환
- 쓰지 않는 오래된 워크플로
정책으로 허용 (필요할 때만)
- 외부 코드를 실행하지 않는 라벨·댓글 봇
- 워크플로 파일 단위로 지정해 허용
- 권한(permissions)은 최소로
내 사업·앱에 무슨 의미
- 공개 저장소 운영 개발자 — 오픈소스 라이브러리·플러그인을 공개 저장소에서 관리한다면 직접 대상입니다.
- 비공개 저장소만 쓰는 1인 개발자 — 이번 변경 대상은 아니지만, 같은 패턴(외부 코드 + 비밀 값)이 있는지 한 번 점검할 만합니다.
- 사장님 — 외주 개발사가 결과물을 공개 저장소에 두고 자동 배포를 걸어 뒀다면 영향 여부를 물어보세요.
직접 확인해 본 방법: 맥에 연결해 둔 앱몬스터 작업 폴더 두 곳에서 .github/workflows 파일과 pull_request_target 문자열을 찾아보니 0건이었습니다. 앱몬스터 사이트는 지금 수동 배포라 영향이 없고, 자동 배포를 붙일 때 워크플로 lockfile과 함께 이 트리거를 피하기로 했습니다.
지금 해볼 것
grep -rn "pull_request_target" .github/workflows로 쓰는 워크플로를 찾습니다.Q&A — pull_request_target 기본 차단 자주 묻는 질문
비공개 저장소도 pull_request_target이 막히나요?
아니요, 공개 저장소만 대상입니다. 비공개·내부 저장소와 GitHub Enterprise Server는 이번 기본 차단에서 빠집니다.
11월 9일 브라운아웃 때 워크플로가 실패하면 계속 멈춰 있나요?
아니요, 2시간 뒤 평가 모드로 돌아가 경고와 함께 다시 실행됩니다. 그때 실패한 워크플로가 12월 2일부터 멈출 대상이니 목록으로 정리해 두면 됩니다.
pull_request_target 대신 무엇을 쓰면 되나요?
외부 PR 코드를 빌드·테스트하는 용도라면 pull_request 트리거가 기본 선택입니다. 포크에서 온 PR은 원본 저장소의 비밀 값 없이 실행되므로 이번 차단 이유가 된 유출 위험이 없습니다.