Blog

API 개발자를 위한 NPM 의존성 보안 완벽 가이드: 공급망 보안 강화

Ashley Innocent

Ashley Innocent

1 April 2026

API 개발자를 위한 NPM 의존성 보안 완벽 가이드: 공급망 보안 강화

요약

2024년에만 NPM 공급망 공격으로 3,000개 이상의 악성 패키지가 급증했으며, 2026년 3월 Axios 침해는 상위 10개 패키지조차 안전하지 않다는 것을 증명했습니다. 이 가이드는 API 개발자에게 필요한 모든 방어 계층을 다룹니다: 록파일 적용, postinstall 스크립트 차단, 출처 확인, 행동 분석 도구, 그리고 공격 표면을 줄이는 아키텍처 선택.

서론

2026년 3월 31일의 Axios 공급망 공격은 첫 번째 npm 침해 사고가 아니었으며, 마지막도 아닐 것입니다. 그러나 주간 8,300만 건의 다운로드와 단일 탈취된 관리자 계정을 통해 배포된 크로스 플랫폼 RAT는 JavaScript 생태계가 받은 가장 큰 경종이었습니다.

이것이 일반적인 "종속성을 업데이트하세요"라는 조언과 다른 점은 다음과 같습니다: Axios 공격은 모든 전통적인 방어를 우회했습니다. 악성 코드는 Axios 자체에 있지 않았습니다. postinstall 훅을 트리거하는 유령 종속성을 통해 주입되었습니다. 공격 기간 동안 npm install을 실행했다면 록파일은 도움이 되지 않았습니다. 아직 버전을 고정하지 않았다면 버전 고정도 도움이 되지 않았습니다.

API 개발자는 특히 취약합니다. 테스트 스크립트, CI/CD 파이프라인, 모의 서버 및 HTTP 클라이언트는 모두 npm에서 가져옵니다. 도구 체인에서 단일 손상된 패키지는 개발 시스템에서 API 키, 데이터베이스 자격 증명 및 클라우드 토큰을 유출할 수 있습니다.

💡
Apidog는 API 테스트를 위한 내장 HTTP 클라이언트를 제공하여 주요 공격 벡터 중 하나를 제거하므로 테스트 스택에 Axios, node-fetch 또는 got이 필요하지 않습니다. 아래 방어 전략을 따르면서 npm 종속성 표면을 줄이려면 Apidog를 무료로 다운로드하십시오.

button

이 가이드는 기본적인 록파일 위생부터 고급 행동 분석에 이르기까지 7가지 보호 계층을 다룹니다.

계층 1: 록파일 적용

록파일이 중요한 이유

록파일은 설치 시점의 모든 패키지와 전이적 종속성의 정확한 버전을 기록합니다. 록파일이 없으면 npm install은 semver 범위에 맞는 최신 버전을 확인합니다. package.json에 "axios": "^1.14.0"이라고 되어 있고 악성 1.14.1이 레지스트리에 있다면, 악성 버전을 얻게 됩니다.

규칙

항상 록파일을 커밋하세요. package-lock.json(npm), yarn.lock(Yarn), pnpm-lock.yaml(pnpm), 또는 bun.lock(Bun)이든 관계없이 버전 제어에 포함되어야 합니다.

CI/CD에서 고정 설치를 사용하십시오. 자동화된 환경에서는 절대 npm install을 실행하지 마십시오. 고정된 록파일과 동등한 다음 명령을 사용하십시오:

# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile

npm ci는 node_modules를 삭제하고 록파일에서 엄격하게 설치합니다. 록파일이 package.json과 일치하지 않으면 실패합니다. 이는 해결 중 발생할 수 있는 예상치 못한 상황을 방지합니다.

풀 리퀘스트에서 록파일 차이점을 검토하십시오. PR이 package-lock.json을 수정할 때, 어떤 내용이 변경되었는지 확인하십시오. 새로운 종속성, 버전 변경 및 레지스트리 URL 변경은 모두 면밀한 조사를 받아야 합니다. Socket.dev와 같은 자동화 도구는 PR 검토에서 의심스러운 록파일 변경을 표시할 수 있습니다.

록파일의 한계

록파일은 예상치 못한 버전 해결로부터 보호하지만, 첫 설치 시에는 보호하지 못합니다. 공격 기간 동안 프로젝트를 초기화하거나 새로운 종속성을 추가하면 악성 버전이 고정됩니다. 이것이 록파일이 유일한 계층이 아닌 계층 1인 이유입니다.

