100만 달성한 오픈소스 패키지, 사용자 자격 증명 유출

`element-data`는 월 100만 다운로드 규모의 npm 패키지로, 공격자가 패키지를 악성 버전으로 갈아치우거나 유사 이름으로 위장(타이포스쿼팅)하여 자격증명 탈취 코드를 심은 전형적인 공급망 공격 사례입니다. 이런 공격은 보통 `package.json`의 `postinstall`·`preinstall` 같은 라이프사이클 훅이나 동적 import를 이용해 `npm install` 시점에 자동 실행되며, `~/.npmrc`, `~/.aws/credentials`, `~/.docker/config.json`, `process.env`, 브라우저 쿠키, SSH 키 등 로컬에 저장된 토큰·비밀번호를 수집해 외부 C2 서버로 전송합니다. 정적 분석을 회피하기 위해 base64·hex 인코딩, 문자열 난독화, 실행 환경 탐지(CI/sandbox 회피) 같은 기법이 함께 쓰이며, 의존성 트리를 통해 직접 설치하지 않은 프로젝트에도 transitive dependency로 침투할 수 있다는 점이 본질적인 위험입니다.

엔지니어 입장에서 가장 큰 충격은 "내가 직접 설치한 적이 없는 패키지"가 빌드 머신과 CI에서 이미 실행됐을 수 있다는 점입니다. 로컬 개발자 PC에서 토큰이 한 번 유출되면 GitHub PAT, npm 퍼블리시 토큰, 클라우드 자격증명을 통해 조직 내부 리포지토리·인프라까지 횡적 이동(lateral movement)이 가능하며, 특히 npm 퍼블리시 토큰이 새면 본인이 관리하는 다른 패키지까지 악성 버전으로 배포되는 2차 공급망 공격으로 번질 수 있습니다. 월 100만 다운로드 규모라면 사내 프론트엔드 빌드 파이프라인, 도커 이미지, CI 캐시에 이미 침투했을 가능성을 전제로 사고 대응을 시작해야 하며, "내 코드만 안전하면 된다"는 가정은 더 이상 유효하지 않습니다.

당장 해야 할 조치는 명확합니다. 첫째, `npm ls element-data`(및 의심 변형명)로 직간접 의존성 여부를 확인하고 `package-lock.json`까지 grep해 lockfile 깊이의 의존성도 점검하세요. 둘째, 영향이 의심되면 **모든 npm·GitHub·클라우드(AWS/GCP) 토큰, SSH 키, .env 시크릿을 즉시 로테이션**하고 GitHub Audit Log·CloudTrail에서 비정상 접근을 역추적해야 합니다. 셋째, 재발 방지를 위해 `npm ci --ignore-scripts`로 빌드, Renovate/Dependabot의 자동 머지 정책 재검토, `npm audit signatures`·Sigstore 검증, 사내 프록시 레지스트리(Verdaccio/Nexus)에서의 화이트리스트 운영, 그리고 CI에서 시크릿을 OIDC 단기 토큰으로 전환하는 등 "패키지를 신뢰하지 않는다"는 전제로 파이프라인을 재설계할 시점입니다. 공급망 공격은 더 이상 예외 사건이 아니라 상시 리스크라는 인식 전환이 필요합니다.