GitHub Actions pull_request_target 기본 차단 예고: 12월 2일 전에 CI 점검하기

신뢰할 수 없는 변경과 권한 있는 실행 경로를 분리하는 생성형 개념 이미지다. 실제 GitHub 화면은 아니다.

공개 저장소에서 PR 자동화가 갑자기 실패한다면 테스트 코드보다 실행 정책을 먼저 확인해야 할 수 있다. GitHub가 pull_request_target의 기본 차단 시행일을 예고했다. 대응의 핵심은 영향받는 워크플로를 찾고, PR 코드 테스트와 권한이 필요한 관리 작업을 분리하는 것이다.

언제, 어디에 적용되나

GitHub의 2026년 11월 2일 발표에 따르면 기본 차단은 2026년 12월 2일 시작한다. 종전 예정일은 11월 2일이었다. 적용되는 Actions 이벤트 정책에서 명시적으로 허용한 경우는 예외다.

대상은 GitHub Free·Team·Enterprise Cloud의 공개 저장소다. 비공개·내부 저장소와 GitHub Enterprise Server는 이번 변경 대상이 아니다. pull_request 전체를 차단하는 발표도 아니다.

영구 적용 전 두 차례 시험 차단인 brownout이 있다.

• 11월 9일 16:00–18:00 UTC → 한국 시간 11월 10일 01:00–03:00

• 11월 16일 16:00–18:00 UTC → 한국 시간 11월 17일 01:00–03:00

각 창에서 기본 규칙에 걸리면 오류 주석이 붙은 실패 실행이 만들어지고 워크플로는 실행되지 않는다. 창이 끝나면 evaluate 모드로 돌아가 경고와 함께 실행을 허용한다. 영구 적용의 정확한 시각은 공지에 없으므로 한국 시간 자정으로 단정하지 않는다. GitHub 공식 일정

이름은 비슷하지만 실행의 신뢰 경계가 다르다

pull_request는 PR의 병합 결과를 대상으로 테스트하는 일반적인 경로다. 공개 저장소의 fork PR에서는 읽기 전용 토큰, 비밀정보 제한 등의 보호가 적용된다.

반면 pull_request_target은 원본 저장소 기본 브랜치의 신뢰된 워크플로를 실행한다. fork PR에 라벨을 붙이거나 댓글을 쓰는 관리 작업에 활용할 수 있지만, PR 코드를 빌드하고 실행해야 하는 작업에는 피하라는 것이 공식 문서의 안내다. 이벤트별 실행 문맥

위험한 조합은 권한 있는 실행 안에서 PR의 head를 가져온 다음 테스트나 빌드 명령을 실행하는 것이다. 체크아웃 자체와 코드 실행을 구분해야 한다. 내려받은 Makefile, 설치 스크립트, 설정 또는 의존성이 실행되면서 신뢰 경계가 깨질 수 있다.

이벤트 이름만 바꿔도 해결되지 않는다. workflow_run 같은 다른 권한 있는 경로가 fork 산출물을 받아 실행하면 같은 문제가 생길 수 있다. PR 산출물은 데이터로 취급하고, 출처가 다른 코드를 비밀정보에 접근 가능한 실행에 섞지 않는다. 보안 원리와 주의사항

먼저 사용하는 위치부터 찾는다

다음은 로컬 저장소의 추적 중인 워크플로 파일에서 검토 후보를 찾는 읽기 전용 명령이다.

출력이 없으면 해당 문자열이 없다는 뜻이지, CI 전체가 안전하다는 증거는 아니다. 이 명령은 YAML의 의미를 분석하지 않으며 주석도 잡는다. 호출되는 재사용 워크플로와 외부 액션도 별도로 읽어야 한다.

발견한 파일마다 목적을 한 줄로 적어 보면 전환 방향이 명확해진다.

• PR 코드의 빌드·테스트: 비밀정보 없이 pull_request로 수행할 수 있는지 검토한다.

• 라벨·댓글 등 관리: PR 코드를 실행하지 않고 필요한 최소 권한으로 처리할 수 있는지 확인한다.

• 배포·패키지 발행: 검토된 신뢰 경로와 분리하고, PR 실행의 산출물을 그대로 실행하지 않는다.

다음은 비밀정보가 필요 없는 PR 테스트 작업의 트리거·권한 출발점이다. 완성된 워크플로나 검증된 마이그레이션 결과가 아니며 저장소의 기존 jobs에 맞춰 검토해야 한다.

이벤트를 변경하면 검사 이름과 필수 상태 검사 연결도 확인한다. 테스트가 실행되는지뿐 아니라 병합 조건이 의도대로 충족되는지까지 봐야 한다. 이 확인 항목은 운영상 제안이다.

정책은 넓게 풀기 전에 영향부터 확인한다

공식 안내의 경로는 저장소 또는 조직의 Settings → Actions → Policies, 그리고 Policy insights다. 어떤 실행이 차단됐거나 차단될지 확인할 수 있다.

기존에 적용되는 이벤트 정책은 새 기본 정책으로 대체되지 않는다. 조직·기업·저장소 수준의 보호도 겹쳐 적용될 수 있으므로 저장소 화면의 한 설정만 보고 판단하지 않는다.

pull_request_target이 반드시 필요하다면 해당 워크플로 경로와 대상을 좁혀 정책을 검토한다. 단순히 CI를 다시 녹색으로 만들기 위해 전체 공개 저장소에 광범위한 허용을 넣는 접근은 피한다. 사용자 정의 정책의 Evaluate 선택은 공식 문서상 Enterprise Cloud 전용이므로, 기본 규칙의 사전 평가 안내와 혼동하지 않는다. 정책 생성과 영향 확인

변경 후 무엇을 검증해야 하나

운영 전 다음을 검토 기록으로 남기면 된다.

1. 영향을 받는 파일, 트리거, 토큰 권한, 필요한 비밀정보를 목록화한다.

2. 신뢰하지 않는 PR 코드 또는 산출물이 권한 있는 job에서 실행되지 않는지 확인한다.

3. 비밀정보가 없는 안전한 검증 환경에서 일반 PR과 fork PR의 예상 동작을 비교한다.

4. Policy insights와 실행 로그에서 실제 적용 규칙을 확인한다.

5. brownout 중 실패가 코드 오류인지 정책 차단인지 구분하고, 필요한 필수 검사도 확인한다.

이 글은 2026년 11월 3일 한국 시간 기준 공식 문서를 검토한 설명이다. 실제 저장소 정책을 바꾸거나 GitHub Actions를 실행해 검증한 결과는 아니다. 적용 전 최신 공식 일정과 계정의 정책을 다시 확인해야 한다.