GitHub Actions 자체 호스팅 Mac Runner 비밀 키 유출, 어떻게 해야 할까? 2026 점검 가이드

로그에 비밀 값이 보이거나 낯선 작업이 맥 러너에서 실행됩니다.
가장 빠른 대응은 의심 작업을 멈추고 호스트를 격리한 뒤, 노출 가능성이 있는 자격 증명을 교체하고 권한을 검토하는 것입니다. 환경을 정리하고 신뢰할 수 있는 코드로 확인하기 전에는 작업을 다시 받지 마세요.

자체 호스팅 맥 러너로 공개 또는 비공개 저장소를 빌드하는 독립 개발자에게 필요한 대응 절차입니다.
고객 저장소를 다루는 프리랜서라면 고객과 러너 관리자의 책임 경계를 확인하는 데 활용하세요.
소규모 원격 팀이라면 이상 작업이나 의심스러운 풀 리퀘스트가 발견됐을 때 공통 대응 기준으로 삼을 수 있습니다.

알림과 실제 노출의 구분

작업 경고 한 건만으로 비밀 값이 유출됐다고 단정하지 마세요. 로그에 값이 출력됐는지, 신뢰하지 않는 코드가 실행됐는지, 러너 환경에서 평소와 다른 동작이 있었는지를 각각 확인해야 합니다. 조사가 끝나기 전에는 이를 확인된 노출, 노출 의심, 일반 경고로 나누어 기록하세요.

GitHub 작업 로그에서 실행된 작업과 각 단계의 출력을 확인할 수 있습니다. 로그를 내려받거나 보존할 때는 접근 권한을 제한하고, 조사 자료에 비밀 값이 그대로 복사되지 않도록 주의하세요. 로그 확인 방법은 GitHub 공식 작업 로그 안내를 참고하세요.

확인 과정에서는 다음 항목을 서로 연결해 살펴보세요.

• 작업을 시작한 이벤트와 작업 흐름 파일의 변경 내역
• 실행된 코드의 출처와 체크아웃한 브랜치 또는 커밋
• 작업에 허용된 토큰 권한과 참조한 비밀 값
• 이상 동작이 시작된 시점과 그 전후의 러너 작업 기록

로그에서 비밀 값이 보이지 않는다고 안전하다는 뜻은 아닙니다. GitHub는 비밀 값의 자동 마스킹을 제공하지만, 마스킹만으로 모든 노출 경로를 막을 수 있다고 보장하지 않습니다. 비밀 값 관리와 마스킹의 한계는 GitHub Secrets 보안 문서에서 확인할 수 있습니다.

풀 리퀘스트 코드의 접근 범위

자체 호스팅 러너는 작업이 실제로 실행되는 호스트입니다. 작업 흐름이 외부에서 온 코드를 받아 실행한다면, 그 코드가 러너에서 접근할 수 있는 파일과 자격 증명에 영향을 줄 가능성을 고려해야 합니다. GitHub도 자체 호스팅 러너가 매번 깨끗하고 격리된 임시 환경에서 실행된다고 보장하지 않으며, 신뢰하지 않는 코드가 러너 환경과 접근 가능한 자격 증명을 위험에 빠뜨릴 수 있다고 설명합니다. GitHub의 안전한 사용 지침을 확인하세요.

특히 풀 리퀘스트가 포크에서 왔는지, 검토나 승인 전에 작업이 실행될 수 있는지 살펴보세요. 높은 권한의 이벤트로 작업을 실행하면서 신뢰하지 않는 코드를 체크아웃해 실행하는 구조도 점검 대상입니다. pull_request_target 이벤트의 권한과 코드 실행 위험은 GitHub의 pull_request_target 보안 설명에 정리되어 있습니다.

