GitHub Actions, 11월 pull_request

GitHub는 2026년 9월 17일 GitHub Actions의 워크플로 실행 보호를 정식 출시했다. GitHub의 정식 출시 공지 에 따르면 기존에 적용 가능한 이벤트 정책이 없는 공개 저장소에는 pull_request_target 실행을 막는 기본 정책이 추가됐으며, 현재는 실행을 중단하지 않는 평가 모드로 작동한 뒤 2026년 11월 2일 집행된다.

9월 17일 발표 기준 직접적인 점검 대상은 모든 저장소가 아니라, 별도의 적용 가능한 이벤트 정책 없이 pull_request_target을 사용하는 공개 저장소와 그 워크플로다. Reveneau의 같은 날 보도 도 정식 출시와 평가 모드, 11월 2일 집행 일정을 정리했다. 해당 팀은 집행 전에 Policy insights에서 차단 후보를 찾고, pull_request로 바꿀지 필요한 워크플로만 명시적으로 허용할지 결정해야 한다.

정식 출시는 끝났지만 기본 차단은 아직 평가 중이다

이번 변경에는 서로 다른 두 상태가 겹쳐 있다. 행위자와 이벤트의 허용 목록을 실행 전에 함께 평가하는 워크플로 실행 보호는 공개 미리보기를 마치고 정식 출시됐다. 반면 공개 저장소에 자동으로 추가되는 pull_request_target 기본 정책은 아직 평가 모드여서 기존 실행이 계속되고, 정책을 집행했을 때 거부될 실행만 Policy insights에 표시된다.

정식 출시와 함께 정책을 특정 워크플로 파일에만 적용하는 기능, 평가·집행 결과를 확인하는 Insights, 엔터프라이즈·조직·저장소 수준에서 정책을 관리하는 REST API가 제공된다. 따라서 하나의 저장소 안에서도 일반 CI와 높은 권한이 필요한 자동화를 구분해 서로 다른 허용 범위를 설정할 수 있다.

기본 정책은 비공개 저장소와 내부 저장소에는 적용되지 않는다. 공개 저장소라도 이미 적용 가능한 Actions 이벤트 정책이 있다면 새 기본 정책이 기존 설정을 대체하지 않는다. 11월 2일 자동 집행 대상은 정식 출시 전에 기본 pull_request_target 정책을 사용하던 영향 대상 저장소로 한정된다.

왜 pull_request_target을 일괄 제한하는가

pull_request_target은 포크에서 들어온 PR에 라벨을 붙이거나 분류하고, 인증된 상태 검사를 게시하는 자동화에 유용하다. 이 이벤트로 시작한 작업은 기본 저장소의 신뢰 수준에서 실행되므로 기본 저장소의 GITHUB_TOKEN과 저장소·조직 시크릿에 접근할 수 있다.

이벤트 자체가 곧 취약점인 것은 아니다. 기본 동작에서는 워크플로 파일과 별도의 참조를 지정하지 않은 체크아웃이 기본 브랜치에서 오기 때문에 포크의 코드를 실행하지 않는다. 위험은 워크플로가 PR의 head나 포크 저장소에서 코드를 가져온 뒤 빌드, 테스트, 의존성 설치 같은 명령으로 실행할 때 생긴다.

GitHub의 pull_request_target 보안 지침 은 이 조합에서 공격자가 수정한 빌드 스크립트나 의존성, 설정 파일이 기본 저장소의 토큰과 시크릿을 가진 상태로 실행될 수 있다고 경고한다. 새 기본 정책은 워크플로 내용을 분석해 위험한 실행만 골라내는 탐지 기능이 아니라 해당 이벤트를 기본적으로 허용하지 않는 정책이므로, 안전하게 설계된 사용 사례도 명시적 허용이 없으면 차단될 수 있다.

평가 모드에서 확인할 감사 순서

