깃허브 1,900개 계정 털고 3만 개 저장소 덮친 고스트액션: CI/CD 파이프라인이 탈취 통로로 전락한 내막

깃허브 계정 1,900개 탈취와 3만 개 저장소를 휩쓴 자동화 스파이웨어

소프트웨어를 개발할 때 코드 검사와 배포를 자동으로 처리해 주는 깃허브 액션(GitHub Actions)은 오늘날 모든 개발팀의 핵심 작업대다. 매번 사람이 손으로 빌드 버튼을 누르지 않아도, 코드를 올리기만 하면 미리 정해둔 순서에 따라 테스트가 돌고 서버로 파일이 넘어간다. 그런데 이 편리한 자동화 일꾼이 순식간에 회사의 가장 은밀한 금고 열쇠를 빼돌리는 내부 스파이로 돌변했다.

글로벌 보안 분석 업체 깃가디언(GitGuardian)과 스텝시큐리티(StepSecurity)가 추적한 ‘고스트액션(GhostAction)’ 공격이 전 세계 오픈소스와 기업 개발 현장을 뒤흔들었다. 해커들은 사전에 유출된 개발자 개인 접근 토큰(PAT)을 악용해 약 1,900개의 깃허브 계정을 무단으로 손에 넣었다. 계정 쓰기 권한을 확보한 이들은 10월 8일과 9일 이틀 동안 무려 3만 개가 넘는 코드 저장소에 가짜 검사 코드를 일제히 심었다.

이번 사건에서 주목해야 할 점은 깃허브 시스템 자체의 결함이나 서버 취약점을 뚫고 들어온 공격이 아니라는 사실이다. 해커들은 깃허브라는 거대한 건물 자체를 부수지 않았다. 대신 직원이 길가에 떨어뜨린 사원증을 주워 문을 열고 들어왔다. 사무실 안으로 들어온 뒤에는 ‘정기 보안 감사(security-audit.yml)‘나 ‘보안 점검(github_actions_security.yml)‘이라는 그럴듯한 명찰을 단 가짜 작업 지시서를 꽂아 두었다.

저장소 안에 이미 등록되어 있던 클라우드 접속 키, 인공지능 모델 호출용 토큰은 정상적인 작업인 줄 알고 가짜 작업 지시서에 그대로 읽혀 들어갔다. 자동화 일꾼의 손을 빌려 비밀번호를 합법적으로 꺼내 간 셈이다.

---

3,174개 자격증명 탈취 시도와 84% 미조치 방치: 숫자로 본 침해 피해

고스트액션 공격은 단 한 번의 단발성 공격으로 끝나지 않았다. 해커들은 8월과 9월에 걸쳐 공개 저장소를 상대로 자동화 파이프라인의 허점을 시험했다. 방어선이 어디까지 작동하는지 간을 본 뒤, 10월 초에 대규모로 화력을 집중했다.

초기 8–9월 공격 당시 해커들은 373개 조직의 772개 공개 저장소에 악성 워크플로우를 주입했다. 이때 기록된 3,669회의 실행 시도 중 실제 실행된 것은 499회였으며, 완전히 성공해 26개의 자격증명을 빼돌린 것은 13개 저장소 336회에 불과했다. 깃허브의 외부 기여자 승인 장치가 대부분의 공격을 막아냈기 때문이다.

그러나 해커들은 과거 침투 흔적이 남아 있는 구형 인프라 92개를 재활용하는 방식으로 방어선을 우회했다. 심지어 10월 5일 기준, 1차 침해를 당했던 772개 저장소 가운데 악성 코드를 찾아내 정리한 곳은 단 16%(124개)에 그쳤다. 나머지 84%의 저장소는 침해를 당한 줄도 모른 채 방치되어 있었다.

구분 항목	8–9월 1차 침투 캠페인	10월 8–9일 집중 확산 캠페인	비고 및 파급력
장악된 계정 규모	수백 개 단위 테스트 계정	약 1,900개 개발자 계정	개인 접근 토큰(PAT) 탈취 경로 유력
오염된 코드 저장소	772개 저장소 (373개 조직)	30,000개 이상 저장소	1차 160개 배포 후 20분 만에 28,000개 급증
공격 표적 시크릿 수	26개 시크릿 유출 확인	3,174개 시크릿 직접 추출 시도	AWS, OpenAI, Anthropic 토큰 집중
추출 범위(Git 깊이)	현재 작업 공간(코드 본문)	전체 커밋 히스토리 (fetch-depth: 0)	과거에 삭제했던 옛날 비밀 키까지 전부 복원
저장소 사후 조치율	16% (124개 저장소만 정리)	조사 진행 중 (대다수 방치 추정)	권한 취소 없이 방치 시 2차 침해 불가피

