npm 공급망 공격 axios 사태 대응 방법과 방어 전략
2026년 4월 첫째 주, 전 세계 개발자들이 패닉 상태에 빠졌어요. 주간 다운로드 수 5,000만 건을 넘는 npm 패키지 axios가 공급망 공격의 표적이 됐거든요. 단순한 취약점 발견이 아니라, 악성 코드가 실제로 패키지에 심어져 배포된 사건이에요. 지금 이 글을 읽는 분 프로젝트도 영향을 받았을 수 있어요.
이 글에서 다룰 내용은 이렇게요:
- axios 사태가 정확히 어떻게 발생했는지
- npm 공급망 공격의 실제 피해 범위
- 지금 바로 확인해야 할 체크리스트
- 재발 방지를 위한 실질적인 방어 전략
핵심 요약
- 2026년 4월, axios npm 패키지에 악성 코드가 삽입돼 배포된 공급망 공격이 확인됐고, 마이크로소프트 시큐리티 블로그가 공식 분석 리포트를 공개했어요.
- axios는 주간 5,000만 건 이상 다운로드되는 패키지로, 이번 공격의 잠재적 영향 범위는 수백만 개 프로젝트에 달해요.
- 공격자는 axios 메인테이너 계정을 탈취해 악성 버전을 공식 npm 레지스트리에 직접 올렸어요. 서드파티 미러가 아닌 공식 채널을 통해 배포됐다는 게 핵심이에요.
- 피해 프로젝트는 npm audit만으로는 탐지되지 않을 수 있어
package-lock.json해시 검증과 런타임 행동 분석이 필요해요.- 이번 사태는 단순 취약점 패치가 아니라 빌드 파이프라인 전체를 점검하는 계기로 삼아야 해요.
axios 사태, 도대체 무슨 일이 있었던 걸까요?
공격의 시작: 메인테이너 계정 탈취
2026년 3월 말, axios의 핵심 메인테이너 계정 하나가 탈취됐어요. 마이크로소프트 시큐리티 블로그에 따르면, 공격자는 피싱으로 npm 계정 자격증명을 얻은 뒤 악성 코드가 포함된 버전을 공식 레지스트리에 직접 퍼블리시했어요. 깃허브 소스코드 저장소는 건드리지 않았기 때문에 개발자들이 눈치채기 훨씬 어려웠죠.
삽입된 악성 코드의 역할은 크게 두 가지였어요:
- 환경 변수 탈취:
process.env전체를 외부 서버로 전송 - 네트워크 요청 인터셉트: axios가 처리하는 HTTP 요청/응답 데이터를 공격자 서버로 미러링
환경 변수에는 API 키, 데이터베이스 비밀번호, 클라우드 자격증명이 담겨 있는 경우가 많아요. 서버사이드에서 axios를 쓰는 Node.js 앱이라면 특히 치명적인 이유가 바로 여기 있어요.
발견이 늦어진 이유
공격 버전이 배포된 시점부터 탐지까지 약 18~24시간이 걸렸어요. 짧아 보이지만, CI/CD 파이프라인 특성상 그 사이에 수십만 건의 설치가 일어났을 가능성이 높아요. npm audit은 알려진 CVE 데이터베이스 기반으로 작동하는데, 공식 계정에서 올라온 악성 버전은 취약점으로 등록되기 전까지 탐지 자체가 안 돼요.
npm 공급망 공격의 구조: 이번이 처음이 아니에요
비슷한 선례들
npm 공급망 공격은 axios가 처음이 아니에요. 과거 사례를 보면 패턴이 보여요:
- 2021년 ua-parser-js 사태: 세 개 버전에 크립토마이너 + 비밀번호 스틸러 삽입
- 2022년 node-ipc 사태: 우크라이나 IP를 가진 사용자 시스템의 파일을 삭제하는 코드 삽입
- 2024년 xz utils 사태: Linux 패키지에 백도어 삽입 (npm은 아니지만 공급망 공격의 정점)
공통점은 하나예요. 신뢰받는 패키지의 배포 경로를 그대로 쓴다는 것. 사용자는 평소처럼 npm install을 했을 뿐인데 악성 코드가 들어오는 구조예요.
axios가 표적이 된 이유
단순해요. 크기가 클수록 파급력이 커요. axios는 React, Vue, Next.js, Express 기반 거의 모든 프로젝트에서 쓰이는 사실상의 표준 HTTP 클라이언트예요. 공격자 입장에서 ROI가 극도로 높은 타깃이죠.
지금 당장 해야 할 대응 방법
1단계: 영향 여부 확인
# 현재 설치된 axios 버전 확인
npm list axios
# package-lock.json의 integrity 해시 확인
cat package-lock.json | grep -A 5 '"axios"'
마이크로소프트 시큐리티 블로그가 공개한 악성 버전 목록과 대조해야 해요. 해시값이 다르다면 즉시 설치를 중단하고 격리해야 해요.
2단계: 안전한 버전으로 고정
npm install axios@[안전한_버전] --save-exact
--save-exact 플래그를 꼭 붙이세요. ^1.x.x 같은 범위 지정은 자동 업데이트를 허용해서 비슷한 공격에 또 당할 수 있어요.
3단계: 환경 변수 즉시 교체
axios를 서버사이드에서 쓰고 있었다면 환경 변수 전체가 유출됐다고 가정하고 움직여야 해요:
- AWS/GCP/Azure 자격증명 전체 로테이션
- 데이터베이스 비밀번호 변경
- 서드파티 API 키 재발급
- JWT 시크릿 교체 및 세션 무효화
npm 공급망 공격 방어 전략 비교
실제로 팀에서 도입할 수 있는 방어 수단을 비교해 봤어요.
| 방어 수단 | 탐지 범위 | 설치 난이도 | 자동화 가능 | 비용 |
|---|---|---|---|---|
npm audit | CVE 등록 취약점만 | 즉시 사용 가능 | CI 통합 쉬움 | 무료 |
npm ci + 해시 고정 | 변조된 설치 방지 | 낮음 | CI 기본 설정 | 무료 |
| Socket.dev | 행동 분석 기반 탐지 | 낮음 | GitHub 앱 | 유료 (팀 플랜) |
| Snyk | CVE + 라이선스 분석 | 보통 | CI/CD 통합 | 프리미엄 유료 |
| Sigstore/npm provenance | 빌드 출처 검증 | 높음 | 복잡한 설정 | 무료 |
| Private 레지스트리 (Verdaccio) | 내부 패키지 통제 | 높음 | 수동 승인 필요 | 인프라 비용 |
npm audit만 믿는 건 이번 사태에서 증명됐듯 불충분해요. Socket.dev는 패키지가 설치 시 네트워크 연결을 시도하거나 환경 변수를 읽는 비정상 행동을 사전에 탐지하는데, 이번 axios 사태 같은 케이스를 잡는 데 훨씬 적합한 구조예요.
앞으로 어떻게 달라져야 할까요?
파이프라인 레벨의 변화가 필요해요
이번 사태 대응을 한 줄로 요약하면 이래요: 배포 경로를 믿지 마세요. npm install이 안전하다는 가정 자체를 버려야 해요.
팀에서 지금 바로 도입해야 할 것들이에요:
package-lock.json커밋 필수화: 팀원 전원이 동일한 버전/해시로 설치하게 강제- CI에서
npm ci사용: lock 파일과 다르면 설치를 거부해요 - npm provenance 확인:
npm view axios dist.integrity로 빌드 출처 검증 - 의존성 업데이트를 PR로 강제: Renovate Bot이나 Dependabot을 쓰되, 자동 머지는 비활성화
6~12개월 후를 내다보면
npm 생태계 전반에서 메인테이너 계정 보안이 강화될 거예요. GitHub은 이미 인기 패키지 메인테이너에게 하드웨어 보안키(FIDO2) 2FA를 의무화하는 방향으로 가고 있고, npm 레지스트리 자체도 패키지 퍼블리시 시 추가 검증 단계를 도입할 가능성이 높아요.
지금 당장 해야 할 한 가지를 꼽으라면 이거예요. 팀의 CI/CD 파이프라인에서 npm install을 npm ci로 교체하고, package-lock.json을 반드시 Git에 커밋하는 규칙을 오늘 만드세요.
결국 신뢰 경계를 어디까지 설정하느냐의 문제예요. 공식 레지스트리라도 100% 신뢰할 수 없다는 걸 이번 사태가 명확하게 보여줬으니까요.
팀의 파이프라인은 지금 어떤 상태인가요? package-lock.json 커밋 규칙이 있는지, CI에서 해시 검증을 하는지 오늘 한 번 점검해 보세요. 생각보다 허술한 부분이 눈에 띌 거예요.
참고자료
- Mitigating the Axios npm supply chain compromise | Microsoft Security Blog
- Axios 공급망 공격 :: 꼰머의 보안공부
- Axios NPM 패키지 공급망 공격 발생
