GitHub Actions pull_request_target 기본 규칙, 맥 CI는 어떻게 검증할까? 2026

GitHub는 2026년 9월 17일 workflow execution protections의 정식 제공을 발표했습니다. 공지에 따르면 적용 가능한 이벤트 정책이 없는 공개 저장소는 먼저 평가 모드로 영향을 확인하며, 대상 저장소의 기본 규칙 자동 실행 예정일은 2026년 12월 2일입니다. 비공개 및 내부 저장소는 이 기본 규칙의 적용 대상이 아닙니다. 공식 공지에서 적용 범위와 일정을 확인하세요.

• [ ] 조직의 저장소 목록에서 공개·비공개·내부 상태를 각각 확인합니다.
• [ ] 공개 저장소마다 적용 중인 조직 및 저장소 이벤트 정책을 확인합니다. Actions 정책 관리 문서를 참고해 정책 범위가 기본 규칙과 겹치는지 살펴보세요.
• [ ] pull_request_target을 사용하는 워크플로 파일과 용도를 기록합니다. 저장소가 공개라는 사실만으로 해당 워크플로가 자동으로 영향을 받는다고 판단하지 않습니다.

저장소 목록에는 소유 팀, 워크플로 파일 경로, 업무 목적, 정책 담당자를 함께 적어 두세요. 이후 평가 결과가 나오면 같은 기록에 연결할 수 있습니다.

평가 모드는 정책의 영향 가능성을 관찰하는 단계입니다. 이 결과를 실제 실행 차단으로 오해하면 안 됩니다. GitHub의 Actions 사용 지표 안내를 확인하고, 결과를 저장소와 워크플로 파일에 연결하세요.

• [ ] 평가 결과에서 허용되지 않는 것으로 판정된 이벤트와 워크플로를 확인합니다.
• [ ] 각 결과를 저장소, 파일 경로, 담당자, 업무 목적에 연결합니다.
• [ ] 반복 관찰 결과와 예외가 필요한 사유를 기록하고, 한 번의 평가만으로 장기 영향이 없다고 결론 내리지 않습니다.

GitHub Actions Insights에서 확인한 결과는 재검토의 출발점입니다. 이벤트 정책 변경 전후에 평가 기록을 다시 확인하고, 정책 구성과 실제 실행 결과를 따로 보관하세요.

pull_request_target에서 중요한 위험은 맥 하드웨어가 아니라 신뢰되지 않는 코드가 어떤 권한으로 실행되는가입니다. GitHub는 이 이벤트에서 기본 저장소 권한과 시크릿이 관여할 수 있다고 설명합니다. 포크 PR의 코드를 가져와 실행하는 흐름은 특히 주의해야 합니다. 보안 문서의 pull_request_target 사용 지침에 따라 코드 출처와 실행 방식을 검토하세요.

• [ ] 트리거 이벤트, 체크아웃하는 코드의 출처, 실제 실행 단계를 기록합니다.
• [ ] 워크플로가 사용하는 토큰 권한을 확인하고, 필요한 권한만 지정합니다. 워크플로 문법의 권한 설정을 참고하세요.
• [ ] 서명 자격 증명과 기타 시크릿에 접근하는 단계가 있는지 확인합니다. PR 코드 실행과 민감한 자격 증명 사용이 같은 신뢰 경계에 놓이지 않도록 점검합니다.

맥 Runner에서 작업이 성공했더라도 정책상 안전하다는 뜻은 아닙니다. 이벤트 정책은 실행 허용 여부를 다룹니다. 호스트 접근, 저장소 권한, 시크릿 보호는 별도 통제 항목입니다.

업무상 해당 이벤트가 필요한지 먼저 확인하세요. 대체 트리거와 권한 축소로 목적을 달성할 수 있다면 예외를 추가하지 않는 편이 낫습니다. 불가피한 예외는 정책과 워크플로 파일 범위를 함께 확인해 지정하세요.

• [ ] 이벤트 변경이 PR 검증이나 업무 흐름에 미치는 영향을 확인합니다.
• [ ] 예외가 필요한 저장소와 워크플로 파일, 이유, 승인자를 변경 기록에 남깁니다.
• [ ] 재검토 조건을 정하고, 관련 없는 워크플로로 허용 범위가 넓어지지 않았는지 확인합니다.

정책을 자동화해 관리한다면 Actions 정책 REST API 문서도 확인하세요. 명시적 허용은 정책상 실행을 허용할 뿐, 코드나 자격 증명이 안전하다는 보증은 아닙니다.