계층 2: postinstall 스크립트 비활성화

주요 공격 벡터

Axios 공격, ua-parser-js 공격, event-stream 공격 및 수십 가지 다른 공격들은 모두 동일한 메커니즘을 사용했습니다: npm install 중에 임의의 코드를 실행하는 postinstall 스크립트입니다. 이 훅은 애플리케이션 코드가 실행되기 전, 패키지를 검토하기 전, 그리고 어떤 런타임 보안 도구도 개입하기 전에 실행됩니다.

스크립트 전역 차단

.npmrc에 다음을 추가하십시오:

ignore-scripts=true

또는 CLI를 통해 설정하십시오:

npm config set ignore-scripts true

이렇게 하면 패키지 설치 중에 모든 라이프사이클 스크립트(preinstall, install, postinstall, prepare)가 실행되는 것을 방지합니다.

스크립트가 필요한 패키지 처리

일부 패키지는 네이티브 컴파일을 위해 postinstall 스크립트가 필요합니다(예: bcrypt, sharp, sqlite3). 두 가지 옵션이 있습니다:

옵션 1: 설치 후 스크립트를 선택적으로 실행

npm ci --ignore-scripts
npm rebuild bcrypt sharp

옵션 2: 허용 목록 사용 (npm 10 이상)

신뢰할 수 있는 패키지만 스크립트를 실행하도록 허용하는 .scriptsrc.json을 생성하십시오:

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}

옵션 3: 미리 빌드된 바이너리 사용

이전에 네이티브 컴파일이 필요했던 많은 패키지들이 이제 미리 빌드된 바이너리를 제공합니다. 예를 들어 sharp는 대부분의 플랫폼용으로 미리 빌드된 바이너리를 제공하여 postinstall 컴파일의 필요성을 없앱니다. 종속성을 확인하십시오. 생각보다 스크립트 예외가 적게 필요할 수 있습니다.

PackageGate 주의사항

2026년 1월, 연구원들은 npm, pnpm, vlt 및 Bun에 영향을 미치는 "PackageGate"라는 6가지 제로데이 취약점을 공개했습니다. 한 가지 발견 사항: Git 기반 종속성은 라이프사이클 스크립트가 비활성화된 경우에도 코드 실행을 가능하게 하는 구성 파일을 포함할 수 있습니다. package.json이 종속성으로 Git URL을 참조하는 경우, ignore-scripts만으로는 충분하지 않습니다. 해당 종속성을 특정 커밋 해시에 고정하고 저장소 내용을 감사하십시오.

계층 3: 정확한 버전 고정

semver 범위 사용 중지

npm install --save의 기본 동작은 캐럿 접두사를 사용하여 패키지를 추가합니다:

{
  "axios": "^1.14.0"
}

^는 "1.14.0과 호환"을 의미하며, 이는 최신 1.x.x 버전으로 해결됩니다. Axios 공격 중에는 1.14.1로 해결되는 것을 의미했습니다.

대신 정확한 버전을 고정하십시오:

{
  "axios": "1.14.0"
}

npm이 기본적으로 정확한 버전을 저장하도록 구성하십시오:

# .npmrc
save-exact=true
save-prefix=''

전이적 종속성에 대한 재정의 사용

직접적인 종속성에는 자체 종속성이 있습니다. 전이적 종속성이 침해된 경우, 직접적인 종속성을 고정하는 것은 도움이 되지 않습니다. 전이적 해결을 제어하기 위해 재정의를 사용하십시오:

{
  "overrides": {
    "axios": "1.14.0",
    "plain-crypto-js": "npm:empty-npm-package@1.0.0"
  }
}

Yarn의 경우:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}

pnpm의 경우:

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}

트레이드오프

정확한 버전 고정은 자동 패치 업데이트를 받지 못한다는 것을 의미합니다. 버전을 수동으로 올려야 하므로 유지보수 오버헤드가 발생합니다. 이 트레이드오프는 의도적인 것입니다: 자동 업데이트 대신 제어된 업데이트를 선택하는 것입니다. 보안에 민감한 프로젝트의 경우 이 트레이드오프는 그만한 가치가 있습니다.

계층 4: 패키지 출처 확인

출처의 의미

npm 출처 증명은 공개 투명성 원장에 기록된 Sigstore 서명을 사용하여 게시된 패키지를 소스 코드 및 빌드 환경에 연결합니다. 출처가 활성화된 CI/CD 파이프라인에서 패키지가 게시될 때, 해당 패키지에는 다음 사항에 대한 암호화된 증명이 포함됩니다:

