GitHub Actions가 위험한 트리거를 막는다…11월부터 기본 차단
GitHub가 2026년 9월 17일 GitHub Actions의 워크플로 실행 보호 기능을 정식 제공으로 전환했다. GitHub의 공식 변경 기록 에 따르면 적용 가능한 기존 이벤트 정책이 없는 공개 저장소에는 pull_request_target 실행을 막는 기본 정책이 추가됐으며, 현재 evaluate 모드를 거쳐 2026년 11월 2일부터 영향 대상에 자동 집행된다.
이 기본값은 비공개·내부 저장소에는 적용되지 않고, 공개 저장소라도 이미 엔터프라이즈·조직·저장소 계층의 유효한 이벤트 정책을 적용받고 있으면 이를 교체하지 않는다. 독립 기술 보도 도 9월 17일 정식 제공, 공개 저장소의 evaluate 상태, 11월 2일 집행 일정을 같은 범위로 확인했다.
무엇이 정식 제공됐나
워크플로 실행 보호는 실행이 시작되기 전에 주체와 이벤트를 각각 검사한다. actor 규칙은 누가 워크플로를 시작할 수 있는지, event 규칙은 push·pull_request·pull_request_target 같은 어떤 이벤트가 실행을 시작할 수 있는지를 허용 목록으로 관리한다. enforce 상태에서 어느 한 규칙이라도 충족하지 못하면 실행은 거부된다.
정식 제공과 함께 정책을 저장소 전체가 아닌 특정 워크플로 파일에 적용하는 기능, 정책 영향을 확인하는 Insights, 엔터프라이즈·조직·저장소 수준에서 규칙을 생성·조회·수정·삭제하는 REST API가 추가됐다. 워크플로 경로 조건도 API로 관리할 수 있어 여러 저장소의 정책을 코드 기반 구성 관리에 포함할 수 있다.
evaluate 모드는 규칙을 평가하되 실행을 중단하지 않는 단계다. 워크플로는 계속 실행되지만 정책 인사이트에는 enforce 상태였다면 거부됐을 실행이 기록된다. 따라서 11월 2일 전에는 트리거 문자열의 존재만 찾는 데 그치지 않고, 실제 실행 기록과 워크플로 경로를 연결해 영향 범위를 확인해야 한다.
pull_request_target가 위험한 이유
pull_request_target는 포크에서 들어온 풀 리퀘스트에 라벨을 붙이거나 분류 작업과 인증된 상태 검사를 수행할 때 유용하다. 그러나 이 이벤트로 시작한 작업은 기본 저장소의 신뢰 문맥에서 실행돼 기본 저장소의 GITHUB_TOKEN과 저장소·조직 비밀정보에 접근할 수 있다.
트리거 자체가 포크 코드를 자동 실행하는 것은 아니다. 기본 동작에서는 워크플로 파일과 참조를 지정하지 않은 actions/checkout 모두 기본 저장소의 기본 브랜치를 사용한다. 취약점은 워크플로가 풀 리퀘스트의 head나 merge ref, 포크 저장소 또는 외부 아티팩트를 가져온 뒤 빌드·테스트·의존성 설치·스크립트 실행으로 그 내용을 실행할 때 생긴다.
GitHub의 보안 지침 은 actions/checkout뿐 아니라 git fetch, gh pr checkout, 포크의 pull_request 실행에서 내려받은 아티팩트도 같은 신뢰 경계 문제를 만들 수 있다고 설명한다. 포크의 Makefile이나 패키지 스크립트, 설정 파일, 의존성이 기본 저장소의 비밀정보와 권한을 가진 상태에서 실행될 수 있기 때문이다.
반대로 외부 코드를 가져오거나 실행하지 않고 기본 브랜치의 신뢰된 코드만 사용하는 라벨링·분류 워크플로는 위험 구조가 다르다. 관리자가 확인해야 할 것은 트리거 이름만이 아니라 신뢰되지 않은 입력이 실행 가능한 코드로 바뀌는지, 그 순간 비밀정보나 쓰기 권한이 함께 제공되는지다.
11월 2일 차단 대상을 가르는 기준
자동 집행 대상의 첫 조건은 공개 저장소라는 점이다. 두 번째 조건은 해당 저장소에 이미 적용되는 Actions 이벤트 정책이 없어 GitHub의 기본 pull_request_target 정책을 사용하고 있다는 점이다. 공식 설명은 정식 제공 전에 이 기본 정책을 사용하던 영향 대상 저장소에서 2026년 11월 2일 자동 집행한다고 범위를 한정한다.
비공개·내부 저장소에는 이번 기본값이 들어가지 않는다. 다만 기본 정책의 적용 대상이 아니라는 사실이 트리거의 안전성을 보장하지는 않는다. 관리자는 필요하면 같은 실행 보호 정책을 직접 구성할 수 있으며, 기존 정책이 있는 공개 저장소에서는 그 정책의 이벤트 허용 목록과 대상 워크플로 조건이 판단 기준이 된다.
차단은 저장소의 모든 자동화를 멈추는 방식이 아니다. 기본 정책은 pull_request_target 이벤트로 시작되는 실행을 제한한다. 한 워크플로 파일에 push나 workflow_dispatch 같은 트리거가 함께 있어도 각 실행은 실제로 시작한 이벤트를 기준으로 평가된다.
evaluate 단계에서 확인할 순서
점검은 정책 상속 관계를 먼저 확인하고, 차단 예정 실행을 워크플로 파일에 연결한 뒤, 해당 트리거가 계속 필요한지 판단하는 순서로 진행할 수 있다. 여러 조직과 저장소를 관리한다면 YAML 검색만으로는 상위 계층의 정책과 실제 실행 이력을 함께 보기 어렵다.
- 엔터프라이즈, 조직, 저장소 계층에서 적용 중인 Actions actor·event 정책과 각 정책의 evaluate 또는 enforce 상태를 확인한다.
- Policy Insights를 사용할 수 있다면 pull_request_target 때문에 거부될 것으로 평가된 실행을 저장소와 워크플로 경로별로 분류한다.
- Insights 접근 범위 밖의 저장소는 .github/workflows 아래에서 pull_request_target를 검색하고 최근 실행 이력과 대조한다.
- 각 파일에서 풀 리퀘스트 head·merge ref, 포크 저장소, 외부 아티팩트를 가져오는 단계와 이후의 빌드·테스트·설치 명령을 함께 확인한다.
- GITHUB_TOKEN 권한, 저장소·조직 비밀정보, 사설 레지스트리 인증, self-hosted runner의 내부 자원 접근이 필요한지 구분한다.
- 트리거가 불필요하면 pull_request로 옮길 수 있는지 검토하고, 권한 없는 검사와 비밀정보가 필요한 후속 작업을 분리한다.
- pull_request_target가 반드시 필요하면 필요한 워크플로 파일만 대상으로 이벤트를 명시적으로 허용하고 evaluate 결과를 다시 확인한다.
pull_request로 바꾸면 포크에서 온 코드에는 읽기 전용 GITHUB_TOKEN, 비밀정보 제한, 포크 승인 정책이 적용되므로 기존 작업과 권한 조건이 달라질 수 있다. 단순한 트리거 치환으로 기존 동작이 그대로 유지된다고 가정해서는 안 되며, 인증이 필요한 후속 작업은 신뢰되지 않은 코드 처리 단계와 분리해야 한다.
파일별 허용은 좁은 예외로 남겨야 한다
workflow file targeting을 이용하면 필요한 파일만 허용하고 나머지 pull_request_target 실행은 계속 차단할 수 있다. 예를 들어 외부 코드를 실행하지 않는 라벨링 워크플로만 허용하면서 포크 코드를 빌드하는 다른 워크플로에는 기본 제한을 유지하는 식이다. 저장소 전체에 트리거를 허용하는 것보다 예외의 목적과 범위가 명확하다.
파일이 허용 목록에 들어갔다고 내부 동작까지 안전해지는 것은 아니다. 예외 워크플로에는 최소 GITHUB_TOKEN 권한을 적용하고 필요한 비밀정보만 사용해야 한다. 포크에서 가져온 내용은 실행 가능한 입력이 아닌 데이터로만 처리되는지, self-hosted runner가 내부 자원에 접근하거나 실행 간에 재사용되는지도 별도로 확인할 대상이다.
현재 확정된 다음 단계는 2026년 11월 2일의 자동 집행이다. 그전까지 영향 대상의 기본 정책은 evaluate 상태이므로 실행은 계속되지만, 명시적인 허용 정책을 만들거나 트리거 구조를 바꾸지 않으면 해당 날짜부터 pull_request_target로 시작되는 워크플로가 거부된다.
함께 읽기:
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.