영향받는 저장소는 어떻게 구분하나요?
기본 규칙은 적용 가능한 이벤트 정책이 아직 없는 공개 저장소를 대상으로 합니다. 이미 적용 중인 정책이 있는지 저장소별로 확인하고 Insights 평가 결과를 함께 검토하세요. 비공개·내부 저장소는 해당 기본 규칙의 적용 대상이 아니지만, 기존 조직 정책이나 저장소 정책까지 면제되는 것은 아닙니다.

Insights에서 어떤 맥 CI 실행을 찾아야 하나요?
pull_request_target으로 시작되는 워크플로와 정책 평가 결과를 확인하세요. 결과를 저장소, 파일 경로, 코드 출처, 시크릿 접근 여부와 연결해야 실제 검토 대상이 드러납니다. 평가 모드의 결과는 영향 확인 자료이지 차단 결과가 아닙니다.

비공개 저장소에서도 이 기본 규칙을 따로 적용해야 하나요?
공개 저장소에 예정된 기본 규칙이 비공개·내부 저장소에 자동 적용되는 것은 아닙니다. 다만 기업 정책이 별도로 적용될 수 있으므로 현재 설정은 확인해야 합니다. 포크 코드 실행과 토큰 권한 검토도 저장소 공개 여부와 무관하게 진행하세요.

꼭 필요한 이벤트의 예외는 어떻게 승인하나요?
대체 트리거와 권한 설계를 먼저 검토한 뒤, 필요한 저장소와 워크플로 파일에만 예외를 한정하세요. 사유, 승인자, 영향 범위, 재검토 조건을 남깁니다. 예외를 넓게 설정하거나 승인만으로 보안 검토를 끝내지 마세요.

정책 변경 전에는 허용되어야 하는 실행과 거부되어야 하는 실행을 구분해 통제된 환경에서 확인하세요. GitHub의 자체 호스팅 Runner 보안 지침도 함께 참고해 호스트와 작업 경계를 검토합니다.

• [ ] 평가 기록과 정책 구성을 대조해 의도한 이벤트 허용·거부가 일치하는지 확인합니다.
• [ ] 실제 워크플로 결과와 정책 평가 결과를 각각 기록합니다. 작업 성공만으로 검증을 끝내지 않습니다.
• [ ] 맥 Runner가 접근할 수 있는 저장소, 서명 자격 증명, 빌드 결과물을 확인합니다. 정책 설정을 호스트 격리나 시크릿 격리로 간주하지 않습니다.
• [ ] 정책 적용 뒤 예상되는 실패 유형과 대응 책임자를 정합니다.

실패 시에는 잘못된 트리거, 정책상 거부, 권한 부족, 자격 증명 접근 실패를 구분해 원인을 기록하세요. 원인을 특정하지 않고 예외를 추가하면 정책 범위만 넓어질 수 있습니다.

평가 결과와 업무 의존성을 함께 보고, 차단·제한된 예외 허용·사전 수정 중 하나를 결정하세요. GitHub가 안내한 자동 실행 예정일인 2026년 12월 2일 전에 검토를 마치고, 날짜나 적용 범위가 바뀌면 공식 공지를 다시 확인합니다.

• [ ] 저장소 범위와 이벤트 정책을 기록합니다.
• [ ] Insights 평가 결과와 통제된 실행 검증 자료를 보관합니다.
• [ ] 예외가 있다면 승인, 대상 워크플로, 재검토 조건을 남깁니다.
• [ ] 정책 적용 뒤 실패가 발생했을 때 확인할 담당자와 절차를 정합니다.

현재의 맥 CI를 자체 구매 장비로 운영하면 초기 구매 비용뿐 아니라 유휴 용량과 하드웨어 유지 관리 부담도 감당해야 합니다. 반대로 원격 맥은 네트워크 연결과 접근 권한 검토가 필요하므로, 지속적인 고부하나 물리 장비 연결이 필수인 작업에는 맞지 않을 수 있습니다. 팀의 실행 환경을 별도로 마련해야 한다면 CALMVPS의 요금과 이용 조건을 살펴보고, VNC·SSH·웹 콘솔을 통한 원격 접근 방식이 운영 요구에 맞는지 판단하세요. 작업량이 임시적이거나 팀의 CI 용량을 유연하게 운영하려는 경우에는 CALMVPS 원격 맥 이용 안내에서 실제 조건을 확인한 뒤 비교할 수 있습니다.