공격자들은 10월 8일과 9일 본색을 드러냈다. 기존 타깃이었던 160여 개 저장소에 시험 코드를 뿌린 뒤, 불과 20분 만에 28,000개의 신규 저장소로 악성 코드를 융단폭격하듯 쏟아부었다.

단순히 소스코드 파일 안의 비밀번호만 긁어모은 것이 아니다. 깃허브 체크아웃 액션의 설정을 fetch-depth: 0으로 강제 변경해, 프로젝트가 처음 시작된 날부터 쌓인 모든 커밋 이력을 바닥까지 긁어냈다. 수개월 전에 실수로 올렸다가 곧바로 지웠던 클라우드 마스터 키, 과거 개발자가 테스트 삼아 썼던 인공지능 API 키까지 전부 되살려 공격자의 IP 주소(193.32.204.199)로 평문 전송했다.

---

코드 저장소 침해가 기업 비즈니스에 가하는 3대 직접 충격

자동화 파이프라인이 뚫린 사고는 단순한 개발 부서의 소란으로 끝나지 않는다. 클라우드 계정과 인공지능 결제 계정으로 직결되는 열쇠가 통째로 넘어갔기 때문이다.

1. 운영 비용(OPEX): 수천만 원대 클라우드 과금 폭탄과 API 무단 도용

탈취된 키 목록에는 아마존웹서비스(AWS)의 핵심 접근 키와 앤트로픽(Anthropic), 오픈AI(OpenAI), 오픈라우터(OpenRouter)의 유료 토큰이 대거 포함되어 있었다. 해커들은 AWS Access Key ID와 Secret Access Key를 한 쌍으로 묶기 위해 코드의 앞뒤 문맥까지 통째로 긁어모았다.

이렇게 빼돌린 클라우드 키는 몇 시간 안에 해외 암호화폐 채굴용 고성능 서버를 수백 대 띄우는 데 악용된다. 인공지능 API 토큰 역시 다크웹이나 불법 대리 호출 작업장에 넘어가 분당 수십만 건의 대규모 호출을 일으킨다. 업계 평균 피해액을 기준으로 추산해 보면, 유출 후 초기 12시간 동안 방치될 경우 발생하는 기습 과금만 기업당 2,500만–6,000만 원 수준에 달한다.

2. 처리 지연(Lead Time): 프로덕션 배포 중단과 전면 감사로 인한 납기 마비

악성 워크플로우가 저장소를 덮치면 소프트웨어 배포 라인이 전면 멈춰 선다. 어떤 파일이 오염되었는지, 정상적인 배포 파일 안에 해커의 백도어가 섞여 들어가지 않았는지 전수 조사를 마칠 때까지 모든 출시 일정이 중단된다.

특히 Datadog 같은 인프라 통합 모니터링 환경에서 비정상적인 외부 통신이나 비정상 트래픽을 감지하고 이상 징후를 추적하더라도, 3만 개에 달하는 저장소의 과거 커밋 기록을 일일이 대조하고 키를 교체하는 작업에는 막대한 시간이 든다. 평균적으로 파이프라인을 완전히 복구하고 정상 업무로 복귀하기까지 최소 7–14일간의 개발 병목과 납기 지연이 발생한다.

3. 공급 안정성: 고객 신뢰 붕괴와 2차 공급망 연쇄 감염

더 큰 문제는 소프트웨어를 고객사나 다른 기업에 납품하는 B2B 기업의 공급망 신뢰가 통째로 무너진다는 점이다. 탈취당한 저장소에서 생성된 컨테이너 이미지나 설치 패키지에 악성 스크립트가 숨어 들어갈 경우, 이를 내려받은 고객사의 내부 인프라까지 연쇄 감염된다.

지난 수년간 이어진 소프트웨어 공급망 공격 사례에서 보듯, 한 번 공급망 보안 검증을 통과하지 못해 파트너십이 끊긴 기업이 신뢰를 회복하는 데는 수년의 시간과 수억 원의 감사 비용이 소모된다.

---

낡은 하드코딩 관행을 깨는 신기술 완충벽과 안전한 대안

개발자들이 프로젝트를 진행할 때 흔히 저지르는 실수는 환경변수나 시크릿 설정 메뉴에 클라우드 장기 접속 키를 그대로 복사해 넣는 일이다. 그러나 영구적으로 쓸 수 있는 비밀번호를 어딘가에 적어두는 순간, 그 비밀번호는 언젠가 유출될 수밖에 없다.

