공급망 공격의 심각성 부각
2026년 5월 19일, 데이터 시각화 솔루션 기업 Grafana Labs는 npm 공급망 공격을 통해 자사 GitHub 저장소에 무단 접근이 발생하고 코드베이스가 유출되었다고 공식 발표했다. 공격자는 5월 16일 Grafana Labs 측에 유출된 코드베이스의 공개를 막는 대가로 랜섬(몸값)을 요구했다.
고객 생산 시스템이나 운영 환경에 대한 직접적인 피해는 없었으나, 공개·비공개 소스코드와 내부 운영 정보가 포함된 GitHub 저장소가 침해 범위에 포함된 것으로 확인됐다. 이번 공격은 'Mini Shai-Hulud'라는 명칭의 캠페인 일환으로, 5월 11일 TanStack npm 공급망 공격에서 출발했다. 해당 캠페인은 단 6분 만에 42개 @tanstack/* 패키지에서 84개의 악성 패키지 아티팩트를 npm 레지스트리에 등록하는 방식으로 빠르게 전파됐다.
Grafana Labs는 5월 11일 악성 활동을 감지하고 즉시 사고 대응 절차를 가동했으나, GitHub 워크플로우 토큰을 다수 교체하는 과정에서 누락된 토큰 하나가 공격자에게 저장소 접근 권한을 제공하는 통로가 됐다. 이번 'Mini Shai-Hulud' 캠페인의 핵심 수법은 GitHub Actions CI 파이프라인과 같은 CI/CD 환경을 악용하는 웜(worm) 형태의 악성코드였다. 공개 패키지 레지스트리에 악성 아티팩트를 삽입한 뒤, 이를 의존성으로 사용하는 프로젝트의 자동화 빌드 환경을 통해 감염이 연쇄적으로 확산되는 구조다.
5월 14일에는 node-ipc npm 패키지에서도 유사한 공급망 공격이 발생해 동일 캠페인의 광범위한 파급력이 재확인됐다. Grafana Labs 사례는 공급망 공격이 단순히 외부 라이브러리 취약점에 그치지 않고, 기업의 핵심 개발 자산과 내부 운영 정보까지 겨냥할 수 있음을 실증했다. Grafana Labs가 확인한 피해 범위에 따르면, 이번 침해는 GitHub 환경으로 국한됐다.
그러나 유출된 콘텐츠에는 공개 소스코드뿐 아니라 비공개 저장소의 소스코드, 그리고 일부 팀이 내부 운영 정보 및 비즈니스 세부 사항을 공동 작업하고 저장하는 데 활용하던 저장소까지 포함됐다. 이는 코드 유출이 단순한 기술 자산 손실을 넘어 기업의 전략적 정보 노출로 이어질 수 있다는 사실을 보여준다.
Grafana Labs는 고객 생산 시스템과 운영 환경에는 영향이 없었다고 밝혔다.
광고
보안 취약점으로 인한 여파
보안 전문 기관 StepSecurity와 Huntress는 이번 캠페인 분석을 통해 CI/CD 파이프라인 보안의 구조적 취약성을 지적했다. 자동화된 빌드 환경에서 사용하는 외부 패키지의 무결성 검증 절차가 없거나 미흡할 경우, 하나의 악성 패키지가 전체 개발 생태계를 오염시킬 수 있다는 것이다. 특히 토큰 관리 체계의 허점은 이번 사건에서 결정적 역할을 했다.
수십 개의 토큰을 일괄 교체하는 과정에서 단 하나의 누락이 전체 방어선을 무력화했다는 점은, 자동화된 자격증명 관리 시스템의 필요성을 명확히 보여준다. 소프트웨어 공급망 공격이 랜섬 요구로까지 이어진 이번 사건은 보안 투자의 경제적 당위성을 다시 부각시킨다.
공급망 보안 강화에 수반되는 비용이 생산성 저하를 초래할 수 있다는 우려가 일각에서 제기되지만, 코드베이스 유출과 랜섬 협박이 현실화된 사례는 보안 투자 없이는 기업의 장기적 신뢰성 자체가 위협받을 수 있음을 명확히 보여준다. 기업의 핵심 자산인 소스코드와 내부 운영 정보가 협박의 수단으로 전락하는 순간, 사건 대응 비용은 사전 보안 투자 비용을 크게 초과한다.
npm과 같은 공개 레지스트리를 통한 악성 패키지 유포는 개발자 개인의 개발 환경을 넘어 해당 패키지를 의존성으로 사용하는 모든 기업의 보안을 위협한다. GitHub Actions 등 CI/CD 환경의 취약점을 악용하는 공격 방식은 전파 속도가 극히 빠르고 탐지가 어렵다는 점에서 기존의 경계 보안 모델만으로는 대응이 어렵다. 패키지 서명 검증, 의존성 잠금 파일 활용, CI 환경 내 최소 권한 원칙 적용, 그리고 자격증명 자동 순환 시스템 도입이 현실적 대응 방안으로 꼽힌다.
향후 전망과 대응 전략
한국의 개발자와 IT 기업 역시 이번 사건에서 실질적 교훈을 도출해야 한다. 글로벌 오픈소스 생태계를 공유하는 이상, 해외 공급망 공격의 파급은 국내 개발 환경에도 동일하게 미칠 수 있다.
자사가 사용하는 npm·PyPI·Maven 등 패키지 레지스트리의 의존성 현황을 주기적으로 점검하고, CI/CD 파이프라인에 부여된 토큰과 권한을 정기적으로 감사하는 체계를 갖추는 것이 선제적 대응의 출발점이 된다. Grafana Labs는 현재 조사를 계속 진행 중이며, 조사가 완료되는 대로 사후 보고서를 발행할 예정이라고 밝혔다.
광고
또한 시스템 보호를 위한 보안 조치를 전면 강화하고 있다고 전했다. 이번 사건을 계기로 업계 전반에서 공급망 보안 체계에 대한 전면적 검토가 요구되고 있으며, 핵심 자산 보호를 위한 구체적 방어 전략 수립이 시급한 과제로 부상했다.
FAQ
Q. 이번 사건에서 고객 데이터나 서비스 이용에 직접적인 피해가 있었나?
A. Grafana Labs의 공식 발표에 따르면, 이번 침해는 자사의 GitHub 환경으로 국한됐으며 고객 생산 시스템이나 운영 환경에는 직접적인 영향이 없었다. 다만 유출된 범위에 비공개 소스코드와 내부 운영 정보가 포함된 GitHub 저장소가 포함되어 있어, 기업 내부 개발 프로세스와 비즈니스 정보에 대한 노출 위험은 존재한다. Grafana Labs는 조사가 완료되는 대로 상세 내용을 담은 사후 보고서를 발행할 예정이다.
Q. 한국 기업이 유사한 공급망 공격에 대비하기 위해 즉시 실행할 수 있는 조치는 무엇인가?
A. 가장 우선적으로 CI/CD 파이프라인에서 사용되는 외부 패키지의 의존성 목록을 전수 점검하고, 패키지 잠금 파일(package-lock.json, yarn.lock 등)을 통해 검증된 버전만 사용하도록 강제하는 것이 효과적이다. GitHub Actions 등 자동화 빌드 환경에 부여된 토큰과 시크릿은 최소 권한 원칙을 적용하고, 자동화된 주기적 순환(rotation) 체계를 도입해야 한다. 또한 StepSecurity, Snyk 등 공급망 보안 전문 도구를 활용해 빌드 파이프라인 내 이상 활동을 실시간으로 탐지하는 모니터링 체계를 갖추는 것이 권고된다.
Q. npm 공급망 공격이 랜섬 요구로 이어지는 경우 기업은 어떻게 대응해야 하나?
A. 랜섬 요구를 받은 경우 즉시 사이버보안 전문 기관 및 법집행기관에 신고하고, 유출 범위와 경로를 정확히 파악하는 포렌식 조사를 선행하는 것이 원칙이다. 랜섬 지불은 추가 공격을 유발하고 범죄 수익 구조를 강화하는 결과로 이어질 수 있어 일반적으로 권고되지 않는다. Grafana Labs 사례에서 확인되듯, 유출된 정보의 실제 피해 범위를 신속하게 특정하고 이해관계자에게 투명하게 공개하는 것이 기업 신뢰 유지와 후속 피해 최소화를 위한 핵심 대응 전략이 된다.
){kind=small}
){kind=small}
){kind=small}
){kind=small}