이벤트 이름만 확인하고 끝내지 마세요. 작업 흐름 파일에서 코드 체크아웃 위치와 실행 단계, 권한 설정을 함께 추적해야 합니다. 작업 토큰의 권한은 워크플로 문법과 권한 설정 문서를 기준으로 검토하고, GITHUB_TOKEN이 실제로 어떤 저장소 작업을 허용했는지도 GitHub 토큰 안내에서 확인하세요.

대응 단계와 재개 조건

아래 비교표로 현재 상황에 맞는 첫 조치와 재개 기준을 정하세요. 경고만 발견됐더라도 조사가 끝날 때까지 러너가 위험에 노출됐다고 판단해야 하는 경우가 있습니다.

즉시: 작업 흐름 중지와 증거 보존

의심스러운 작업 흐름의 추가 실행을 멈추고, 해당 러너가 새 작업을 받지 않도록 조치하세요. 작업을 취소하거나 실행을 제한할 때는 팀의 사고 대응 절차와 저장소 권한을 따르세요. 관련 작업 로그와 이벤트 정보를 보존하되, 조사 과정에서 로그를 더 넓은 범위에 공유하지 마세요.

조사: 노출된 값과 접근 범위 확인

노출이 의심되는 항목을 저장소 비밀 값, 환경 비밀 값, GITHUB_TOKEN, 외부 서비스의 키나 토큰으로 나누어 확인하세요. 어떤 작업 흐름이 값을 참조했는지, 그 작업이 어떤 코드와 권한으로 실행됐는지 추적해야 합니다. 작업 토큰에 필요 이상의 권한이 부여되어 있었다면 함께 기록하고 줄이세요.

격리: 러너 호스트 상태 확인

러너를 다른 작업에서 분리한 뒤, 실행된 코드와 호스트에서 관찰된 변화를 책임자와 함께 조사하세요. 의심되는 환경에서 새 작업을 실행해 상태를 확인하려고 하면 추가 위험을 만들 수 있습니다. 등록 취소는 러너를 작업 대상으로 관리하는 조치이지, 호스트의 파일이나 지속성 위험을 제거했다는 증거가 아닙니다. 등록된 러너를 제거하는 절차는 GitHub의 자체 호스팅 러너 제거 안내를 참고하되, 호스트 정리는 조직의 대응 절차에 따라 별도로 진행하세요.

교체: 영향받은 자격 증명과 권한 수정

노출 가능성이 있는 자격 증명은 해당 값이 발급된 서비스에서 취소하거나 교체하세요. 저장소에 값을 다시 입력하는 것만으로 이전 키가 무효화되는 것은 아닙니다. 환경 비밀 값, 관련 토큰, 의심스러운 앱이나 계정 권한도 노출 범위에 따라 확인하고, 사용하지 않는 접근 권한은 제거하세요.

동시에 작업 흐름의 트리거와 승인 조건, 보호된 환경 사용 여부, 외부 액션의 출처를 검토하세요. GITHUB_TOKEN은 작업에 허용된 권한 범위 안에서 작동하므로, 작업 흐름 권한 설정이 필요한 수준으로 제한됐는지 확인해야 합니다. 자격 증명 교체만으로 러너 호스트에 남았을 수 있는 변경 사항까지 해결됐다고 보지 마세요.

복구: 신뢰할 수 있는 코드로 재검증

책임자가 러너 환경을 조사하고 필요한 정리나 재구축을 마쳤는지 확인하세요. 다시 등록할지 여부는 조직의 절차와 호스트 상태에 따라 결정해야 합니다. 신뢰할 수 있는 코드만 사용하는 통제된 작업 흐름으로 러너 상태, 작업 권한, 새 자격 증명의 사용 범위, 빌드 결과를 점검하세요.

복구를 승인하기 전에는 다음 조건을 기록으로 남기세요.

• 문제의 작업 흐름이 추가 실행을 받지 않도록 통제됐습니다.
• 노출 가능성이 있는 이전 자격 증명이 발급처에서 취소됐거나 교체됐습니다.
• 러너 환경을 점검하고 필요한 정리 또는 재구축을 마쳤습니다.
• 제한된 권한으로 신뢰할 수 있는 코드의 작업을 완료했습니다.

