npm 공급망을 파고드는 웜 'Shai-Hulud', 이번엔 Keyv 생태계를 감염시켰어요

혹시 프로젝트에서 npm install을 최근에 돌리셨나요? 그렇다면 오늘 이야기는 남의 일이 아닐 수 있어요. npm 생태계에서 자가복제 웜 'Shai-Hulud'의 새로운 공격이 진행 중인데, 이번에는 Keyv와 그 주변 패키지들이 감염됐다는 소식이에요. Keyv가 뭐냐면, Redis, MongoDB, SQLite 같은 다양한 저장소를 하나의 통일된 키-값 인터페이스로 쓰게 해주는 라이브러리인데요, 문제는 이걸 직접 설치한 적 없는 사람도 갖고 있을 확률이 높다는 거예요. 유명 HTTP 클라이언트 got이 캐싱을 위해 내부적으로 keyv를 쓰는 것처럼, 수많은 인기 패키지의 '의존성의 의존성'으로 깔려 있거든요.

Shai-Hulud, 이게 뭐냐면

이름은 소설 <듄>에 나오는 거대 모래벌레에서 따왔어요. 이름처럼 스스로 증식하는 '웜(worm)' 방식의 악성코드인데, 동작 원리가 꽤 교묘해요.

먼저 감염된 패키지를 누군가 설치하면, 설치 직후 자동으로 실행되는 스크립트(postinstall)가 악성코드를 실행해요. 이 코드는 TruffleHog라는 오픈소스 비밀키 탐지 도구를 이용해 그 컴퓨터와 CI 환경을 싹 뒤져요. npm 배포 토큰, GitHub 토큰, AWS·GCP 같은 클라우드 자격증명이 표적이에요. 아이러니하게도 TruffleHog는 원래 보안 담당자들이 유출된 비밀키를 찾으려고 만든 도구인데, 공격자가 거꾸로 쓰고 있는 거죠.

여기서 진짜 무서운 부분이 나와요. 훔친 npm 토큰의 주인이 패키지 관리자(maintainer)라면, 웜은 그 사람이 관리하는 다른 패키지들에 자기 자신을 심어서 새 버전으로 배포해 버려요. 그럼 그 패키지를 설치한 또 다른 개발자가 감염되고, 그 사람의 패키지가 또 감염되고... 이렇게 사람 손을 거치지 않고 기하급수적으로 퍼지는 거예요. 훔친 자격증명은 공개 GitHub 저장소에 올려서 유출시키고, 피해자의 저장소에 GitHub Actions 워크플로를 심어 지속적으로 비밀을 빼돌리기도 해요.

처음이 아니에요

Shai-Hulud는 2025년 9월에 처음 등장해 @ctrl/tinycolor를 비롯한 수백 개 패키지를 감염시켰고, 같은 해 11월에는 2차 대유행으로 Zapier, PostHog, Postman, AsyncAPI 같은 유명 프로젝트 관련 패키지까지 뚫으면서 수만 개의 GitHub 저장소에 훔친 비밀이 뿌려졌어요. 이후 npm이 오래된 방식의 토큰을 정리하고 신뢰 기반 배포(Trusted Publishing)를 밀어붙이는 등 대응에 나섰지만, 이번 Keyv 감염으로 웜이 여전히 살아서 돌고 있다는 게 확인된 셈이에요. event-stream 사태나 ua-parser-js 하이재킹 때부터 반복돼 온, '메인테이너 계정 하나가 뚫리면 생태계 전체가 위험해지는' npm의 구조적 약점이 계속 찔리고 있는 거죠.

지금 당장 확인할 것들

한국 개발자 대부분이 npm을 쓰니까, 이건 실무 이슈예요. 먼저 npm ls keyv로 내 프로젝트에 keyv가 간접적으로라도 들어와 있는지, 잠금파일(package-lock.json)에 기록된 버전이 감염 버전인지 확인해 보세요. 최근에 의존성을 업데이트했거나 CI가 돌았다면, npm·GitHub 토큰과 클라우드 자격증명을 재발급하는 게 안전해요. 예방 차원에서는 설치 스크립트 자동 실행을 끄는 npm install --ignore-scripts 옵션, 그리고 pnpm의 minimumReleaseAge처럼 '배포된 지 며칠 지난 버전만 설치'하는 쿨다운 설정이 효과적이에요. 이런 웜은 배포 직후 며칠 안에 탐지되고 내려가는 경우가 많아서, 이 설정 하나로 위험이 크게 줄거든요. 배포 권한이 있는 분이라면 2단계 인증을 피싱에 강한 패스키 방식으로 바꾸는 것도 중요하고요.

정리하면, 오픈소스 공급망 공격은 이제 일회성 사건이 아니라 스스로 번식하는 생태계 차원의 위협이 됐다는 거예요. 여러분 팀은 의존성 보안을 어떻게 관리하고 계세요? 잠금파일 검사나 쿨다운 설정, 실제로 도입해 보신 분들의 경험이 궁금하네요.