VSCode 확장 하나로 3,800개 저장소가 털렸다 — 'GlassWorm' 사건이 알려주는 공급망 보안의 현실

무슨 일이 일어났나

GitHub가 공식적으로 확인한 사건이에요. 악성 VSCode 확장 프로그램 하나를 통해 약 3,800개 저장소가 침해당했다고요. 이번 캠페인은 보안업계에서 'GlassWorm' 또는 유사한 이름으로 추적 중인데, 특이한 건 공격자가 단순히 악성코드 파일 하나를 심은 게 아니라 개발자들이 매일 쓰는 확장 마켓플레이스를 신뢰의 통로로 이용했다는 점이에요.

왜 이게 중요하냐면, 우리가 npm install이든 pip install이든, VSCode 확장 설치든 할 때 사실상 '이건 안전하겠지'라는 신뢰 위에서 움직이거든요. 마켓플레이스에 올라와 있고 별점도 있고 다운로드 수도 있으니까. 그런데 그 신뢰의 사다리가 한 칸씩 무너지면, 결국 우리 개발 PC와 그 PC가 접근할 수 있는 모든 자격증명, 그리고 그 자격증명으로 닿을 수 있는 모든 저장소까지 다 위험해져요. 그게 이번 사건이 실제로 벌어진 시나리오예요.

공격은 어떻게 이뤄졌나

공격자는 인기 있는 확장 프로그램을 모방하거나, 합법적인 개발자의 계정을 탈취해서 악성 업데이트를 푸시하는 방식을 썼어요. 이게 무서운 게, 합법적인 확장이 어느 날 업데이트되면서 악성 코드가 들어오는 형태라 사용자가 알아채기 어려워요. "어, 내가 설치한 그 확장은 멀쩡한 거였는데?"라고 생각하는 사이에 이미 코드가 실행되고 있는 거죠.

악성 코드가 실행되면 가장 먼저 노리는 게 자격증명이에요. ~/.gitconfig에 저장된 GitHub 토큰, npm 토큰, AWS 키, SSH 키, 그리고 OS 키체인에 저장된 토큰들까지요. VSCode 확장은 보통 사용자 권한으로 돌아가니까 사용자가 접근 가능한 거의 모든 파일에 접근할 수 있어요. 토큰을 빼내면 그걸로 공격자가 GitHub API를 직접 호출해서 다른 저장소에 악성 커밋을 푸시하거나, 비공개 저장소 코드를 그대로 긁어가요. 한 개발자가 회사 코드와 개인 코드 양쪽에 접근 가능했다면, 회사 IP까지 같이 털리는 거예요.

특히 이번 캠페인의 무서운 점은 자기 복제(worm-like) 동작이에요. 침해당한 저장소나 패키지를 통해 다른 개발자의 환경으로 다시 퍼져나가는 구조라서, 3,800개라는 숫자도 끝이 아닐 가능성이 커요. 누군가 침해된 저장소에서 코드를 받아 빌드하는 순간 또 한 명이 감염되는 식이에요.

비슷한 사건들이 계속 늘고 있어요

공급망 공격은 이제 일회성 사건이 아니에요. 작년 XZ Utils 백도어 사건은 리눅스 압축 라이브러리에 2년간 공들여 위장한 메인테이너가 백도어를 심으려다 막판에 발각된 케이스고요, Polyfill.io 공격은 수십만 개 웹사이트가 쓰던 CDN 스크립트가 악성으로 바뀐 사건이었어요. npm에서는 거의 매달 typosquatting(이름 비슷하게 짓기) 패키지나 의존성 가로채기 사건이 보고되고 있고요.

공통점이 뭐냐면, 공격 대상이 최종 사용자가 아니라 개발자라는 거예요. 개발자 한 명을 뚫으면 그 사람이 빌드하고 배포하는 모든 시스템이 같이 뚫리니까요. 비용 대비 효율이 엄청나게 좋은 거죠. 그래서 국가 단위 위협 그룹부터 일반 사이버 범죄 조직까지 모두 이 분야에 인력을 투입하고 있어요.

VSCode 확장 마켓플레이스 자체의 보안 모델도 도마에 올랐어요. npm처럼 자동 검사가 있긴 하지만, 확장 코드는 사실상 임의의 Node.js 코드를 사용자 권한으로 실행할 수 있어요. 권한 분리가 거의 없어서 한 번 설치하면 무엇이든 할 수 있어요. JetBrains는 좀 더 엄격한 플러그인 모델을 갖고 있고, 브라우저 확장은 권한 매니페스트가 있지만, VSCode는 상대적으로 자유로운 편이에요. 마이크로소프트도 이번 사건 이후로 정책 강화 얘기가 나오고 있어요.

우리는 뭘 해야 할까

한국 개발자 입장에서 당장 점검할 게 몇 가지 있어요. 첫째, 설치된 VSCode 확장 목록을 한번 훑어보세요. 거의 안 쓰는데 그냥 설치돼 있는 확장이 있다면 지우는 게 좋아요. 공격 표면을 줄이는 가장 쉬운 방법이에요. 확장 게시자(publisher) 이름이 공식 회사인지, 다운로드 수가 충분히 많은지도 한번 더 확인해 보세요.

둘째, GitHub 개인 액세스 토큰을 점검하세요. 만료일 없는 classic token을 쓰고 있다면 지금이라도 fine-grained PAT로 바꾸고, 범위(scope)도 꼭 필요한 것만 부여하세요. SSH 키 passphrase도 설정해 두고요. 1Password나 Bitwarden 같은 시크릿 매니저로 토큰을 관리하는 것도 좋아요.

셋째, 회사 차원에서는 개발 환경 격리를 진지하게 고민할 때예요. Dev Container, Codespaces, 가상머신, 혹은 격리된 빌드 환경 같은 거요. 개인 노트북에서 회사 코드를 직접 빌드하던 시대는 이제 위험 부담이 너무 커요. 최소한 회사 토큰과 개인 토큰을 다른 머신에서 다루는 정도는 분리해 두는 게 좋아요.

넷째, 의존성 감사 도구를 CI에 넣으세요. npm audit, pip-audit, GitHub Dependabot, Socket.dev, Snyk 같은 도구들이 알려진 악성 패키지를 잡아줘요. 100%는 아니지만, 첫 방어선이 되긴 해요.