새벽에 배포 파이프라인이 자동으로 돌아간다. 개발자는 npm install 한 줄을 믿고 잠자리에 든다. 패키지 뒤에 서명이 붙어 있고, 배포 주체가 깃허브 액션으로 자동 검증됐다는 사실이 그 믿음의 근거였다. 그런데 최근 벌어진 npm 공급망 공격은 이 믿음의 근거 자체를 무기로 바꿔버렸다.
공격 이름은 GHAPPIER. 2026년 9월 보안업체 클라우드섹(CloudSEK)이 처음 보고했다. 필자가 보기엔 이번 사건이 무서운 지점은 코드 품질이 아니라, 공격자가 노린 대상이 ‘개발자의 부주의’가 아니라 ‘신뢰를 자동으로 부여하는 시스템’ 그 자체였다는 데 있다.
npm 공급망 공격, 이번엔 무엇이 달랐나
npm은 몇 해 전부터 ‘트러스티드 퍼블리싱(Trusted Publishing)’이라는 기능을 밀어왔다. 개발자가 매번 발급하는 액세스 토큰 대신, 깃허브 액션 워크플로우가 자동으로 서명하고 배포하는 방식이다. 토큰 유출 위험을 줄이자는 취지였다.
GHAPPIER는 바로 이 워크플로우를 장악했다. 공격자는 65개에 달하는 깃허브 저장소와 22개 계정을 확보한 뒤, 정상적인 트러스티드 퍼블리싱 절차를 그대로 통과시켜 악성 로더를 심었다. 검증 절차 자체는 정직하게 작동했다는 점이 역설적이다.
기존 공급망 공격과 무엇이 다른가
이전까지 알려진 npm 공급망 공격은 대개 타이포스쿼팅이나 유출된 개인 토큰을 악용하는 방식이었다. 개발자 개인의 실수를 파고드는 구조였다. 반면 GHAPPIER는 자동화된 신뢰 체계 안쪽에서 시작됐다는 점에서 성격이 다르다.
| 구분 | 기존 방식 (토큰 탈취형) | GHAPPIER (신뢰 체계 악용형) |
|---|---|---|
| 침투 경로 | 유출된 개인 액세스 토큰 | 트러스티드 퍼블리싱 워크플로우 |
| 탐지 난이도 | 비정상 로그인 흔적으로 포착 가능 | 정상 배포 절차처럼 보여 탐지 지연 |
| 확산 범위 | 개별 패키지 단위 | 깃허브 저장소 65개·계정 22개 연쇄 |
| 근본 문제 | 개인 보안 습관 | 자동화 신뢰 인프라 설계 |
표로 정리하고 나니 이 사건의 무게가 더 분명해진다. 개인 습관을 고치는 문제가 아니라, 생태계가 자동화를 신뢰로 착각한 설계의 문제라는 점이다. 필자 개인적으로는 이 구분이 앞으로 오픈소스 보안 논의의 기준선이 될 것으로 본다.
npm과 오픈소스 생태계의 전략적 대응
깃허브와 npm 운영진은 사건 확인 직후 관련 패키지를 격리하고, 트러스티드 퍼블리싱 워크플로우에 대한 추가 검증 절차를 예고했다. 다만 아직 공식적으로 재발 방지책의 세부 내용을 전부 공개하지는 않았다.
기업 보안팀 쪽 반응도 빨라졌다. 한 보안 매체 분석에 따르면 다수 기업이 CI/CD 파이프라인에서 신규 패키지 버전을 즉시 반영하지 않고, 일정 시간 지연 후 반영하는 ‘쿨다운’ 정책을 재점검하는 중이라는 보도가 나온다. 이런 대응은 다음과 같이 요약된다.
- 신규 패키지 버전 자동 반영 지연(쿨다운) 정책 강화
- 트러스티드 퍼블리싱 워크플로우 권한 범위 재점검
- 의존성 스캐닝 도구를 통한 이상 행위 탐지 강화
이런 움직임은 방향은 맞지만 속도는 느리다는 게 필자의 판단이다. 자동화가 빨라질수록 검증 체계도 같은 속도로 빨라져야 하는데, 현재는 사고가 터진 뒤에야 정책이 따라가는 구조다.
IT-SUE의 시각
이번 npm 공급망 공격 사건은 개발 생태계가 ‘자동화된 것은 안전하다’는 전제를 얼마나 쉽게 만들어왔는지 보여준다. 개인적으로는 이 전제가 앞으로 AI 코딩 에이전트 시대에는 더 위험해질 것으로 본다. 사람이 검토하는 단계가 줄어들수록, 신뢰 체계 자체를 노리는 공격의 파급력은 커질 수밖에 없다.
결국 관건은 검증 주체를 다시 사람 쪽으로 일부 되돌리느냐, 아니면 자동화 신뢰 체계를 더 정교하게 재설계하느냐다. 관련해 IT-SUE가 앞서 다룬 섀도우 AI란 — 통제 밖에서 자라는 기업의 위험 글에서도 비슷한 구조의 위험을 짚은 바 있다. 공급망이든 AI 도입이든, 통제되지 않은 자동화가 가장 먼저 노려진다는 점은 동일하다.
답글 남기기