GitHub Actions pull_request_target 11월부터 자동 차단 - CI 멈추기 전 Pwn Request 막는 전환법

🚨 공개 GitHub 저장소에서 pull_request_target을 쓰는 CI/CD라면 지금 한 번 점검할 이유가 생겼습니다. GitHub는 2026년 9월 17일 Workflow Execution Protections를 정식 출시했고, 별도 정책이 없는 공개 저장소에는 pull_request_target을 차단하는 기본 정책을 적용하기 시작했습니다.

👋 Network History 독자 여러분, 안녕하세요. YH입니다.

현재는 Evaluate Mode로 영향을 먼저 확인할 수 있지만, GitHub는 2026년 11월 2일부터 대상 공개 저장소의 기본 정책을 실제로 강제할 예정입니다. 그대로 두면 기존 자동화가 실패할 수 있고, 반대로 무작정 허용하면 오래전부터 문제가 된

Pwn Request

공격면을 다시 열 수 있습니다.

핵심은 “차단을 풀까 말까”가 아닙니다. PR 코드 테스트는 낮은 권한으로, 라벨·댓글·배포처럼 권한이 필요한 작업은 별도 신뢰 경계로 분리하는 것입니다.

오늘은 최신 정책 변경을 계기로 왜 pull_request_target이 위험한지 → 내 저장소 영향 확인 → 안전한 pull_request 전환 → 꼭 필요한 경우의 하드닝 → Evaluate Mode 검증 → 재발방지까지 정리합니다.

📅 정책 변화

공개 저장소 기본 차단 정책은 현재 평가 중이며 11월 2일부터 대상 저장소에 강제됩니다.

⚠️ 핵심 위험

Fork PR의 코드를 높은 권한 Workflow에서 실행하면 Secret·Token 탈취로 이어질 수 있습니다.

🔒 기본 해법

테스트는 pull_request, 권한 작업은 별도 Workflow로 분리합니다.

🧪 안전한 전환

Actions Policies의 Evaluate Mode로 차단될 실행을 먼저 확인한 뒤 적용합니다.

핵심 한 줄

pull_request_target을 계속 허용하는 것보다 “신뢰되지 않은 코드 실행”과 “Secret·쓰기 권한”을 서로 다른 Workflow로 분리하는 것이 장기적인 해법입니다.

---

왜 pull_request_target이 이렇게 위험하게 취급될까요?

pull_request와 pull_request_target은 이름은 비슷하지만 신뢰 수준이 다릅니다.

구분	pull_request	pull_request_target
기본 목적	PR 코드의 빌드·테스트	PR 메타데이터 처리·라벨·댓글 등
Workflow 기준	PR Merge Commit 컨텍스트	Base Repository 기본 브랜치 컨텍스트
권한 수준	Fork PR에서는 제한적	높은 신뢰 컨텍스트
Secret 접근	Fork PR에는 일반적으로 제공되지 않음	Repository·Organization Secret 접근 가능성 존재
주요 위험	테스트 실패·악성 코드 실행 자체	악성 코드 + 높은 권한 결합

문제는 pull_request_target 자체가 악성이라는 뜻이 아닙니다. 이 이벤트는 외부 기여자의 PR에도 라벨을 붙이거나 댓글을 남겨야 할 때처럼 높은 권한이 필요한 자동화를 위해 존재합니다.

위험은 여기에 신뢰되지 않은 Fork PR 코드를 Checkout하고 실제로 실행하는 순간 생깁니다.

Fork PR → pull_request_target → PR Head Checkout → Build·Test 실행 → Secret·Token 위험

Checkout만 했다고 바로 취약한 것은 아닙니다.

GitHub 문서가 강조하는 핵심은 공격자가 제어하는 코드를 높은 권한 컨텍스트에서 실행하는 것입니다. npm install, make test, Build Script, 설정파일, Dependency Hook도 모두 실행 경로가 될 수 있습니다.

---

내 저장소가 영향을 받는지 먼저 찾는 방법

정책이 적용되기 전에 가장 먼저 해야 할 일은 저장소에서 pull_request_target을 실제로 쓰는 Workflow를 찾는 것입니다.

로컬 Repository에서 Trigger 검색

grep -R -n "pull_request_target" .github/workflows

결과가 있다면 해당 Workflow에서 PR의 Head Commit이나 Fork Repository를 다시 가져오는 코드가 있는지 확인합니다.

grep -R -nE "head\.sha|head\.repo|refs/pull|gh pr checkout|git fetch" .github/workflows

패턴	위험 판단
라벨·댓글만 처리	코드 실행이 없다면 상대적으로 낮은 위험
Fork PR Head Checkout	주의 필요
Checkout 후 npm install / test / build	높은 위험
Secret 사용 + PR 코드 실행	최우선 수정 대상
write 권한 GITHUB_TOKEN + PR 코드 실행	최우선 수정 대상

