- 아마존 보안 연구팀이 Debug와 Chalk 등 npm 패키지 침해를 북한 해커 그룹의 소행으로 추적해 공개함
- 공격은 타이포스쿼팅(Typo-squatting)으로 위장한 악성 npm 패키지를 배포해 개발자 빌드 환경을 감염시키는 방식을 사용함
- 개발 조직은 npm 의존성 감사, package-lock.json 무결성 검증, 사설 레지스트리 전환 등 공급망 방어 강화가 시급함
글로벌 클라우드 사업자가 공식 attribution을 제시한 이번 사건은 오픈소스 생태계의 신뢰 재설계 필요성을 다시 한번 확인한 사례임
2026년 7월 30일, Bleeping Computer는 아마존이 Debug와 Chalk 등 다수의 npm 패키지에서 발생한 공급망 공격을 북한 해커 그룹의 소행으로 명확히 추적했다고 보도했다. 이번 사건은 단순한 단일 패키지 침해를 넘어, 국가 지원을 받는 공격자가 Node Package Manager 생태계 전체를 겨냥하고 있음을 보여주는 대표 사례로 평가된다. 본문에서는 아마존의 분석 결과를 바탕으로 침해 흐름과 개발 조직이 즉시 취해야 할 점검 항목을 정리한다.
공격 개요: Debug와 Chalk 패키지를 노린 북한 npm 공급망 침해
아마존 보안 연구팀은 자사 빌드 파이프라인과 외부 보고를 교차 분석한 결과, Debug와 Chalk를 포함한 일련의 npm 패키지에서 유사한 침해 패턴을 발견했다. 이들 패키지는 다운로드 수 기준 주요 의존성으로 분류되는 대표 패키지인 만큼, 단 한 번의 감염만으로도 다수의 빌드 환경으로 악성코드가 전파될 수 있다는 점이 위험도를 높였다. 보도에 따르면 침해 패키지 다수가 npm 공식 레지스트리를 통해 배포되었으며, 일반적인 npm install 명령만으로도 감염이 이뤄진 것으로 파악된다.
침해 기법 분석: 타이포스쿼팅과 악성 스크립트 삽입 흐름
아마존은 이번 사건의 핵심 침투 경로로 타이포스쿼팅과 빌드 훅을 통한 악성 스크립트 삽입을 지목했다. 다만 발췌 원문에 따르면 자동 추천과 검색 노출을 통한 유도 방식은 확인되지 않은 정황이며, 구체적 유포 경로는 원문에서 단정되지 않는다.
유사 이름 패키지를 통한 개발자 오설치 유도
타이포스쿼팅은 chalk-debug, debug-chalk 등 정품과 혼동하기 쉬운 이름을 등록하는 방식으로 진행된 것으로 보도됐다. 개발자가 터미널에서 패키지명을 직접 타이핑하는 과정에서 발생하는 미세한 오타가 그대로 악성 패키지로 연결되며, 감염 즉시 postinstall 스크립트가 동작해 빌드 머신의 자격 증명을 외부 서버로 유출시키는 구조를 갖췄다.
빌드 환경 침투 후 자격 증명 탈취 절차
침투 이후 단계에서는 GitHub 토큰, AWS 액세스 키, npm 게시 토큰 등 클라우드 자격 증명을 순차적으로 수집한 뒤, 이를 토대로 동일 조직 또는 동일 빌드 환경의 다른 패키지로의 횡적 이동이 이뤄졌을 것으로 추정된다.과 내부 레지스트리 접근 시도가 이뤄진 것으로 분석된다. 즉 1차 감염을 발판으로 조직 내부 신뢰 경계를 추가 침투하는 전형적인 국가 지원형 캠페인 흐름을 따랐다는 평가다.
아마존의 공격자 attribution 방식과 증거 연계
아마존은 침해 패키지에서 추출한 인프라 지표, 페이로드 코드 재사용 패턴, 그리고 과거에 알려진 북한 연계 캠페인의 행위 특징을 교차 매칭해 attribution을 제시했다. 보도된 내용에 따르면 사용된 인프라 중 일부는 과거 라자루스(Lazarus) 및 관련 그룹이 활용한 인프라와 일부 겹치는 것으로 보도됐으며, 코드 내부의 주석과 문자열 표기도 동일 그룹의 기존 도구와 일치하는 양상을 보였다. 다만 일부 요소는 공개 정보에 기반한 추론에 가까워, 단정적 표현보다는 공격자 프로파일 수준의 평가로 해석하는 것이 적절하다.
국내외 개발 조직에 미치는 영향과 긴급 점검 항목
이번 사건은 npm 의존성을 광범위하게 사용하는 한국 개발 조직에도 직접적 영향을 미친다. 글로벌 클라우드 사업자가 attribution까지 명시한 사례라는 점에서 보안팀과 DevOps팀은 침해 대응뿐 아니라 선제적 점검 항목 마련을 검토할 필요가 있다.
| 점검 영역 | 핵심 확인 항목 | 권장 도구 |
|---|---|---|
| 의존성 잠금 파일 | package-lock.json 해시 일관성, 알 수 없는 패키지 등록 여부 | npm audit, lockfile-lint |
| 빌드 훅 스크립트 | postinstall 등 라이프사이클 스크립트 내 의심 명령 존재 여부 | npm config set ignore-scripts, SBOM 스캐너 |
| 자격 증명 로테이션 | 침해 의심 기간 이후 발급된 토큰 전량 재발급 | 내부 비밀 관리 시스템, IAM 정책 |
| 패키지 출처 통제 | 사설 레지스트리 미러 및 승인 패키지 화이트리스트 운영 | Verdaccio, Nexus, GitHub Packages |
package-lock.json 재검증 절차
가장 먼저 수행해야 할 조치는 모든 저장소의 package-lock.json을 원본 커밋과 비교해 무결성을 확인하는 절차다. 침해된 패키지는 잠금 파일에 정상적 메타데이터를 등록하기 때문에 단순 npm audit만으로는 탐지가 어렵다. 따라서 lockfile-lint와 같은 도구로 무결성을 검증하고, 등록된 resolved URL이 공식 레지스트리 도메인인지 함께 점검해야 한다.
사설 레지스트리 및 SBOM 기반 방어 전환
장기적으로는 사설 npm 레지스트리를 도입해 승인된 패키지만 내부로 유입시키는 통제 체계가 효과적인 대응책으로 거론된다. 또한 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 자동 생성하고 변경 이력을 추적하면, 신규 침해가 발생하더라도 영향 범위를 빠르게 식별할 수 있다. 업계에서는 SBOM 도입을 선택이 아닌 필수 기준으로 전환해야 한다는 시각이 확산되고 있는 추세다.
결론: 오픈소스 공급망 신뢰 재설계의 필요성
이번 Debug와 Chalk 사건은 글로벌 클라우드 사업자가 공식 attribution까지 제시한 사례라는 점에서, 오픈소스 공급망 위협이 단순 기술 이슈를 넘어 국가 안보 수준으로 다뤄질 필요가 있음을 시사한다. 향후에는 패키지 게시자 신원 검증, 자동화된 의존성 감사, 그리고 빌드 환경 격리 기술이 결합된 다층 방어 체계가 표준으로 자리 잡을 것으로 보인다. 개발 조직 입장에서는 침해 발생 이후의 대응보다, 사전에 의존성 신뢰 경계를 어떻게 설계하느냐가 핵심 경쟁력으로 부상할 것으로 분석된다.
- 아마존은 Debug와 Chalk 침해를 북한 해커 그룹으로 추적해 공식 발표했으며, 이는 국가 지원형 npm 공급망 공격의 대표 사례로 기록될 전망임
- 공격 흐름은 타이포스쿼팅 패키지 배포, postinstall 훅 실행, 자격 증명 탈취의 3단계로 정리되며 빌드 환경 침투가 핵심 목표임
- 개발 조직은 package-lock.json 무결성 검증, postinstall 스크립트 차단, 자격 증명 로테이션, 사설 레지스트리 도입을 즉시 점검해야 함
- 장기적으로는 SBOM 기반 가시성 확보와 패키지 게시자 신뢰 검증 체계 구축이 오픈소스 공급망 방어의 새로운 기준이 될 것으로 보임
참고 자료: