GitHub Actions 실행 보호는 actor·event·workflow 파일별 allowlist로 실행 범위를 줄이고, Evaluate에서 영향 범위를 본 뒤 강제하는 기능입니다.
이 글은 2026년 10월 7일 기준 GitHub 공식 변경 공지와 Actions 정책 문서를 읽고, 계정·토큰·저장소 권한 없이 정책 판단의 흐름을 재현한 로컬 실습을 함께 기록합니다. 핵심은 “GitHub에서 실행했다”는 주장과 “공식 문서의 규칙을 자체 fixture로 계산했다”는 사실을 분리하는 것입니다. 아래 결과는 GitHub Actions의 실제 실행 결과나 보안 보증서가 아니며, 정책 설계를 시작하기 전에 확인할 순서와 실패 경계를 보여 주는 작은 smoke test입니다.
워크플로 실행 보호가 해결하는 질문
Actions 보안에서 흔한 질문은 “이 YAML 파일이 안전한가?”로 시작하지만, 실제 운영에서는 그보다 앞선 권한 경계가 있습니다. 누가 실행할 수 있는가, 어떤 이벤트가 시작점이 될 수 있는가, 특정 workflow만 더 엄격하게 제한할 것인가, 정책을 강제하기 전에 어떤 실행이 영향을 받는가를 함께 정해야 합니다. GitHub는 2026년 9월 17일 변경 공지에서 워크플로 실행 보호가 공개 프리뷰를 벗어나 Enterprise·조직·저장소에 일반 제공된다고 설명했습니다. 보호 규칙은 actor와 event를 각각 allowlist로 다루고, 한 번의 실행 전에 두 조건을 함께 평가합니다.
이 구조는 쓰기 권한과 실행 권한을 분리할 때 유용합니다. 문서상 기본값은 저장소에 쓰기 권한이 있는 사용자가 workflow를 실행할 수 있는 상태지만, actor 규칙으로 기여자는 코드를 제출하되 배포 workflow를 직접 시작하지 못하게 분리할 수 있습니다. event 규칙은 push, pull_request, pull_request_target, workflow_dispatch처럼 어떤 사건을 허용할지 통제합니다. 즉, 단순히 “Actions를 켠다/끈다”가 아니라 실행 주체와 실행 사건을 조합해 통제하는 모델입니다.
정식 제공에 추가된 범위도 운영 관점에서 중요합니다. 정책을 저장소 전체가 아니라 특정 workflow 파일에 적용할 수 있고, Insights에서 정책이 실제 실행을 어떻게 평가·차단했는지 살펴볼 수 있으며, Enterprise·조직·저장소 수준의 REST API로 규칙을 코드로 관리할 수 있습니다. 이 세 요소를 합치면 민감한 deploy.yml에는 강한 정책을 두고 일반적인 ci.yml에는 다른 규칙을 적용하며, 변경 전후의 영향을 기록하는 정책-as-code 흐름을 설계할 수 있습니다.
평가 모드와 pull_request_target의 경계
처음부터 강제 모드로 바꾸면 정상 배포까지 막을 수 있습니다. GitHub 문서는 Enterprise Cloud에서 Evaluate를 선택하면 아직 제한을 적용하지 않고 정책이 어떤 실행을 막게 될지 Insights에서 관찰할 수 있다고 안내합니다. 따라서 첫 단계는 대상 조직·저장소·workflow 파일을 작게 잡고, 평가 결과에서 허용되어야 할 실행과 차단되어야 할 실행을 분류하는 것입니다. 운영팀이 기대하는 허용 목록과 실제 이벤트 이름이 다르면, 강제 전에 fixture와 테스트 저장소에서 먼저 수정해야 합니다.
pull_request_target는 특히 별도 확인이 필요합니다. GitHub의 공식 공지는 이 이벤트가 기본 저장소의 비밀에 접근할 수 있는 문맥에서 실행되므로, fork의 신뢰하지 않은 코드가 파이프라인을 오염시키거나 비밀을 빼낼 위험이 있다고 설명합니다. 공개 저장소에서 별도 event 정책이 없으면 GitHub가 이 이벤트를 제한하는 기본 규칙을 도입했고, 2026년 11월 2일 affected repository에 자동 강제할 예정이라고 밝혔습니다. 현재 문서와 공지는 이 기본 규칙이 처음에는 evaluate 모드로 동작한다고 적고 있으므로, 공개 저장소라면 Insights에서 영향을 받는 workflow를 미리 확인해야 합니다.
이 일정은 “11월 2일까지 무조건 허용 목록을 바꿔라”는 뜻이 아닙니다. 먼저 해당 이벤트가 정말 필요한지, 필요한 경우에도 어떤 workflow 파일과 어떤 actor만 허용해야 하는지 결정해야 합니다. 명시적인 예외를 추가한다면 그 이유와 비밀 접근 여부를 기록하고, 일반 CI와 배포·릴리스 작업을 같은 정책으로 뭉뚱그리지 않는 편이 안전합니다.
직접 실행 결과: 계정 없는 로컬 정책 모형
실제 GitHub 조직이나 저장소에 로그인하지 않고, 위 규칙의 판단 흐름만 자체 작성한 브라우저 fixture로 재현했습니다. 입력은 네 건입니다. deploy.yml을 release-bot이 workflow_dispatch로 시작하는 경우는 허용, 같은 workflow를 contributor가 수동 실행하는 경우는 차단, 일반 ci.yml에 대한 pull_request는 허용, deploy.yml의 pull_request_target는 차단으로 고정했습니다. actor·event·workflow-file 세 필드를 표로 보여 주고, 버튼을 누르면 평가 모형이 각 케이스를 분류합니다.
2026년 10월 7일 Windows 독립 Chromium 1200×675 viewport에서 실행한 결과는 허용 2건, 차단 2건, policy insights 4건, enforcement mode는 EVAL입니다. 시작 화면과 결과 화면은 같은 독립 세션의 WebP로 저장했고, 버튼을 눌러 시작 상태가 결과 상태로 바뀌는 실제 프레임 변화 WebM도 저장했습니다. 이 실습은 네트워크 요청·로그인·API 키·GitHub 저장소 쓰기를 하지 않았습니다. 따라서 확인한 것은 “고정된 actor/event/file 조건을 정책 결과로 바꾸는 브라우저 계산”뿐이며, GitHub의 실제 정책 엔진이나 Insights 화면을 재현한 것이 아닙니다.
정책-as-code로 옮길 때의 순서
첫째, 보호 대상을 workflow 파일 단위로 분리합니다. 배포·릴리스·환경 승격처럼 비밀과 운영 권한이 연결된 파일은 일반 테스트 workflow보다 강한 actor와 event 조건을 적용할 이유가 있습니다. 모든 파일을 한 번에 잠그면 예외를 늘리게 되므로, 민감도와 배포 상태를 기준으로 정책 대상을 구분하고 그 기준을 문서에 남깁니다.
둘째, Evaluate에서 관찰할 입력을 정합니다. 최소한 actor, event, workflow path, 저장소 공개 여부, 정책이 적용된 계층을 기록하고, 허용·차단·예상 밖의 세 그룹으로 결과를 분류합니다. 단순히 차단 건수를 줄이는 것이 목표가 아닙니다. 배포 workflow를 contributor가 실행하게 되는 실수가 없는지, 반대로 정상적인 pull request 검증이 전부 막히지 않는지를 확인해야 합니다. Insights는 이런 영향 범위를 확인하는 보조 자료이지, 사람의 보안 검토를 대신하는 증명은 아닙니다.
셋째, 여러 계층의 정책을 겹쳐 적용할 때 우선순위를 확인합니다. GitHub 문서는 Enterprise·조직·저장소 수준에서 정책을 구성할 수 있고, 각 계층의 보호가 함께 작동한다고 안내합니다. Enterprise에서 절대 허용하지 않을 이벤트, 조직에서 공통으로 관리할 actor, 저장소에서만 필요한 workflow path를 분리하면 예외가 덜 퍼집니다. REST API를 사용할 때는 조회·생성·수정·삭제 권한과 대상 계층을 명확히 하고, 정책 변경 자체도 코드 리뷰와 승인 대상으로 둡니다.
넷째, 강제 이후의 관찰도 설계합니다. 차단된 실행의 사용자 메시지와 workflow path를 기록하고, 정책 변경 전후의 실패율·정상 배포 지연·예외 승인 수를 비교합니다. 이때 로그에 토큰, 비밀값, 비공개 diff를 남기지 않도록 하고, public fork에서 실행되는 코드가 base repository의 권한 문맥과 섞이지 않는지 점검합니다. 정책이 있다는 이유만으로 workflow 내부의 셸 명령이나 third-party action을 안전하다고 판단해서는 안 됩니다.
한계와 실패 조건
이번 로컬 결과의 숫자 2·2·4는 GitHub의 실제 실행 통계가 아닙니다. 자체 fixture의 네 케이스를 고정된 규칙으로 분류한 값이므로, GitHub Actions의 정책 API 응답·Insights 기록·실제 workflow 로그로 바꾸어 말할 수 없습니다. 또한 GitHub Enterprise Cloud 계정, 조직 소유자 권한, 저장소 관리자 권한을 확인하지 않았고, 정책 생성·평가 모드 연결·pull_request_target 호출은 이번 범위에 포함되지 않았습니다.
다음 조건이면 강제하지 않고 보류해야 합니다. 대상 workflow path가 불명확할 때, actor와 event가 실제 운영 흐름과 맞지 않을 때, Evaluate 결과를 읽지 않은 채 정책을 강제하려 할 때, 예외가 왜 필요한지 설명할 수 없을 때, 공개 fork 코드와 비밀 접근 문맥을 함께 실행할 때, 또는 로컬 fixture 결과를 GitHub 제품 사용 경험으로 표현할 때입니다. 특히 public repository의 기본 규칙 일정은 공식 문서가 갱신될 수 있으므로 적용일과 현재 상태를 발행 전에 다시 확인해야 합니다.
안전한 연습과 실제 적용 사이에도 차이가 있습니다. 로컬 fixture는 입력을 통제하고 외부 부작용을 제거했지만, 실제 정책은 저장소 계층·팀·봇 계정·권한·기존 workflow·third-party action과 결합됩니다. 그러므로 이 글의 캡처와 영상은 설계 순서를 설명하는 증거로만 사용하고, 조직 설정을 바꾸는 근거로 단독 사용하지 않습니다.
실무 체크리스트
- 보호할 workflow path와 공개·비공개 저장소 범위를 먼저 고정했는가?
- actor allowlist와 event allowlist를 각각 검토했는가?
- Evaluate에서 정상 실행과 차단되어야 할 실행을 분리해 읽었는가?
pull_request_target과 fork 코드의 비밀 접근 경계를 확인했는가?- Enterprise·조직·저장소 계층의 정책 중복과 예외 이유를 기록했는가?
- REST API 변경에 코드 리뷰·승인·감사 로그를 연결했는가?
- 로컬 모형의 결과를 GitHub 실제 실행 결과로 과장하지 않았는가?
외부 상태를 바꾸기 전 승인과 stage-only 경계를 분리하는 예시는 이 사이트의 npm stage-only 토큰과 사람 승인 경계 점검 글에서도 확인할 수 있습니다. 이 링크는 GitHub 정책 실행 결과가 아니라, 승인 전에는 공개나 배포를 진행하지 않는 운영 원칙을 연결하는 내부 참고입니다.
공식 출처와 검증일
공식 사실은 2026년 10월 7일 다음 GitHub 1차 자료를 대조했습니다. 변경 공지는 일반 제공 범위, workflow 파일 대상 지정, Insights, REST API, public repository의 pull_request_target 기본 보호와 2026년 11월 2일 강제 예정일을 설명합니다. Actions 정책 문서는 actor·event allowlist와 정책 계층을, 실행 제어 문서는 대상 workflow·Evaluate 모드·Insights 확인 순서를 설명합니다. 본문의 직접 증거는 이 문서들을 읽고 만든 계정 없는 로컬 정책 모형의 실행 결과입니다.