공급망 사고는 계약 코드가 직접 뚫리지 않아도 package 게시 계정·빌드·CDN에 악성 코드가 들어가 사용자 서명을 유도할 수 있다. 영향 판단에는 악성 package·version·publish 시각, lockfile과 설치 로그, bundle hash, 런타임 CDN 로드, cache 잔존시간, 실제 서명 거래를 확인해야 한다. 온체인 계약·하드웨어 지갑·웹 프런트 침해 범위를 따로 쓴다.
공식 저장소가 정상이어도 배포물이 오염될 수 있다
개발자는 Git 저장소를 검토하지만 실제 앱은 npm package나 CDN bundle을 가져온다. 게시 token이나 외부 계정이 탈취되면 저장소에 악성 commit이 없어도 새 버전에 코드가 삽입될 수 있다. GitHub는 안 뚫렸다는 설명만으로 이용자 노출을 부정할 수 없다.
Ledger의 2023년 Connect Kit 사고 보고서는 전 직원의 npm 접근이 제거되지 않아 공격자가 1.1.5·1.1.6·1.1.7을 게시했고 runtime loader를 쓰는 DApp이 악성 bundle을 불러왔다고 설명한다. Ledger infrastructure·repository·DApp 자체 접근과 package 배포 경로를 구분했다.
공급망 사고에서는 코드가 어디서 작성됐는지보다 사용자의 브라우저에 어떤 바이트가 언제 도착했는지가 중요하다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 공식 저장소가 정상이어도 배포물이 오염될 수 있다
개발자는 Git 저장소를 검토하지만 실제 앱은 npm package나 CDN bundle을 가져온다 .
- 영향 창은 게시 시각과 다를 수 있다
악성 package가 레지스트리에 있던 시간, CDN이 cache한 시간, 사용자가 실제 페이지를 열고 서명한 시간은 다르다.
- 프런트 사고와 지갑 장치 침해를 나눈다
Connect Kit 악성 코드는 DApp 사용자에게 drain 거래를 서명하게 했지만 Ledger는 hardware integrity와 Ledger Live가 영향받지 않았다고 밝혔다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
영향 창은 게시 시각과 다를 수 있다
악성 package가 레지스트리에 있던 시간, CDN이 cache한 시간, 사용자가 실제 페이지를 열고 서명한 시간은 다르다. Ledger 보고서는 악성 파일이 약 5시간 접근 가능했지만 drain 창은 2시간 미만으로 추정했고 fix 뒤에도 CDN cache 전파 때문에 파일이 잠시 남았다고 밝혔다.
정적 bundle로 version을 고정한 앱은 악성 버전을 설치·재빌드하지 않았다면 영향이 없을 수 있다. runtime latest loader는 앱 재배포 없이 오염될 수 있다. lockfile·integrity hash, artifact, CDN 요청과 service worker cache를 확인한다.
| 단계 | 증거 | 판정 |
|---|---|---|
| 게시 | version·publisher·시간 | 악성 버전 존재 |
| 설치 | lockfile·CI log | 빌드 유입 |
| 번들 | artifact hash | 앱 포함 |
| 동적 로드 | CDN 응답·cache | 브라우저 전달 |
| 피해 | 서명·온체인 거래 | 자산·권한 이동 |
프런트 사고와 지갑 장치 침해를 나눈다
Connect Kit 악성 코드는 DApp 사용자에게 drain 거래를 서명하게 했지만 Ledger는 hardware integrity와 Ledger Live가 영향받지 않았다고 밝혔다. 하드웨어 화면의 clear signing 내용과 브라우저 요청을 대조했다면 위험을 줄일 수 있었다. 제품 이름 전체가 해킹됐다고 쓰지 않는다.
악성 요청에 blind sign하면 개인키가 유출되지 않아도 자산이 이동한다. seed compromise, token approval, 직접 transfer, permit 서명을 구분하고 거래별 대응을 안내한다.
패치 버전만 올리고 끝내면 안 된다
악성 버전을 deprecate하고 안전 버전을 게시한 뒤 downstream 앱이 재빌드·배포됐는지 확인한다. runtime loader면 CDN purge와 cache expiry가 필요하다. 열린 탭·service worker가 옛 코드를 유지할 수 있어 새로고침·브라우저 종료 같은 조치도 구체적으로 안내한다.
게시 계정·API token 회전, 퇴사자 접근 제거, 2FA·최소 권한·다중 승인, build-to-registry 연결이 재발 방지다. Ledger는 npm 팀을 read-only로 바꾸고 publishing secret을 회전하며 pipeline과 배포 채널 통제를 강화하겠다고 밝혔다.
- 악성 package·version·publish와 제거 시각을 기록한다
- lockfile·build·CDN에서 실제 로드를 확인한다
- DApp·지갑·계약·서명 영향을 분리한다
- 패치·cache purge·재배포를 추적한다
- 게시 권한·token·퇴사자·provenance 통제를 개선한다
provenance는 출처를 증명하지만 무해함은 보증하지 않는다
npm provenance는 package가 어느 source와 build instruction에서 만들어졌는지 검증 가능한 연결을 제공한다. trusted publishing은 OIDC 기반 짧은 자격증명으로 장기 publish token 위험을 줄이고 자동 provenance를 만들 수 있다.
npm 문서는 provenance가 malicious code 부재를 보증하지 않는다고 명시한다. 신뢰된 workflow가 악성 commit을 빌드하거나 의존성이 오염되면 서명된 악성 package가 나올 수 있다. code review·branch protection·dependency pinning과 함께 쓴다.
노출 판정 기준을 공개한다
수천 개 DApp 영향 가능성과 실제 악성 bundle을 로드한 앱 수, drain 거래를 서명한 사용자 수를 나눠 쓴다. 추정치는 로그 범위와 cache 가정을 밝힌다. 의존성 목록에 있었다는 사실만으로 피해를 단정하지 않는다.
이용자 행동은 영향 창에 해당 사이트를 열었는지와 서명했는지에 따라 달라진다. 접속만 했다면 seed 이동을 지시하지 않고, 악성 approval·permit을 서명했다면 체인별 권한과 자산 이동을 확인한다.
자주 묻는 질문
악성 npm 버전이 있으면 모든 사용자가 위험한가요?
아니다. 앱이 해당 버전을 설치·번들링 또는 동적 로드했는지 확인한다.
개인키가 안 새면 피해가 없나요?
아니다. 악성 거래나 approval을 서명해 자산이 이동할 수 있다.
provenance badge가 있으면 안전한가요?
출처·빌드 연결을 검증할 뿐 코드 무해함은 보증하지 않는다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