출처를 확인하는 방법

npm audit signatures

이는 설치된 패키지에 유효한 출처 증명이 있는지 확인합니다. 개발자의 시스템에서 수동으로 게시된 패키지에는 출처가 없습니다.

악성 Axios 버전은 OIDC 출처 바인딩이 없었고 해당 GitHub 커밋도 없었습니다. 자동화된 출처 확인이 표준 관행이었다면, 공격은 즉시 경고를 발생시켰을 것입니다.

자신의 패키지에 출처 활성화

npm 패키지를 게시하는 경우 CI/CD에서 출처를 활성화하십시오:

# GitHub Actions 예시
- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

.npmrc에 다음을 추가하십시오:

provenance=true

제한 사항

출처는 선택 사항입니다. 대부분의 npm 패키지는 아직 이를 가지고 있지 않습니다. 그리고 출처는 패키지가 어디에서 빌드되었는지("where")만 증명합니다. 소스 코드가 안전하다는 것을 ("what") 증명하지는 않습니다. 손상된 CI/CD 파이프라인은 유효한 출처와 함께 악성 패키지를 게시할 수 있습니다.

계층 5: 행동 분석 도구 사용

취약점 스캔을 넘어서

npm audit 및 Snyk와 같은 전통적인 도구는 알려진 취약점(CVE) 데이터베이스에 대해 검사합니다. 이러한 도구는 보고된 문제를 탐지하지만 제로데이 공격은 놓칩니다. Axios 침해는 게시되었을 때 어떤 CVE 데이터베이스에도 없었습니다.

행동 분석 도구는 패키지가 무엇을 하는지("what they do")를 조사하며, 그 패키지에 대해 무엇이 보고되었는지("what's been reported")는 조사하지 않습니다.

Socket.dev

Socket은 설치 및 런타임 동안 패키지 동작을 분석합니다. 다음을 표시합니다:

GitHub와 통합되면 Socket은 새로운 종속성이 의심스러운 동작을 보일 때 PR에 댓글을 답니다. Axios 공격의 plain-crypto-js 종속성은 난독화된 코드, postinstall 중 네트워크 요청, 패키지 디렉토리 외부 파일 시스템 쓰기와 같은 여러 Socket 경고를 트리거했을 것입니다.

# Socket CLI 설치
npm install -g @socketsecurity/cli

# 프로젝트 스캔
socket scan

Snyk

Snyk는 위험 점수, 익스플로잇 성숙도 데이터 및 수정 지침을 제공하는 취약점 관리를 제공합니다. 알려진 취약점에는 강력하지만 제로데이 행동 탐지에는 약합니다.

# Snyk CLI 설치
npm install -g snyk

# 프로젝트 테스트
snyk test

계층적 접근 방식

둘 다 사용하십시오. Socket은 Snyk가 놓치는 행동 이상을 탐지합니다. Snyk는 Socket이 제공하는 것보다 더 풍부한 컨텍스트로 알려진 취약점을 탐지합니다. npm audit을 기본으로 추가하십시오:

# 기본
npm audit

# 행동 분석
socket scan

# 취약점 관리
snyk test

CI/CD에서 세 가지 모두를 게이트로 실행하십시오. 중요 경고는 빌드를 차단해야 합니다.

계층 6: 종속성 표면 최소화

더 깊은 질문

node_modules의 모든 패키지는 신뢰 결정의 대상입니다. Axios 공격은 주간 8,300만 다운로드를 기록하는 패키지를 침해했습니다. 일반적인 Node.js 프로젝트에는 수백 개의 전이적 종속성이 있습니다. 각각은 잠재적인 공격 벡터입니다.

가장 효과적인 방어는 방어할 종속성을 줄이는 것입니다.

종속성 트리 감사

# 총 종속성 수 세기
npm ls --all | wc -l

# 중복 확인
npm ls --all | sort | uniq -c | sort -rn | head -20

각 종속성에 대해 다음 질문을 하십시오:

일반 패키지에 대한 네이티브 대안

패키지 네이티브 대안 사용 가능 버전
axios, node-fetch, got fetch (글로벌) Node.js 18
uuid crypto.randomUUID() Node.js 19
dotenv --env-file 플래그 Node.js 20.6
chalk util.styleText() Node.js 21.7
glob fs.glob() Node.js 22
path-to-regexp 네이티브 URL 패턴 API Node.js 23

특히 API 테스트를 위해

