깃허브 내부 저장소 3800개 유출...'방패의 설계도'가 새어나갔다...스팸·코파일럿 감시·수사기관 협력 도구까지 노출, 공지는 X에만 올려 논란

[한국정보기술신문] 전 세계 개발자 1억 명 이상이 쓰는 코드 호스팅 플랫폼 깃허브(GitHub)가 내부 저장소에 대한 무단 접근 사고를 겪었다. 깃허브는 2026년 5월 19일 이를 조사 중이라고 처음 알렸고, 이후 약 3800개 저장소가 유출됐다는 공격자의 주장이 자체 조사와 "방향적으로 일치한다"고 인정했다. 이번 사고는 단순한 데이터 유출을 넘어, 플랫폼이 스스로를 지키는 방법까지 외부에 드러났다는 점에서 파장이 크다.

이번 공격은 깃허브의 서버나 깃허브닷컴을 직접 노린 것이 아니다. 공격자는 한 직원이 쓰던 코드 편집기 비주얼 스튜디오 코드(VS Code)의 확장 프로그램을 표적으로 삼았다.

직원이 악성 확장을 설치하자, 프로그램은 작업 공간을 여는 순간 조용히 실행됐다. 그리고 직원이 내부 환경에 접속할 때 쓰던 자격 증명을 빼냈다. 공격자는 이 정보로 내부 저장소에 들어가 약 3800개를 통째로 내려받았다.

전문가들이 우려하는 지점이 바로 이것이다. 깃허브닷컴이나 깃(Git) 자체의 결함이 아니라, 공식 마켓플레이스에서 받은 확장 하나가 개발자 한 명의 컴퓨터에서 실행돼 벌어진 일이기 때문이다.

이번 사고가 특히 무거운 이유는 새어나간 것이 고객 코드가 아니라 깃허브가 플랫폼을 운영하고 보호하는 방식 그 자체이기 때문이다. 공개된 것으로 보이는 파일 목록을 보면 민감한 영역이 고스란히 드러난다.

스팸 조사 관련 파일(spam-investigations, spamops)은 깃허브가 스팸을 어떻게 탐지하고 대응하는지 담고 있을 가능성이 크다. 탐지 논리가 알려지면 스팸 발송자가 이를 우회할 수 있다. 코파일럿(Copilot) 악용 감시 도구로 추정되는 파일은 인공지능 코딩 도구가 어떤 기준으로 악용을 차단하는지 노출할 수 있다.

법 집행기관 협력 채널 관련 코드도 포함됐다. 수사기관이 깃허브에 데이터를 요청할 때 쓰는 포털의 구조가 드러나는 셈이다. 또 저장소에 실수로 올라간 비밀번호나 API 키를 자동으로 찾아내는 시크릿 스캐닝(secret scanning) 기능 관련 파일도 있었다. 탐지 규칙이 공개되면 우회가 쉬워질 수 있다.

정리하면 방패의 설계도가 공격자 손에 들어간 상황이다. 깃허브는 고객 정보가 침해됐다는 증거는 없다고 밝혔지만, 후속 활동을 계속 감시 중이라고 덧붙였다.

깃허브는 사고를 일으킨 확장의 이름을 공식적으로 밝히지 않았다. 다만 시점과 정황을 근거로 보안업계는 'Nx 콘솔(Nx Console)'을 유력한 후보로 지목한다.

Nx 콘솔은 누적 설치 수가 220만 건이 넘는 도구다. 권고문에 따르면 악성 버전 18.95.0이 지난 18일 마켓플레이스에 올라와 약 11분간 공개됐다. 짧은 시간이었지만 자동 업데이트를 켜둔 컴퓨터들은 그사이 감염됐다. Nx 측 분석으로는 수천 명의 개발자가 영향을 받은 것으로 추정된다.

악성 코드는 토큰과 SSH 키, AWS·npm·1패스워드·쿠버네티스 등의 자격 증명을 노렸다. Nx는 즉시 최신 버전인 18.100.0으로 갱신하고, 감염이 의심되면 디스크의 비밀키 등을 모두 교체하라고 당부했다.