선도적인 테크 기업들은 이미 코드 저장소에 클라우드 비밀번호를 적어두는 방식을 완전히 버렸다. 대신 ‘오픈아이디 커넥트(OIDC)’ 기술을 깃허브 액션에 연결해 사용한다.

OIDC 방식은 깃허브와 클라우드 서비스(AWS, GCP 등)가 서로 약속된 신분증을 주고받는 구조다. 깃허브에서 작업이 시작되면 클라우드 서버에 “이 작업은 공식 검증된 우리 저장소의 작업이 맞다”는 1회용 증명서를 보낸다. 클라우드는 그 증명서를 확인한 뒤 딱 15분 동안만 유효한 임시 출입증을 발급해 준다.

작업이 끝나면 출입증은 그 자리에서 휴지조각이 된다. 해커가 코드를 가로채거나 과거 커밋 기록을 아무리 뒤져도 훔쳐갈 고정 비밀번호 자체가 존재하지 않으므로, 공격은 원천 차단된다.

---

자격증명 유출 위기를 막아서는 실무 3단계 긴급 방어선

고스트액션과 같은 파이프라인 침해 사고는 “우리 회사는 괜찮겠지”라는 안일한 생각이 드는 순간 터진다. 현재 깃허브를 사용해 배포와 빌드를 자동화하고 있는 모든 실무팀은 지금 당장 아래 3가지 방어선을 구축해야 한다.

1차 방어선: 워크플로우 수정 계정 색출 및 개인 접근 토큰(PAT) 전면 폐기

가장 먼저 해야 할 일은 누가 저장소의 자동화 설정 파일(.github/workflows/)을 건드렸는지 감사 로그(Audit Log)를 뒤지는 일이다.

• 최근 30일 동안 워크플로우 파일을 새로 만들거나 수정한 개발자 계정을 전수 조사한다.
• 조금이라도 비정상적인 IP에서 접속했거나 업무와 무관한 시간에 작업을 수행한 계정이 있다면 즉시 쓰기 권한을 회수한다.
• 저장소 안에 악성 파일이 이미 지워졌더라도 안심해서는 안 된다. 계정의 접근 토큰 자체가 살아 있다면 해커는 언제든 다시 들어와 백도어를 심을 수 있다. 발급된 지 오래되었거나 만료 기한이 없는 구형 PAT는 예외 없이 전부 삭제한다.

2차 방어선: 과거 커밋 이력 포함 전사 클라우드 키 롤링(Rotation)

많은 개발팀이 “예전에 올렸던 비밀번호는 커밋에서 이미 지웠으니 안전하다”고 착각한다. 그러나 깃의 특성상 과거 커밋 기록을 지우지 않는 한, 파일 변경 이력 속에 영원히 암호문이 남아 있다.

• 과거에 한 번이라도 저장소에 올라간 적이 있는 AWS 키, 데이터베이스 비밀번호, 오픈AI 등 인공지능 API 토큰은 전부 폐기 처리하고 새로 발급받는다.
• 단순히 코드 최신 버전에서 지우는 데 그치지 않고, git-filter-repo나 BFG Repo-Cleaner 같은 전문 도구를 사용해 깃 히스토리 자체에서 해당 문자열을 완전히 찢어내야 한다.
• 프로젝트 저장소의 포크(Fork)나 복사본이 외부에 퍼져 있다면 해당 키는 이미 인터넷에 공개된 것과 다름없으므로 즉각적인 무효화만이 유일한 해결책이다.

3차 방어선: 자동화 파이프라인의 최소 권한 규칙과 승인 장치 의무화

침투를 당하더라도 내부에서 비밀번호를 마음대로 꺼내 갈 수 없도록 빗장을 걸어야 한다.

• 깃허브 저장소 설정에서 기본 워크플로우 권한을 ‘읽기 전용(Read repository contents permission)‘으로 고정한다.
• 외부 기여자나 권한이 불확실한 계정이 제안한 코드 변경(Pull Request)은 관리자의 명시적 승인이 떨어지기 전까지 자동화 빌드가 절대 실행되지 않도록 강제한다.
• 코드 저장소 시크릿에 보관하는 모든 키를 OIDC 기반 단기 자격증명으로 전환하고, 더 이상 코드베이스 어디에도 영구적인 비밀번호가 남아 있지 않도록 파이프라인 구조를 전면 개편한다.