pile·
보안·인프랩 (인프런)인프런 (인프랩)·

소프트웨어 공급망 공격, pnpm으로 1차 방어선 구축하기

인프랩이 소프트웨어 공급망 공격(Supply-Chain Attack)에 대응하기 위해 pnpm 11의 보안 설정을 활용해 조직 전체의 1차 방어선을 구축한 과정을 다룬다. 2025년 3월 Axios npm 패키지가 탈취되어 악성 코드가 게시 후 6분 만에 배포된 사례를 출발점으로, pnpm 11의 기본 보안 옵션들이 이런 공격을 어떻게 원천 차단하는지 설명한다.

핵심 포인트
  • 공급망 공격은 서비스 인프라를 직접 공격하지 않고 외부 의존성(npm 패키지)을 먼저 침해해 내부망에 침투하는 고도의 우회 기법이다.
  • 2025년 3월 Axios 사건: npm 계정 탈취 후 악성 의존성 주입 → postinstall 스크립트로 .env·AWS 자격증명·SSH 키를 C2 서버로 전송, 6분 만에 정적 분석 도구가 탐지했다.
  • pnpm 11의 minimumReleaseAge(기본 1440분) 설정으로 신규 게시 버전 즉시 설치를 차단해 보안 커뮤니티 탐지 시간을 확보한다.
  • strictDepBuilds(기본 true)로 미승인 빌드 스크립트가 포함된 의존성 설치를 차단해 postinstall 류 공격을 원천 봉쇄한다.
  • 설치 시점 방어는 1차 방어선일 뿐 — import 시점·런타임·난독화 공격에 대한 다층 방어가 추가로 필요하다.
상세 정리
  • 공급망 공격 정의: 최종 타깃을 직접 공격하지 않고 개발 과정에서 신뢰하는 외부 자산(npm 패키지)을 먼저 침해한 뒤 징검다리로 삼아 내부망에 침투하는 기법이다.
  • Axios 사건 전개: 공격자가 npm 계정 탈취 → plain-crypto-js@4.2.1 악성 패키지를 의존성 트리에 강제 추가 → postinstall 스크립트로 setup.js 드로퍼 실행 → .env, AWS 자격증명, SSH 키를 C2 서버로 전송 → 깨끗한 패키지로 위장. 게시 후 6분 만에 탐지됐다.
  • lifecycle scripts 위험: npm install 시 preinstall → install → postinstall → prepare 등이 자동 실행돼 개발자가 코드를 실행하기 전에 악성 코드가 활성화될 수 있다.
  • pnpm 11 선택 이유: 인프랩 대부분의 저장소가 이미 pnpm을 사용 중이고, pnpm 11에서 보안 설정이 기본값으로 강화되며 Node.js 22 지원으로 안정성이 검증됐다.
  • minimumReleaseAge: 기본값 1440분(24시간). 게시된 지 24시간 이내 버전 설치를 차단해 캐럿 범위(^1.14.0)로도 안전한 버전만 설치된다.
  • strictDepBuilds: 기본값 true. 미승인 빌드 스크립트가 있는 의존성 설치 자체를 실패시켜 Axios 류 postinstall 공격을 원천 봉쇄한다.
  • allowBuilds 화이트리스트: 정상 동작에 필요한 패키지(esbuild, sharp 등)만 명시적으로 허용하고 최소한으로 유지한다.
  • blockExoticSubdeps: 간접 의존성이 npm 외 외부 소스(Git URL, HTTP tarball)에서 설치되는 것을 차단해 의존성 트리 무결성을 지킨다.
  • trustPolicy(no-downgrade): 이전 버전보다 신뢰 수준이 낮아지는 업그레이드(Trusted Publisher → None)를 차단한다.
  • verifyDepsBeforeRun: CI에서 error 설정 시 의존성이 불완전하면 스크립트 실행을 중단해 파이프라인 보안을 강화한다.
  • 마이그레이션 팁: 기존 pnpm 사용자는 한 메이저 버전씩(8→9→10→11) 단계적으로 업그레이드. npm/yarn 전환 시 pnpm import 명령으로 기존 락 파일을 pnpm-lock.yaml로 변환한다.
  • 한계 인정: 설치 시점 방어가 강화될수록 공격자는 import 시점, 런타임 실행, 난독화된 악성 로직으로 전환할 수 있어 다층 방어 전략이 필수다.
왜 읽나npm/pnpm을 사용하는 프론트엔드·풀스택 개발자와 DevSecOps 담당자에게 실제 공격 사례 기반의 의존성 보안 설정 레퍼런스.
인프랩 (인프런)
인프런 (인프랩) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 보안·cloudflare-blogCloudflare Blog·

    사이트 소유자를 위한 새 AI 트래픽 제어 옵션

    Cloudflare가 Content Independence Day 1주년을 맞아 웹사이트 소유자가 AI 트래픽을 목적별로 세분화해 제어할 수 있는 새 시스템을 공개했다. 기존 "AI 봇 차단" 토글을 넘어 Search·Agent·Training 세 카테고리로 봇을 분류하고, robots.txt에 콘텐츠 재사용 범위를 선언하는 새 use= 시그널을 도입했다. 멀티퍼포스 봇은 가장 제한적인 카테고리 규칙이 적용되며, 2026년 9월 15일부터 광고 페이지에 새 기본값이 적용된다.

    #web-security#bot-management#robots-txt+2
  2. 보안·cloudflare-blogCloudflare Blog·

    Cloudflare 앱 생태계 OAuth 전면 개방 — Hydra 마이그레이션 내막

    Cloudflare가 OAuth 인프라를 Hydra 1.X에서 2.X로 업그레이드하면서 자체 관리 OAuth를 전체 개발자에게 개방한 과정을 다룬다. 스키마 변경으로 인한 인덱스 락 문제, 블루-그린 배포 전략, 전환 중 revocation 큐 설계, 전환 후 리프레시 토큰 버그까지 실제 운영 사고와 해결을 상세히 기록했다.

    #database-migration#zero-downtime#oauth+2
  3. 보안·cloudflare-blogCloudflare Blog·

    양자 내성 암호화 행정명령(EO 14409) — 2030 전환 기한과 조직 대응 방안

    2026년 6월 22일 트럼프 대통령이 서명한 행정명령 EO 14409는 미 연방 기관에 2030년까지 암호화(키 교환) 전환, 2031년까지 디지털 서명 전환을 요구한다. Cloudflare는 이미 자사 네트워크 브라우저 트래픽의 2/3 이상을 PQC(Post-Quantum Cryptography)로 보호 중이며, 이 글은 행정명령의 기술적 함의와 조직이 지금 당장 해야 할 일을 정리한다.

    #tls#cryptography#post-quantum-cryptography+2