Hacker News 2026.05.13 109

TanStack npm 공급망 공격 사고 분석 - 토큰 하나가 뚫리면 어디까지 무너지는가

무슨 일이 있었나

React 생태계에서 React Query, React Router, React Table 같은 인기 라이브러리를 만드는 TanStack 팀이 npm 공급망 공격을 당했어요. 공격자가 TanStack 메인테이너의 npm 계정을 탈취해서 여러 패키지에 악성 코드가 들어간 버전을 배포했고, 그게 자동으로 전 세계 개발자들의 빌드 파이프라인으로 흘러들어간 사건입니다. 우리나라에서도 React Query는 거의 표준급으로 쓰이고 있어서 남의 일이 아니거든요.

공급망 공격(supply chain attack)이 뭐냐면, 내가 직접 만든 코드가 아니라 "내가 의존하는 라이브러리"가 오염되는 공격이에요. npm install 한 번에 수백 개 패키지가 따라오는 자바스크립트 생태계에서는 특히 치명적입니다. TanStack 팀은 이번에 사고가 터지자마자 상세한 포스트모템(사후 분석 보고서)을 공개했는데, 어떻게 뚫렸고, 어떻게 막았고, 앞으로 뭘 바꿀지를 솔직하게 적어놨어요.

핵심 내용: 토큰 하나가 만든 도미노

TanStack의 분석에 따르면 공격의 시작은 npm 자동화 토큰의 유출이었어요. CI/CD 파이프라인에서 패키지를 자동 배포하기 위해 발급한 토큰이 어떤 경로로 외부에 노출됐고, 공격자는 그 토큰으로 정상적인 메인테이너인 척 새 버전을 publish 했습니다. 토큰은 2FA(2단계 인증)를 우회할 수 있는 권한을 가지고 있었기 때문에, 사람이 직접 로그인하는 게 아니라 자동화 토큰만으로도 publish가 가능했던 거예요. 이게 첫 번째 구멍입니다.

악성 버전에 심어진 코드는 빌드 타임에 환경 변수와 .env 파일 같은 민감한 정보를 빼돌리는 형태였어요. 특히 무서운 건, 패키지가 의존성으로 들어가 있는 모든 프로젝트의 CI 환경에서 실행되기 때문에, AWS 키나 GitHub 토큰 같은 게 한꺼번에 털릴 수 있다는 점이에요. "내가 직접 코드를 안 봤는데도" 내 빌드 서버가 도둑맞는 셈입니다.

TanStack 팀이 빠르게 대응한 부분은 인상적이에요. 사고를 인지하자마자 npm에 deprecate(사용 중단) 요청을 하고, 영향받은 버전 범위를 명확히 공지하고, 새 토큰을 발급해서 클린 버전을 재배포했어요. 그리고 토큰 권한을 최소화하고, 2FA가 강제되는 "granular access token"으로 전환했습니다. 이건 npm에서 비교적 최근에 도입한 기능인데, 특정 패키지에만 publish 권한을 부여할 수 있고 자동화에서도 OTP를 요구할 수 있어요.

또 하나 중요한 조치는 provenance(출처 증명) 기능 활성화예요. npm provenance는 패키지가 정확히 어느 GitHub Actions 워크플로우에서, 어떤 커밋으로부터 빌드됐는지를 암호학적으로 증명하는 기능이에요. 이게 켜져 있으면 "이 패키지는 진짜 TanStack 공식 레포의 main 브랜치 X 커밋에서 빌드된 것"이라는 영수증이 npm에 박혀요. 사용자는 그 영수증을 확인할 수 있고요.

업계 맥락: 반복되는 공급망 공격의 역사

이번 사건이 처음이 아니거든요. 지난 몇 년 동안 event-stream(2018), ua-parser-js(2021), colors.js/faker.js(2022), 그리고 작년에는 XZ Utils 백도어 사건까지, 오픈소스 공급망은 계속 공격받고 있어요. 패턴도 비슷합니다. 메인테이너 한 명을 노리거나, 메인테이너가 신뢰한 컨트리뷰터를 노리는 방식이죠.

업계 대응도 빠르게 진화하고 있어요. GitHub와 npm은 provenance, sigstore 기반 서명, 의무 2FA 같은 걸 도입했고, Google이 주도하는 SLSA(Supply-chain Levels for Software Artifacts) 같은 표준도 만들어지고 있어요. Socket, Snyk, Phylum 같은 회사들은 npm에 새 버전이 올라오면 실시간으로 악성 패턴을 탐지해주는 서비스를 제공합니다. pnpm은 최근 minimumReleaseAge 옵션을 추가해서 "배포된 지 N일 이내의 버전은 설치하지 않기"를 강제할 수 있게 했는데, 이런 사고에 직접적인 방어가 되거든요.

반대로 PyPI나 RubyGems도 비슷한 문제를 겪고 있어서, 이건 자바스크립트만의 문제가 아니라 모든 패키지 매니저의 숙제입니다.

한국 개발자에게 주는 시사점

실무에서 당장 할 수 있는 게 몇 가지 있어요. 첫째, package-lock.json이나 pnpm-lock.yaml을 반드시 커밋하세요. 이게 있어야 다음 빌드에서 정확히 같은 버전이 설치됩니다. "^4.2.0" 같은 캐럿 버전만 믿고 lockfile 없이 배포하는 건 이번 같은 사고에 정통으로 노출되는 거예요.

둘째, CI에서 사용하는 토큰의 권한을 최소화하세요. npm 토큰이든 GitHub 토큰이든 AWS 키든, "이 작업에 필요한 최소한"만 부여하는 게 원칙이에요. 그리고 정기적으로 로테이션하세요. 1년 묵은 토큰이 어디서 새는지 아무도 모릅니다.

셋째, 의존성 자동 업데이트를 무조건 신뢰하지 마세요. Renovate나 Dependabot이 PR을 올려도, 메이저 라이브러리의 패치 버전이라고 묻지마 머지하는 건 위험합니다. 최소 며칠 텀을 두거나, pnpm의 minimumReleaseAge 같은 안전장치를 쓰는 게 좋아요.

넷째, npm audit signatures나 socket.dev 같은 도구로 의존성을 주기적으로 점검하세요. 회사 보안팀이 따로 없는 스타트업이라면 더더욱 직접 챙겨야 합니다.