공격의 배후로는 '팀PCP(TeamPCP)'가 지목됐다. 구글 위협분석그룹은 이 조직을 'UNC6780'으로 추적하고 있다. 이들은 빼낸 데이터를 5만 달러 이상에 팔겠다고 내건 것으로 알려졌다.

깃허브는 대응을 빠르게 진행했다고 설명했다. 악성 확장 버전을 제거하고 감염된 단말기를 격리한 뒤, 중요 인증정보를 야간에 걸쳐 교체했다. 영향이 가장 큰 자격 증명부터 우선 처리했고, 조사가 끝나면 전체 보고서를 공개하겠다고 밝혔다. Nx 최고경영자(CEO)도 자사 확장이 침투 경로였음을 인정하며 책임을 진다고 밝혔고, 배포 시 관리자 두 명의 승인을 받도록 절차를 강화했다.

기술적 침해만큼 논란이 된 것은 깃허브의 공지 방식이다. 깃허브는 이 사고를 자사 상태 페이지나 공식 블로그가 아닌 엑스(X·옛 트위터)에서만 발표했다.

이를 두고 보안 커뮤니티에서는 비판이 나왔다. 외부 플랫폼에만 공지를 올리면 기업 네트워크나 특정 국가처럼 X에 접근할 수 없는 환경에서는 내용을 볼 수 없다는 것이다. 실제로 자바스크립트가 꺼진 환경에서는 원문 확인이 어려웠다. 보안 사고 공지는 접근성과 영속성이 보장되는 자사 인프라에 올리는 것이 기본이라는 지적이다. 제3자 플랫폼은 장애나 정책 변경으로 공지가 사라질 위험도 있다.

이번 사고가 곧바로 고객 코드 유출로 이어진 것은 아니지만, 공급망 보안에 대한 경각심을 높이는 계기가 됐다. 실무 대응 방안 몇 가지를 정리한다.

먼저 깃허브 액션(GitHub Actions) 설정 점검이다. 지저(zizmor) 같은 정적 분석 도구로 자동화 설정 파일의 취약점을 찾을 수 있다. 다음으로 패키지 설치 대기 기간 설정이다. npm·pnpm 등에서 새로 올라온 패키지를 곧장 설치하지 않고 며칠 기다리도록 설정하면, 게시 직후 빠르게 퍼지는 공급망 공격을 막는 데 효과적이다. 또 소켓(Socket) 같은 패키지 방화벽을 CI 파이프라인에 더하면 알려진 악성 패키지를 차단할 수 있다. 마지막으로 VS코드 확장은 신뢰할 수 있는 게시자의 것만 남기고 불필요한 것은 지우는 것이 좋다. 확장은 편집기 안에서 사실상 무제한 권한으로 실행되기 때문이다.

비슷한 시기 그라파나(Grafana) 랩스도 인기 npm 패키지의 공급망이 침해돼 랜섬웨어가 퍼지는 사고를 공개했다. 두 사건이 직접 연결됐는지는 확인되지 않았지만, 공격 대상이 개별 서비스에서 개발 인프라 자체로 옮겨가고 있다는 공통점이 있다. 하나의 패키지나 플랫폼을 뚫으면 그 위에 쌓인 수만 개 프로젝트에 영향을 줄 수 있어, 공격의 지렛대 효과가 극대화되기 때문이다.

이번 사고의 본질은 깃허브가 뚫렸다는 사실보다, 소프트웨어 산업이 소수의 핵심 인프라에 지나치게 집중돼 있다는 구조적 취약성에 있다. 깃허브에 코드를 올리고, 깃허브 액션으로 빌드하고, npm으로 패키지를 가져오는 흐름은 사실상 업계 표준이 됐다. 그 표준의 한 지점이 뚫리면 파급 범위는 기하급수적으로 커진다. 결국 중요한 것은 특정 플랫폼을 믿느냐가 아니라, 어떤 단일 플랫폼도 신뢰의 단일 장애점이 되지 않도록 스스로 보안 계층을 갖추고 있느냐다.