API 테스트 워크플로우는 일반적으로 HTTP 클라이언트 라이브러리, 어설션 라이브러리, 테스트 러너 및 모의 서버에 의존합니다. 각 종속성은 공격 표면입니다.

Apidog는 전체 스택을 단일 플랫폼으로 대체합니다:

API 테스트 워크플로우를 Apidog로 옮기면 테스트 인프라에서 수십 개의 npm 종속성이 제거됩니다. 종속성이 적다는 것은 신뢰 결정이 적고 공격 벡터도 적다는 것을 의미합니다.

Apidog를 무료로 사용해 API 테스트 스택을 통합해 보세요.

button

계층 7: 네트워크 및 런타임 모니터링

알려진 악성 도메인 차단

공급망 공격 후에는 네트워크 수준에서 명령 및 제어 인프라를 차단하십시오:

# /etc/hosts에 추가
echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts

CI/CD 환경에서는 알려진 양호한 도메인으로의 아웃바운드 네트워크 액세스를 제한하십시오. 대부분의 빌드 프로세스는 npm 레지스트리, Git 호스트 및 배포 대상에만 액세스하면 됩니다. 그 외의 모든 것은 기본적으로 차단되어야 합니다.

CI/CD를 위해 StepSecurity Harden-Runner 사용

StepSecurity의 Harden-Runner는 GitHub Actions 워크플로우를 실시간으로 모니터링합니다. npm install이 시작된 지 1.1초 이내에 Axios 드로퍼가 C2에 연결하는 것을 감지했습니다. 이 도구는 다음을 제공합니다:

# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # 엄격 모드의 경우 'block'

런타임 프로세스 모니터링

개발 머신의 경우 Node.js에 의해 생성된 의심스러운 자식 프로세스를 플래그 지정하는 엔드포인트 탐지 및 응답(EDR) 도구를 고려하십시오. Axios RAT는 npm 설치 프로세스 내에서 osascript(macOS), cscript(Windows) 및 python3(Linux)를 생성했습니다. 이러한 자식 프로세스 패턴은 탐지할 수 있습니다.

권장 .npmrc 구성

위 계층들을 결합한 보안 강화 .npmrc 파일은 다음과 같습니다:

# 정확한 버전 고정
save-exact=true
save-prefix=

# 라이프사이클 스크립트 비활성화
ignore-scripts=true

# 게시를 위한 출처 활성화
provenance=true

# 공식 레지스트리 사용
registry=https://registry.npmjs.org/

# 게시를 위한 2FA 요구
auth-type=web

# 감사 레벨 임계값
audit-level=moderate

모든 팀원이 동일한 보안 설정을 사용하도록 이 파일을 저장소에 커밋하십시오.

CI/CD 보안 파이프라인 예시

다음은 7가지 모든 계층을 적용하는 GitHub Actions 워크플로우입니다:

name: Secure Build
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # 계층 1+2: 고정 록파일, 스크립트 없음
      - run: npm ci --ignore-scripts

      # 계층 3: 예상치 못한 버전 없음 확인
      - run: npm ls --all > deps.txt

      # 계층 4: 출처 확인
      - run: npm audit signatures

      # 계층 5: 행동 분석
      - run: npx socket scan

      # 계층 5: 취약점 스캔
      - run: npx snyk test

      # 계층 1: 기본 감사
      - run: npm audit --audit-level=moderate

      # 허용된 네이티브 종속성만 다시 빌드
      - run: npm rebuild sharp bcrypt

npm 보안의 다음 단계

인기 패키지에 대한 출처 의무화

npm은 특정 다운로드 임계값 이상의 패키지에 대해 출처 증명을 의무화하는 것을 논의 중입니다. 이는 Axios 공격을 가능하게 한 수동 토큰 기반 게시를 방지할 것입니다.

2인 릴리스 승인

이중 승인이 필요한 금융 거래와 같이, 다운로드 수가 많은 패키지는 두 번째 관리자가 릴리스를 승인해야 할 수 있습니다. 단일 계정 침해로는 충분하지 않을 것입니다.

런타임 권한 범위 지정

Deno는 명시적으로 부여되지 않는 한 스크립트가 액세스할 수 있는 것(네트워크, 파일 시스템, 환경 변수)을 이미 제한합니다. Node.js는 유사한 권한 모델을 탐색 중입니다. 이것이 출시되면 postinstall 스크립트는 네트워크 요청을 하거나 파일 시스템에 액세스하기 위해 명시적인 권한이 필요할 것입니다.

패키지 관리자 컨버전스