actions/checkout만 검색하면 놓칠 수 있습니다.

GitHub가 강화한 actions/checkout 보호는 흔한 위험 패턴을 막아주지만, git fetch, gh pr checkout, 외부 Artifact 다운로드처럼 다른 방법으로 신뢰되지 않은 코드를 가져와 실행하는 경우까지 모두 없애주지는 않습니다.

---

가장 안전한 기본형은 테스트를 pull_request로 옮기는 것입니다

습니다. 이 작업은 낮은 신뢰 컨텍스트인 pull_request로 옮기는 것이 기본입니다.

name: PR Test

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Install
        run: npm ci

      - name: Test
        run: npm test

이 구조의 장점은 Fork PR에서 공격자가 Build Script를 바꾸더라도 Repository Secret과 높은 쓰기 권한이 같은 실행공간에 존재하지 않도록 하는 것입니다.

기본 원칙

신뢰되지 않은 코드 실행 = 낮은 권한 / Secret·쓰기 권한 = 신뢰된 코드만

필요한 권한도 명시적으로 줄이는 것이 좋습니다. 단순 테스트라면 contents: read 정도로 충분한지 먼저 검토하고, 불필요한 write 권한은 주지 않습니다.

---

라벨·댓글 자동화는 pull_request_target을 남길 수 있습니다

pull_request_target이 항상 제거 대상은 아닙니다. 외부 PR에 라벨을 붙이거나, 메타데이터를 읽고 댓글을 남기는 자동화처럼 PR 코드를 실행하지 않는 작업에는 여전히 유용합니다.

name: PR Triage

on:
  pull_request_target:
    types: [opened]

permissions:
  contents: read
  pull-requests: write

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v8
        with:
          script: |
            await github.rest.issues.addLabels({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              labels: ['needs-review']
            })

이 Workflow에는 PR Head Code를 Checkout하는 단계가 없습니다. 공격자가 수정한 Repository 파일을 Build하거나 실행하지도 않습니다.

권한이 필요한 Workflow에서는 “코드를 안 가져오는 것”도 강력한 방어입니다.

Secret을 지키려면 Secret masking에만 의존하기보다, 공격자가 제어하는 코드와 Secret이 같은 Job 안에서 만날 수 없도록 구조적으로 분리하는 편이 좋습니다.

---

꼭 pull_request_target이 필요하다면 다섯 가지를 같이 보세요

업무상 pull_request_target이 꼭 필요한 환경이라면 Trigger 하나만 허용하고 끝내면 안 됩니다.

1

PR Code 실행 여부 확인
Fork Head·Merge Commit·외부 Repository를 가져와 Build·Test·Install하지 않는지 확인합니다.

2

GITHUB_TOKEN 최소권한
Workflow에 실제로 필요한 read/write 범위만 명시합니다.

3

Secret 최소화
해당 Job에 필요하지 않은 Repository·Organization Secret을 참조하지 않습니다.

4

Cache 쓰기 제한
pull_request_target과 같은 낮은 신뢰 Trigger가 공유 Cache를 오염시키지 않도록 기본 read-only 보호를 유지합니다.

5

정책으로 허용범위 좁히기
Repository 전체가 아니라 필요한 Workflow 파일에만 Execution Policy를 적용하는 방식도 검토합니다.

GitHub는 Workflow Execution Protections의 GA와 함께 Workflow File Targeting을 제공해, 예를 들어 일반 CI는 열어두되 배포 Workflow만 특정 Actor·Event로 제한하는 식의 정책 설계가 가능해졌습니다.

---

11월 2일 전에 Evaluate Mode로 먼저 검증하세요

공개 저장소에 대한 기본 pull_request_target 정책은 곧바로 모든 Workflow를 끊는 방식이 아닙니다. GitHub는 먼저 Evaluate Mode에서 어떤 실행이 차단될지를 볼 수 있도록 제공합니다.

1

Settings → Actions → Policies
Repository 또는 Organization의 Actions 정책 화면을 엽니다.

2

현재 Event Policy 확인
pull_request_target 관련 기본 또는 사용자 정책이 있는지 확인합니다.

3

Evaluate 결과 확인
Policy Insights에서 어떤 Workflow Run이 향후 차단될지 확인합니다.

4

안전한 Workflow로 전환
가능하면 pull_request로 옮기고, 권한작업은 별도 Workflow로 분리합니다.

5

필요한 경우만 명시적 허용
하드닝을 끝낸 특정 Workflow만 Allowlist 하는 방식으로 범위를 줄입니다.

기본 차단은 모든 저장소에 동일하게 적용되는 것이 아닙니다.

