공급망 사고는 계약 코드가 직접 뚫리지 않아도 일어납니다. 패키지 게시 계정이나 빌드, 콘텐츠 전송망(CDN)에 악성 코드가 들어가 사용자에게 서명을 유도할 수 있기 때문입니다. 피해 범위를 가리려면 악성 패키지와 버전, 게시 시각, 잠금 파일(lockfile)과 설치 로그, 번들 해시, 실행 중 CDN 로드, 캐시가 남아 있던 시간, 실제로 서명된 거래를 확인해야 합니다. 온체인 계약, 하드웨어 지갑, 웹 프런트엔드 침해 범위는 각각 따로 적습니다.
공식 저장소가 멀쩡해도 배포물은 오염될 수 있습니다
개발자는 Git 저장소를 검토하지만 실제 앱은 npm 패키지나 CDN 번들을 받아 씁니다. 게시용 토큰이나 외부 계정을 빼앗기면 저장소에 악성 커밋이 하나도 없어도 새 버전에 코드가 끼어들 수 있습니다. 깃허브는 뚫리지 않았다는 해명만으로 이용자 노출이 없었다고 말할 수는 없습니다.
Ledger가 낸 2023년 Connect Kit 사고 보고서에 따르면, 퇴사한 직원의 npm 접근 권한이 지워지지 않은 틈을 타 공격자가 1.1.5·1.1.6·1.1.7을 게시했습니다. 실행 시점에 코드를 불러오는 로더를 쓰던 탈중앙 앱(DApp)은 그대로 악성 번들을 내려받았습니다. 보고서는 Ledger 자체 인프라·저장소·앱 접근과 패키지 배포 경로를 따로 나눠 설명했습니다.
공급망 사고에서는 코드를 어디서 썼느냐보다, 사용자 브라우저에 어떤 바이트가 언제 도착했느냐가 더 중요합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 공식 저장소가 멀쩡해도 배포물은 오염될 수 있습니다
개발자는 Git 저장소를 검토하지만 실제 앱은 npm 패키지나 CDN 번들을 받아 씁니다.
- 영향을 받은 기간은 게시 시각과 다를 수 있습니다
악성 패키지가 저장소에 올라 있던 시간, CDN이 캐시에 담아 둔 시간, 사용자가 실제로 페이지를 열고 서명한 시간은 모두 다릅니다.
- 프런트엔드 사고와 지갑 장치 침해는 다른 일입니다
Connect Kit 악성 코드는 앱 사용자에게 자산을 빼내는 거래에 서명하게 했지만, Ledger는 하드웨어 무결성과 Ledger Live에는 영향이 없었다고 밝혔습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
영향을 받은 기간은 게시 시각과 다를 수 있습니다
악성 패키지가 저장소에 올라 있던 시간, CDN이 캐시에 담아 둔 시간, 사용자가 실제로 페이지를 열고 서명한 시간은 모두 다릅니다. Ledger 보고서는 악성 파일에 약 5시간 접근할 수 있었지만 자산 탈취가 가능했던 시간은 2시간 미만으로 추정했습니다. 또 수정 뒤에도 CDN 캐시가 퍼지는 동안 파일이 잠시 남아 있었다고 밝혔습니다.
버전을 고정해 정적 번들로 묶은 앱이라면, 악성 버전을 설치하거나 다시 빌드하지 않은 한 영향이 없을 수 있습니다. 반면 늘 최신 버전을 불러오는 로더는 앱을 다시 배포하지 않아도 오염됩니다. 잠금 파일과 무결성 해시, 빌드 산출물, CDN 요청, 서비스 워커 캐시를 확인하세요.
| 단계 | 증거 | 판정 |
|---|---|---|
| 게시 | 버전·게시자·시간 | 악성 버전 존재 |
| 설치 | 잠금 파일·빌드 로그 | 빌드 유입 |
| 번들 | 산출물 해시 | 앱 포함 |
| 동적 로드 | CDN 응답·캐시 | 브라우저 전달 |
| 피해 | 서명·온체인 거래 | 자산·권한 이동 |
프런트엔드 사고와 지갑 장치 침해는 다른 일입니다
Connect Kit 악성 코드는 앱 사용자에게 자산을 빼내는 거래에 서명하게 했지만, Ledger는 하드웨어 무결성과 Ledger Live에는 영향이 없었다고 밝혔습니다. 하드웨어 화면에 뜬 서명 내용과 브라우저가 보낸 요청을 맞춰 봤다면 위험을 줄일 수 있었습니다. 제품 이름 전체가 해킹당했다고 쓰면 안 됩니다.
내용을 확인하지 않고 악성 요청에 서명하면 개인키가 새지 않아도 자산이 빠져나갑니다. 시드 유출, 토큰 사용 승인, 직접 송금, 퍼밋 서명을 나눠 보고 거래마다 맞는 대응을 안내합니다.
패치 버전만 올리고 끝내서는 안 됩니다
악성 버전을 사용 중단으로 표시하고 안전한 버전을 낸 뒤에는, 이 패키지를 쓰는 앱들이 다시 빌드·배포했는지 확인합니다. 실행 중에 불러오는 구조라면 CDN 캐시 비우기와 만료도 필요합니다. 열린 탭이나 서비스 워커가 옛 코드를 붙잡고 있을 수 있으니 새로고침, 브라우저 종료 같은 조치도 구체적으로 알려 줍니다.
재발을 막으려면 게시 계정과 API 토큰 교체, 퇴사자 권한 회수, 2FA와 최소 권한, 다중 승인, 빌드에서 저장소까지 이어지는 경로 통제가 필요합니다. Ledger는 npm 팀 권한을 읽기 전용으로 돌리고, 게시용 비밀값을 교체하며, 빌드 파이프라인과 배포 채널 관리를 강화하겠다고 밝혔습니다.
- 악성 패키지·버전과 게시·삭제 시각을 기록합니다
- 잠금 파일·빌드·CDN에서 실제로 불러왔는지 확인합니다
- 앱·지갑·계약·서명에 미친 영향을 나눕니다
- 패치·캐시 비우기·재배포 진행을 추적합니다
- 게시 권한·토큰·퇴사자·출처 증명 관리를 손봅니다
출처 증명은 어디서 왔는지 보여 줄 뿐 안전을 보증하지 않습니다
npm의 출처 증명(provenance)은 패키지가 어떤 소스와 빌드 지시로 만들어졌는지 검증할 수 있게 이어 줍니다. 신뢰 게시(trusted publishing)는 OIDC 기반의 짧은 자격증명을 써서 오래 살아 있는 게시 토큰의 위험을 줄이고, 출처 증명을 자동으로 만들어 줍니다.
npm 문서도 출처 증명이 악성 코드가 없다는 보증은 아니라고 분명히 적고 있습니다. 믿을 만한 빌드 절차가 악성 커밋을 빌드하거나 의존성이 오염되면, 서명까지 붙은 악성 패키지가 나올 수 있습니다. 코드 리뷰, 브랜치 보호, 의존성 버전 고정과 함께 써야 합니다.
노출을 판정한 기준을 공개합니다
영향을 받을 수 있었던 수천 개 앱, 실제로 악성 번들을 불러온 앱 수, 자산을 빼내는 거래에 서명한 사용자 수는 나눠서 씁니다. 추정치라면 어느 범위의 로그를 봤고 캐시를 어떻게 가정했는지 밝힙니다. 의존성 목록에 이름이 있었다는 이유만으로 피해를 단정하지 않습니다.
이용자가 할 일은 영향 기간 안에 그 사이트를 열었는지, 그리고 서명했는지에 따라 달라집니다. 접속만 했다면 시드를 옮기라고 하지 않습니다. 악성 승인이나 퍼밋에 서명했다면 체인별 권한과 자산 이동을 확인합니다.
자주 묻는 질문
악성 npm 버전이 있으면 모든 사용자가 위험한가요?
아닙니다. 앱이 그 버전을 설치해 번들에 넣었는지, 아니면 실행 중에 불러왔는지부터 확인하세요.
개인키가 안 새면 피해가 없나요?
아닙니다. 악성 거래나 사용 승인에 서명하면 자산이 빠져나갈 수 있습니다.
출처 증명 배지가 있으면 안전한가요?
출처와 빌드의 연결을 검증해 줄 뿐, 코드가 무해하다는 보증은 아닙니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