첫 단계는 관리 대상 저장소를 공개, 내부, 비공개로 나누고 공개 저장소 가운데 적용 가능한 이벤트 정책이 없는 곳을 추리는 것이다. 이어 Policy insights에서 현재는 허용되지만 집행 후 거부될 실행과 해당 워크플로 파일을 확인하면 단순 문자열 검색보다 실제 영향 범위를 정확히 좁힐 수 있다.

공개 저장소 가운데 적용 가능한 Actions 이벤트 정책이 없는 대상을 식별한다.
Policy insights에서 pull_request_target 때문에 향후 거부될 실행과 워크플로 경로를 확인한다.
해당 워크플로가 PR head, 포크 저장소의 코드 또는 포크 실행에서 생성된 아티팩트를 가져오는지 조사한다.
가져온 내용을 빌드·테스트·설치 단계나 스크립트가 실행하는지 확인한다.
시크릿과 쓰기 권한이 필요하지 않다면 pull_request로 전환할 수 있는지 판단한다.
이벤트 유지가 불가피하다면 저장소 전체가 아니라 필요한 워크플로 파일만 허용할 수 있는지 결정한다.

평가 결과가 없다고 해서 워크플로 정의 자체의 검토를 생략해서는 안 된다. 관찰 기간에 해당 이벤트가 우연히 실행되지 않았다면 Policy insights에도 기록이 나타나지 않을 수 있기 때문이다. 실행 기록과 함께 .github/workflows의 이벤트 선언, checkout 대상, 이후 실행 단계, 토큰 권한과 시크릿 사용을 대조해야 한다.

pull_request로 바꿀지 예외를 둘지

시크릿이나 쓰기 권한이 필요 없는 PR 검사라면 pull_request가 우선 검토 대상이다. 포크 PR에서 이 이벤트는 읽기 전용 GITHUB_TOKEN을 사용하고 다른 시크릿을 제공하지 않으며, PR의 병합 브랜치에서 워크플로 코드를 실행한다. 신뢰할 수 없는 변경 코드와 높은 권한을 같은 실행에 결합하지 않는 선택이다.

라벨링, 분류 또는 인증된 상태 게시처럼 기본 저장소 권한이 필요한 자동화는 pull_request_target을 계속 사용해야 할 수 있다. 이 경우 적용 가능한 Actions 이벤트 정책을 만들거나 수정해 이벤트를 명시적으로 허용해야 한다. 새 워크플로 파일별 대상 기능을 이용하면 필요한 파일만 허용하고 같은 저장소의 다른 워크플로에는 기본 차단을 유지할 수 있다.

예외는 위험성 검토를 대신하지 않는다. 유지할 워크플로는 GITHUB_TOKEN 권한과 사용 시크릿을 최소화하고, 포크에서 가져온 코드나 아티팩트를 높은 권한으로 실행하는 경로가 없는지 확인해야 한다. pull_request_target 워크플로의 기본 브랜치 캐시는 읽기 전용이지만 쓰기 가능한 cache-mode를 명시하면 캐시 오염 위험이 다시 생길 수 있으며, 자체 호스팅 러너는 내부 자원과 격리하고 실행 간에 재사용하지 않는 구성이 필요하다.

11월 2일 이후 달라지는 것

현재 확정된 상태는 실행 보호의 정식 출시와 기본 정책의 평가 모드, 그리고 2026년 11월 2일 집행 일정이다. 평가 기간에는 워크플로가 계속 실행되지만, 집행 뒤에는 정책이 허용하지 않은 pull_request_target 이벤트가 실행 단계에 들어가기 전에 거부된다.

영향 대상 팀의 선택지는 세 가지다. 일반 PR 검증은 pull_request로 옮기고, 필요하지 않은 pull_request_target은 기본 차단 상태로 두며, 높은 권한이 꼭 필요한 자동화만 파일 단위 정책으로 명시적으로 허용하는 것이다. 집행 전 확인해야 할 핵심은 이벤트 이름의 존재 여부만이 아니라, 각 워크플로가 어떤 코드를 어느 권한으로 실행하는지와 그 권한이 실제로 필요한지다.

함께 읽기:

GitHub가 위험한 PR 워크플로를 막는다…11월 전 영향부터 확인하라