GitHub의 현재 안내 기준으로 기본 정책은 적용 가능한 별도 Event Policy가 없는 공개 저장소를 대상으로 하며, Private·Internal Repository에는 이 기본 차단이 적용되지 않습니다.

---

actions/checkout 보호가 있어도 구조적 분리는 계속 필요합니다

GitHub는 2026년 중 actions/checkout에도 pull_request_target에서 Fork PR Head를 위험하게 가져오는 일반적인 패턴을 차단하는 보호를 강화했습니다.

하지만 이것만 믿고 Workflow를 그대로 두는 것은 충분하지 않습니다.

상황	checkout 보호로 해결?
위험한 Fork Head checkout	대표적인 패턴은 차단 가능
git fetch로 직접 가져오기	별도 검토 필요
gh pr checkout 사용	별도 검토 필요
Untrusted Artifact 실행	별도 검토 필요
issue_comment 등 다른 Privileged Trigger	별도 검토 필요

결국 가장 오래 가는 보안 설계는 특정 Action이 막아주기를 기다리는 것이 아니라

Untrusted Code와 Privileged Context를 아키텍처 수준에서 분리

하는 것입니다.

---

Workflow를 두 단계로 나눌 때도 Artifact를 신뢰하지 마세요

복잡한 프로젝트에서는 pull_request Workflow에서 테스트를 수행하고, 후속 workflow_run에서 권한이 필요한 작업을 수행하는 구조를 사용할 수 있습니다.

이때도 첫 Workflow가 만든 Artifact를 두 번째 Privileged Workflow가 무조건 신뢰해 실행하면 다시 공격경로가 생길 수 있습니다.

Untrusted PR → Low-Privilege Test → Artifact = Untrusted Data → 검증 → Privileged Action

“Workflow를 분리했으니 안전하다”가 아닙니다.

신뢰되지 않은 Workflow가 만든 실행파일·Script·압축파일을 Privileged Workflow에서 실행하면 경계가 다시 무너집니다. 후속 Workflow에는 필요한 최소 데이터만 전달하고, 실행 가능한 Artifact는 특히 신중하게 다뤄야 합니다.

---

조직에서는 YAML 수정과 정책 적용을 함께 가져가세요

Repository가 수십·수백 개라면 각 팀이 YAML을 올바르게 작성하기를 기다리는 것만으로는 한계가 있습니다.

Workflow Execution Protections는 Actor Rule과 Event Rule을 Enterprise·Organization·Repository 수준에서 적용할 수 있고, Evaluate Mode로 영향도를 먼저 볼 수 있습니다.

보호층	역할
Workflow YAML	최소권한·안전한 Trigger·Secret 분리
Checkout 보호	대표적인 Pwn Request 패턴 차단
Execution Policy	허용 Actor·Event를 실행 전에 통제
Code Scanning	위험한 Actions Workflow 패턴 탐지
Review	정책 예외와 Privileged Workflow 변경 감시

정책은 잘못된 Workflow가 실행되기 전에 막는 방어선이고, YAML 하드닝은 Workflow 자체의 공격면을 줄이는 방어선입니다. 둘 중 하나만 선택할 필요는 없습니다.

---

마무리

GitHub의 2026년 9월 Workflow Execution Protections GA는 단순한 새 설정 메뉴가 아닙니다. 공개 저장소의 pull_request_target이 얼마나 자주 잘못 사용돼 왔는지를 보여주는 변화이기도 합니다.

11월 2일 전까지 해야 할 일은 단순히 차단 정책을 해제하는 것이 아닙니다. PR 코드를 실제로 실행해야 하는 Workflow는 pull_request로 이동하고, 권한이 필요한 자동화는 PR 코드를 실행하지 않는 별도 Workflow로 분리하는 것이 먼저입니다.

🔐 오늘 하나만 점검한다면 Repository에서 pull_request_target을 검색한 뒤, 그 Workflow가 Fork PR 코드를 가져와

Build·Install·Test 중 하나라도 실행하는지

확인해보세요. 그 한 줄이 Pwn Request 여부를 가르는 가장 중요한 출발점입니다.

👋 Network History의 YH였습니다.

※ 이 글은 2026년 9월 18일 기준 GitHub 공식 Changelog와 GitHub Actions 보안 문서를 바탕으로 작성했습니다. Workflow Execution Policy의 적용범위와 기본정책 일정은 이후 변경될 수 있으므로 실제 적용 전 최신 GitHub 문서를 다시 확인하세요.

---

🔗 공식 출처

🚨 Workflow Execution Protections GA 🛡️ pull_request_target 보안 가이드 ⚙️ Workflow Execution 제어 🔐 GitHub Actions Secure Use 📦 actions/checkout 보호 변경