멀웨어 신고에 11일 — 한 npm 메인테이너가 기록한 깃허브 보안 대응의 현실

신고부터 삭제까지 11일, 그동안 3,000명이 멀웨어를 받았다

월 400만 회 다운로드되는 npm 패키지를 관리하는 한 오픈소스 메인테이너가 작심하고 쓴 글이 올라왔어요. 제목부터 '깃허브 보안팀은 대체 뭘 하나'인데요. 최근 6개월 동안 자기 패키지를 노린 멀웨어 캠페인을 다섯 번 깃허브에 신고하면서 겪은 일을 타임라인으로 낱낱이 공개했거든요. 오픈소스 공급망 보안이 실제로 어떻게 굴러가는지, 아니 어떻게 안 굴러가는지 보여주는 생생한 기록이에요.

다섯 번의 신고, 다섯 번의 실망

첫 번째는 타이포스쿼팅 패키지였어요. 타이포스쿼팅이 뭐냐면, 유명 패키지와 한두 글자만 다른 이름으로 악성 패키지를 등록해서 오타 낸 개발자가 설치하게 만드는 수법이에요. 이 가짜 패키지에는 난독화된 postinstall 스크립트, 그러니까 npm install만 해도 자동으로 실행되면서 개발자의 인증 정보를 훔쳐가는 코드가 들어 있었고요. 공식 멀웨어 신고 폼으로 신고했는데 삭제까지 11일이 걸렸고, 그 사이 약 3,000회 다운로드됐어요. 두 번째는 같은 공격자가 이름만 바꿔 올린 거의 동일한 패키지였는데, 이전 신고 이력까지 첨부했는데도 6일이 걸렸죠.

세 번째가 압권이에요. 자기 저장소를 포크한 뒤 악성 '버그픽스' 커밋을 넣고, 트로이 목마가 심긴 윈도우 바이너리를 릴리스로 올린 건이었는데요. 바이러스토탈에서 70개 엔진 중 42개가 알려진 정보 탈취 악성코드로 판정한 파일이었어요. 그런데 깃허브의 첫 답변은 '포크는 서비스 약관상 허용된다'였대요. 결국 SNS에서 공론화되고 나서야 48시간 만에 내려갔고요. 네 번째는 메인테이너를 사칭한 유사 계정이었고, 다섯 번째 신고는 글 작성 시점 기준 9일째 처리 중이에요. 뼈아픈 대조도 있어요. 세 번째 건의 2차 악성코드를 호스팅하던 CDN 업체에 같은 내용을 신고했더니 4시간 만에 사라졌거든요.

개인의 태만이 아니라 구조의 문제

글쓴이가 강조하는 건 담당자 개인을 욕하자는 게 아니에요. 사적으로 대화해본 깃허브 보안팀 사람들은 좋은 사람들인데 인력이 부족해 허우적대고 있다는 거예요. npm은 주당 40억 회의 다운로드를 처리하는, 사실상 전 세계 자바스크립트 생태계의 수도관이거든요. 깃허브는 Advanced Security라는 보안 제품군으로 큰 매출을 올리는 회사인데 정작 생태계의 멀웨어 신고 큐에는 충분한 인력을 배치하지 않는 것, 이건 윗선의 자원 배분 결정이라는 게 핵심 비판이에요. 그래서 요구 사항도 구체적이에요. 인증 정보 탈취형 멀웨어는 24시간 내 처리하는 SLA(처리 시한 약속), 신고 이력이 검증된 메인테이너를 위한 '신뢰 신고자' 프로그램, 그리고 정기적인 삭제 조치 투명성 보고서요.

업계 맥락에서 보면 낯선 이야기가 아니죠. event-stream 사태부터 ua-parser-js 하이재킹까지 npm 공급망 공격은 이미 연례행사가 됐고, 변종을 자동으로 찍어내는 공격이 늘면서 신고하고 삭제되기를 기다리는 속도전은 갈수록 수비 측에 불리해지고 있어요. 플랫폼의 사후 대응이 느리니 Socket이나 npq처럼 설치 시점에 패키지의 수상한 행동(postinstall 존재, 네트워크 접근, 난독화된 코드)을 미리 검사해주는 서드파티 도구들이 그 빈자리를 채우며 성장하는 상황이고요.

한국 개발자가 오늘 할 수 있는 것

플랫폼이 바뀌길 기다리는 동안 우리가 할 수 있는 방어책도 글쓴이가 정리해줬는데, 전부 실용적이에요. 패키지를 쓰는 입장에서는 lockfile로 의존성 버전을 고정하고, npm 설정에서 ignore-scripts를 켜 postinstall 자동 실행을 기본 차단하고(꼭 필요한 패키지만 예외 처리), 새 의존성을 추가할 때 Socket 같은 도구로 한 번 걸러보는 것. 패키지를 배포하는 입장이라면 npm provenance(패키지가 어느 저장소의 어느 커밋에서 빌드됐는지 증명하는 기능)를 켜고, 자기 패키지 이름의 뻔한 오타 변형들을 미리 선점 등록해두는 것까지요. 회사라면 사내 npm 프록시에서 새로 등장한 패키지를 며칠 검역하고 들여보내는 정책도 고려할 만해요.

한줄 정리: 세계 최대 코드 플랫폼의 멀웨어 대응이 SNS 공론화보다 느린 게 현실이라면, 내 프로젝트의 공급망 방어는 내가 직접 챙겨야 해요. 여러분 팀은 의존성 보안을 어떻게 관리하고 계세요? postinstall 차단이나 패키지 검역을 실무에 적용해본 경험이 있다면 공유해주세요.