GitHub, 12월 2일부터 공개 저장소에서 pull_request_target 기본 차단: 11월 9일·16일 브라운아웃

2026년 11월 2일 GitHub는 GitHub Actions가 모든 공개 저장소에서 pull_request_target 이벤트를 기본으로 차단한다는 변경 로그를 게시했다. 해당하는 Actions 이벤트 정책이 명시적으로 허용하는 경우는 예외다. 날짜가 중요한 세부 사항이다. 변경 로그에 따르면 시행은 원래 2026년 11월 2일로 예정되어 있었고, 영구 시행의 새 날짜는 2026년 12월 2일이다. 이 항목은 ‘폐지’로 분류되며, 공개 저장소 소유자에게 멈추게 될 워크플로를 찾을 짧은 기간을 준다.

이유는 보안이다. pull_request_target 이벤트는 기본 저장소의 컨텍스트에서 실행되며 그 저장소의 시크릿에 접근할 수 있다. 이를 쓰는 워크플로가 포크에서 온 신뢰할 수 없는 코드를 실행하면 그 코드가 파이프라인을 해치거나 시크릿을 훔칠 수 있다. GitHub는 기본 규칙이 이 위험을 줄이면서도, 이 트리거에 의존하는 워크플로를 소유자가 의도적으로 허용할 수 있게 한다고 말한다. 규칙은 워크플로 실행 보호를 통해 도입되었고 처음에는 평가 모드로 동작하므로, 소유자는 시행이 시작되기 전에 어떤 워크플로 실행이 차단될지 볼 수 있다.

범위가 중요하며 변경 로그는 이를 좁게 서술한다. 이 변경은 GitHub Free, GitHub Team, GitHub Enterprise Cloud의 공개 저장소에 적용된다. GitHub Enterprise Server에는 적용되지 않는다. 비공개 저장소와 내부 저장소도 영향을 받지 않는다. 따라서 저장소 유형이 섞여 있는 조직은 공개 저장소부터 목록을 만들어야 한다. 실행이 차단될 수 있는 것은 그것들뿐이기 때문이다.

영구 시행에 앞서 GitHub는 예정된 두 번의 브라운아웃 동안 기본 보호를 실제로 적용한다. 날짜는 2026년 11월 9일과 11월 16일이며 각각 UTC 16:00부터 18:00까지다. 이 시간대에는 영향을 받는 공개 저장소에서 기본 규칙이 차단하는 pull_request_target 워크플로 실행 시도가 오류 주석이 달린 실패한 실행이 되고 워크플로는 실행되지 않는다. 각 시간대가 끝나면 규칙은 평가 모드로 돌아가고 워크플로는 경고와 함께 다시 실행된다. 그러므로 브라운아웃은 이 워크플로들에게 서류상의 예행연습이 아니라 실제 중단이다.

변경 로그는 두 가지 선택지를 준다. 첫 브라운아웃 전에 Insights로 규칙이 차단할 워크플로 실행을 확인한다. 그런 다음 기본 규칙을 유지해 트리거를 계속 차단하거나, 워크플로가 의존한다면 해당하는 Actions 이벤트 정책에서 pull_request_target을 명시적으로 허용하되 워크플로 파일 지정으로 특정 워크플로만 허용한다. 저장소 전체에 이벤트를 허용하는 것은 파일 하나를 허용하는 것보다 넓은 결정이며, 변경 로그는 워크플로 실행 제어 방법에 관한 문서를 안내한다.

이 문서에는 변경 로그가 되풀이하지 않는 세부 사항이 있다. 워크플로 실행 보호는 누가 워크플로를 트리거할 수 있는지, 어떤 이벤트가 실행될 수 있는지를 제한하고 잠금 파일(lockfile)을 요구할 수도 있다. 이벤트 규칙은 push, pull_request, pull_request_target, workflow_dispatch 같은 이벤트를 다룬다. 액터 규칙에서는 dependabot[bot]처럼 GitHub 기능에 연결된 ID가 워크플로를 실행해야 할 때 허용된 액터로 추가해야 한다. 정책은 저장소, 조직, 엔터프라이즈 수준에서 설정할 수 있고, 큰 정책 하나보다 명확히 정의된 여러 정책을 권장한다. 확인해야 할 불일치도 있다. 페이지는 정책의 시행 상태로 ‘평가(Evaluate)’를 고르면 사용자가 언제 제한에 걸릴지 정책 인사이트에서 볼 수 있다고 하면서 평가를 GitHub Enterprise Cloud 전용으로 표시한다. 반면 변경 로그는 기본 규칙이 Free, Team, Enterprise Cloud의 공개 저장소에서 평가 모드로 시작한다고 말한다. Free와 Team 소유자가 같은 Insights 화면을 쓸 수 있는지는 이 페이지들만으로는 알 수 없으므로 의존하기 전에 자기 설정에서 확인해야 한다.

실용적인 계획은 짧다. 공개 저장소에서 pull_request_target을 쓰는 워크플로를 모두 찾는다. 각각에 대해 기본 저장소의 시크릿이나 쓰기 권한이 정말 필요한지, pull_request로 충분한지 판단한다. 남겨야 한다면 포크에서 어떤 코드를 체크아웃하는지 검토한다. 규칙이 겨냥하는 것이 바로 그 위험한 패턴이기 때문이다. 그런 다음 그 파일에만 명시적 허용을 추가하고, 담당자와 이유를 기록하고, 11월 9일 시간대에 시험한다. 12월 2일 이후에는 허용 규칙이 없으면 워크플로가 그냥 실행되지 않는다고 생각하면 된다.

오픈소스를 운영하는 팀에게는 또 하나의 의미가 있다. 라벨 자동화, 댓글 봇, 의존성 업데이트 같은 흐름은 그동안 쓰기 권한을 얻으려고 pull_request_target에 기대는 경우가 많았다. 브라운아웃 동안 이런 흐름이 한꺼번에 멈추고 기여자에게는 실패한 검사만 보일 수 있다. 기여 가이드나 고정 이슈에 미리 일정을 알려 두면 유지관리자가 당일에야 자동화가 멈춘 것을 알아차리는 일을 피할 수 있다.