VSCode 확장 하나로 깃허브 저장소 3,800개가 털렸다 — 당신의 IDE가 다음 표적입니다

개발자라면 하루에도 몇 번씩 VSCode 확장을 설치하실 텐데요. 그 마우스 클릭 한 번이 회사 코드 전체를 통째로 넘기는 스위치가 될 수 있다는 게 이번에 증명됐습니다. 깃허브 내부 저장소 3,800개가 단 한 명의 개발자 노트북에서 시작된 공급망 공격으로 유출됐기 때문입니다.

무슨 일이 벌어졌나

이번 사건은 한마디로 “노트북 한 대로 회사 전체가 뚫린 사건”입니다. 공격자는 합법적으로 보이는 VSCode 확장을 마켓플레이스에 올렸고, 한 개발자가 이걸 설치하면서 모든 게 시작됐습니다.

문제는 그 다음입니다. VSCode 확장은 우리가 생각하는 것보다 훨씬 강력한 권한을 가집니다. 파일 시스템에 접근할 수 있고, 터미널 명령을 실행할 수 있고, 환경 변수를 읽을 수 있습니다. 즉, 개발자가 로컬에 저장해둔 깃허브 PAT(Personal Access Token), SSH 키, .env 파일에 들어 있는 시크릿을 전부 긁어모을 수 있다는 뜻인데요.

결과적으로 공격자는 그 개발자의 신원으로 깃허브에 로그인한 것과 동일한 권한을 손에 넣었고, 접근 가능한 3,800개의 내부 저장소를 통째로 클론해 갔습니다.

왜 IDE가 새로운 표적이 됐을까

지금까지 공급망 공격이라고 하면 보통 npm이나 PyPI 같은 패키지 레지스트리를 떠올렸습니다. 그런데 IDE 확장은 그보다 훨씬 더 매력적인 표적입니다. 이유는 세 가지인데요.

첫째, 심사가 느슨합니다. VSCode 마켓플레이스는 npm처럼 누구나 확장을 올릴 수 있고, 자동화된 정적 분석 외에는 깊이 있는 검증이 거의 없습니다.

둘째, 실행 권한이 광범위합니다. npm 패키지는 빌드 시점이나 런타임에 실행되지만, IDE 확장은 개발자가 코드를 짜는 동안 항상 백그라운드에서 돌아갑니다. 시크릿이 메모리에 떠 있는 그 순간에 옆에서 지켜보고 있는 셈입니다.

셋째, 신뢰의 사슬이 깁니다. 개발자 한 명이 뚫리면, 그 사람이 접근 가능한 모든 저장소가 함께 뚫립니다. 이번 사건처럼 한 명의 노트북에서 3,800개라는 숫자가 나올 수 있는 이유입니다.

방어는 어떻게 해야 하나

보안 업계에서는 이번 사건을 계기로 IDE 확장에 대한 인식이 바뀌어야 한다고 입을 모읍니다. 핵심은 “확장도 코드다”라는 관점입니다.

실무에서 당장 적용할 수 있는 조치는 이렇습니다. 우선 확장은 publisher 평판과 다운로드 수만 보지 말고, GitHub 저장소가 공개돼 있는지, 마지막 업데이트가 언제인지, 요구하는 권한이 합리적인지 확인하셔야 합니다. 그리고 회사 환경이라면 마켓플레이스를 그대로 열어두지 말고, 화이트리스트 기반의 사내 확장 레지스트리를 운영하는 게 안전합니다.

더 근본적으로는 개발자 노트북에 장기 유효 토큰을 절대 두지 않는 게 맞습니다. 깃허브의 fine-grained PAT나 OIDC 기반 단기 토큰을 쓰면, 설령 노트북이 뚫려도 피해 범위를 크게 줄일 수 있습니다.

마무리: 신뢰의 비용

이번 사건이 무서운 건 공격이 정교해서가 아닙니다. 오히려 너무 단순해서입니다. 클릭 한 번, 그게 전부였습니다.

우리가 매일 무심코 설치하는 그 확장 하나하나가 사실은 회사 전체 코드베이스에 대한 백도어가 될 수 있다는 사실, 한 번쯤 진지하게 돌아보실 때입니다. 지금 여러분의 VSCode에 설치된 확장은 몇 개인가요? 그중에 publisher 이름까지 확인하고 설치한 건 몇 개인가요?