pnpm의 엄격한 격리 모델(패키지는 선언된 종속성만 액세스할 수 있음)은 많은 종속성 혼란 공격을 방지합니다. npm이 유사한 엄격함을 채택함에 따라 공격 표면은 줄어듭니다.

FAQ

npm에서 공급망 공격이란 무엇인가요?

npm에서의 공급망 공격은 애플리케이션을 직접 노리는 대신 소프트웨어 종속성 체인을 대상으로 합니다. 공격자는 패키지 관리자 계정을 침해하거나, 인기 패키지에 악성 코드를 주입하거나, 유사한 이름을 가진 타이포스쿼팅 패키지를 게시합니다. 종속성을 설치하거나 업데이트할 때, 악성 코드는 사용자 시스템이나 CI/CD 파이프라인에서 실행되어 자격 증명을 훔치고, 백도어를 설치하거나, 데이터를 유출합니다.

npm audit만으로 공급망 공격으로부터 보호하기에 충분한가요?

아닙니다. npm audit은 알려진 취약점(CVE) 데이터베이스에 대해 검사합니다. Axios 침해와 같은 제로데이 공격은 발생 시 어떤 CVE 데이터베이스에도 없습니다. 패키지에 대해 보고된 내용이 아니라 패키지가 무엇을 하는지("what they do")를 조사하는 Socket.dev와 같은 행동 분석 도구가 필요합니다. npm audit은 유일한 방어가 아닌 기본 기준으로 사용하십시오.

npm 사용을 완전히 중단해야 하나요?

아닙니다. npm은 여전히 가장 큰 패키지 생태계이며, 대부분의 패키지는 안전합니다. 목표는 정확한 버전 고정, 록파일 적용, 스크립트 차단 및 종속성 최소화를 통해 노출을 줄이는 것입니다. 각 종속성이 필요한지 고려하고, 가능하면 네이티브 대안을 사용하십시오.

Apidog는 npm 공급망 위험을 줄이는 데 어떻게 도움이 되나요?

Apidog는 API 개발을 위한 내장 HTTP 클라이언트, 테스트 러너, 모의 서버 및 문서 생성기를 제공합니다. 이는 Axios, node-fetch, Jest, Express(모의 서버용)와 같은 npm 패키지 및 기타 테스트 종속성에 대한 필요성을 없앱니다. npm 종속성이 적다는 것은 API 개발 워크플로우에서 공격 벡터가 적다는 것을 의미합니다.

npm에서 패키지 출처(provenance)란 무엇인가요?

패키지 출처는 Sigstore를 사용하여 게시된 패키지를 소스 저장소 및 CI/CD 빌드 환경에 암호화 방식으로 연결합니다. 이는 패키지가 어디서 어떻게 빌드되었는지 증명합니다. npm audit signatures를 사용하여 출처를 확인할 수 있습니다. 개발자 시스템에서 수동으로 게시된 패키지는 출처가 없으며, 이는 다운로드 수가 많은 패키지에서는 위험 신호입니다.

악성 npm 패키지는 몇 개나 되나요?

Snyk는 2024년에 3,000개 이상의 악성 npm 패키지를 확인했습니다. 2025년 4분기까지 Sonatype은 npm, PyPI 및 기타 레지스트리에서 한 분기 동안 120,612건의 멀웨어 공격을 차단했습니다. 이 숫자는 증가하고 있습니다. 대부분의 악성 패키지는 다운로드 수가 적은 타이포스쿼팅이지만, Axios와 같은 고위험 침해 사례는 인기 패키지도 안전하지 않다는 것을 증명합니다.

PackageGate 취약점은 무엇인가요?

PackageGate는 2026년 1월에 공개된 npm, pnpm, vlt 및 Bun에 영향을 미치는 6가지 제로데이 취약점 세트입니다. 한 가지 발견 사항은 Git 기반 종속성이 라이프사이클 스크립트가 비활성화된 경우에도 코드 실행을 가능하게 하는 구성 파일을 포함할 수 있다는 것을 보여줍니다. 이는 종속성이 Git 저장소를 참조하는 경우 ignore-scripts만으로는 충분하지 않다는 것을 의미합니다. Git 종속성을 특정 커밋 해시에 고정하십시오.

핵심 요약

모든 종속성은 신뢰 결정의 대상입니다. 종속성이 적을수록 공격 표면은 작아집니다. 더 많은 검증 계층을 적용할수록 공격자가 침투하기가 더 어려워집니다. 방어를 고립적으로 구축하지 말고 심층적으로 구축하십시오.

button

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드