깃허브 Actions 실행 보호 정식 제공…공개 저장소 기본 정책 점검 필요

깃허브 Actions를 쓰는 개발팀이 먼저 살펴볼 항목은 저장소 공개 여부와 pull_request_target 이벤트의 기존 정책이다. 깃허브는 9월 17일 실행 보호 기능의 정식 제공을 발표하면서, 해당 이벤트에 적용되는 정책이 없는 공개 저장소에서 실행을 차단하도록 설계한 새 기본 규칙을 안내했다. 비공개·내부 저장소는 이 기본 규칙의 대상에서 제외된다.

정식 제공 시점과 차단이 강제되는 시점은 구별해야 한다. 회사가 예고한 자동 강제 적용일은 2026년 11월 2일이며, 대상은 정식 제공 이전부터 기본 pull_request_target 정책을 사용하던 영향 대상 저장소다. 모든 저장소에 같은 날 일괄 적용한다는 발표는 아니다. 새 기본 규칙은 실제 차단 전 영향을 살펴보는 evaluate 모드에서 시작한다고 회사는 설명했다.

운영자가 선택할 수 있는 대응은 기본 차단 규칙을 유지하거나, 적용 가능한 이벤트 정책에 pull_request_target 허용을 명시하는 것이다. 깃허브는 특정 워크플로 파일만 허용하는 설정도 안내했다. 따라서 이 이벤트를 사용하는 팀이라면 허용이 필요한 파일과 실행 조건을 먼저 정리하고, 정책 적용에 따른 영향을 확인하는 순서로 준비할 수 있다.

회사 설명에 따르면 실행 보호는 엔터프라이즈·조직·저장소 단위에서 실행 주체와 이벤트의 허용 규칙을 실행 전에 평가한다. 정식 제공에는 워크플로 파일별 규칙 지정, 평가·집행 결과를 확인하는 Insights, 세 관리 단위의 규칙을 생성·조회·수정·삭제하는 REST API가 추가됐다. 미리보기에서 제공하던 평가 모드도 유지된다. 회사는 기본 정책 변경에 앞서 Insights로 영향을 확인하도록 안내했다.

배포 권한을 좁히는 별도 배경 사례도 있다. 클라우드플레어는 9월 15일 사용자와 API 토큰의 접근 대상을 개별 Worker로 지정하는 기능을 전체 고객에게 제공한다고 발표했다. 회사가 설명한 자동 배포용 Editor 토큰은 해당 Worker의 코드를 배포할 수 있지만, Worker 삭제나 다른 애플리케이션 접근은 허용 범위에 포함하지 않는다.

클라우드플레어는 라우트나 사용자 지정 도메인 연결을 바꾸려면 Worker의 Editor 권한과 해당 zone의 Workers Routes 권한이 함께 필요하다고 설명했다. 기존 연결을 유지하는 새 버전 배포에는 연결된 zone이나 리소스의 접근 권한이 필요하지 않다는 안내다. 이는 배포 대상의 작업 권한에 관한 발표로, 깃허브의 실행 보호 기능을 검증한 자료는 아니다. 제공된 두 발표에는 외부 보안 효과 검증이나 직접 시험 결과가 포함돼 있지 않다.