자주 묻는 질문

자체 호스팅 러너에서 비밀 키가 노출된 것 같으면 무엇부터 해야 하나요?

먼저 의심스러운 작업 흐름이 새 작업을 받지 않도록 멈추고, 영향을 받은 러너 호스트를 다른 작업과 분리하세요. 이어서 로그와 작업 이벤트를 보존해 어떤 코드가 실행됐는지 확인하고, 노출 가능성이 있는 저장소 비밀 값과 토큰을 취소하거나 교체해야 합니다. 증거를 확인하기 전에는 단순 경고와 확인된 노출을 같은 사건으로 취급하지 마세요.

풀 리퀘스트 코드에 비밀 값이 전달됐는지 어떻게 확인하나요?

작업 흐름이 어떤 이벤트로 실행됐는지, 풀 리퀘스트가 포크에서 왔는지, 검토 승인 없이 실행됐는지 살펴보세요. 로그에서는 체크아웃한 코드의 출처와 실행 단계, 토큰 권한, 비밀 값 참조를 함께 확인해야 합니다. 특히 높은 권한으로 실행되는 이벤트에서 신뢰할 수 없는 코드를 가져와 실행했는지 점검하고, 로그에 값이 보이지 않는다는 이유만으로 노출이 없었다고 판단하지 마세요.

신뢰할 수 없는 코드가 맥 러너에서 실행됐다면 러너를 다시 등록해야 하나요?

등록을 취소하거나 다시 등록하는 일만으로 호스트가 깨끗해졌다고 볼 수는 없습니다. 작업을 멈춘 뒤 조직의 사고 대응 절차에 따라 호스트를 격리하고, 실행된 코드와 러너가 접근할 수 있었던 파일 및 자격 증명을 조사하세요. 환경을 정리하거나 새로 구축한 사실을 확인한 뒤 책임자가 승인해야 다시 작업을 받게 하세요. 의심스러운 상태에서 바로 재등록하지 마세요.

GitHub Actions 비밀 값을 교체한 뒤 이전 자격 증명이 무효가 됐는지 어떻게 확인하나요?

저장소 비밀 값만 바꾸지 말고 해당 값이 발급된 서비스나 계정에서도 기존 토큰과 키를 취소했는지 확인하세요. 관련 로그와 권한 설정을 검토해 같은 자격 증명이 다른 저장소나 환경에 복사돼 있는지도 살펴봐야 합니다. 통제된 작업 흐름으로 새 값이 필요한 범위에서만 작동하는지 확인하고, 이전 값은 실제 발급처에서 거부되는지 안전한 방식으로 검증하세요.

운영 방식을 바꾸기 전 확인할 점

자체 호스팅 러너를 계속 운영하면 호스트 격리와 환경 정리, 자격 증명 회전, 재개 승인까지 직접 맡아야 합니다. 이를 감당하기 어렵다면 관리 책임이 어떻게 나뉘는지 먼저 확인한 뒤 원격 맥 환경을 검토할 수 있습니다. 다만 원격 호스트를 쓰더라도 저장소 권한과 비밀 값 관리, 사고 대응 책임이 자동으로 해결되지는 않습니다.

macminirent의 원격 맥 작업 환경 안내와 데이터 보호 관련 정보를 확인하고, 실제 호스트 접근 권한과 격리 책임, 자격 증명 관리 방식을 검토하세요. 임시 빌드 환경이 필요하다면 그 조건을 확인한 뒤 macminirent의 원격 맥 옵션을 비교할 수 있습니다. 장기간의 고정된 부하나 직접 연결해야 하는 장비가 있다면, 먼저 자체 장비 운영이 더 적합한지 따져보세요.

자주 묻는 질문