1. 예상치 못한 피해 발견
개발자들은 매일 다양한 도구를 사용하며 높은 신뢰를 부여합니다. 그러나 이 신뢰가 오히려 보안의 사각지대가 될 수 있습니다.
이번 사례는 VS Code 확장 프로그램 Nx Console을 통해 발생한 공급망 공격으로,
안전하다고 여겨졌던 개발 도구가 어떻게 보안 위협의 통로로 변할 수 있는지를 보여줍니다.
Nx Console은 Nx 기반 프로젝트를 효율적으로 관리하도록 돕는 인기 확장 프로그램이었습니다.
하지만 2024년 말경, 이 확장이 악의적으로 변조되어 배포된 사실이 발견되었습니다.
공격자는 확장 코드 내부에 악성 스크립트를 삽입하여, 사용자의 인증 정보와 환경 변수를 탈취하는 기능을 추가했습니다.
문제는 이 악성 버전이 정상 업데이트처럼 위장해 자동 설치되었다는 점입니다.
피해자는 IDE 내에서 정상적으로 프로젝트를 관리하던 중, GitHub Personal Access Token(PAT)이 외부 서버로 전송된 정황을 발견했습니다.
일부 사용자들은 원격 저장소에 자신도 모르게 커밋이 발생하거나, 알 수 없는 리포지토리가 생성되는 피해를 입었습니다.
이 사건은 개발 생태계에서 “신뢰된 소프트웨어”라는 전제를 다시 생각하게 만든 충격적인 사례였습니다.
사건 발생 직후, 보안 커뮤니티에서는 해당 악성 버전의 확장 프로그램이 VS Code 마켓플레이스에 짧은 시간 등록되어 있었다는 점을 확인했습니다.
다행히도 마이크로소프트 측에서 빠르게 조치를 취했지만, 이미 다운로드한 사용자는 수동 점검과 토큰 폐기를 진행해야 했습니다.
2. 즉각적인 대응 단계
공급망 공격이 발생한 뒤 가장 중요한 것은 신속하고 체계적인 대응입니다.
피해를 최소화하기 위해 다음의 세 가지 조치가 즉시 시행되었습니다.
첫째, GitHub Personal Access Token 전면 폐기입니다.
PAT은 원격 리포지토리 접근에 필요한 중요한 인증 수단이므로, 유출 시 즉각 폐기해야 합니다.
피해자들은 모든 저장소에서 기존 토큰을 삭제하고 새로운 토큰으로 재발급 받았습니다.
둘째, 환경 변수 점검 및 재설정입니다.
공격 코드가 process.env 값을 수집하는 형태로 작동했기 때문에,
로컬 및 CI/CD 환경의 민감한 키(API 키, 비밀번호, 인증서 등)를 전면 검토해야 했습니다.
이 과정에서 누락된 비밀 키나 토큰을 교체하고 접근 권한을 재조정하는 절차가 뒤따랐습니다.
셋째, 시스템 전체 감염 여부 점검입니다.
일부 확장 프로그램이 브라우저 실행과 비슷한 샌드박스 구조를 이용해 외부 요청을 수행하기 때문에,
OS 수준의 네트워크 로그와 DNS 요청 내역을 추적했습니다.
이 과정을 통해 백도어나 악성 프로세스가 남아 있지 않은지 확인했습니다.
위 세 단계의 대응으로 2차 피해를 차단했으며, 이후 IDE와 확장 프로그램의 자동 업데이트를 중지하고
신뢰할 수 있는 버전만 수동 설치하도록 조치했습니다.
3. 공급망 공격의 원인 분석
공격의 핵심 원인은 소프트웨어 공급망의 신뢰 체계 붕괴에 있었습니다.
개발자들이 매일 사용하는 패키지 매니저와 IDE 확장은 서명 검증 절차가 미비한 경우가 많습니다.
Nx Console의 경우에도 공식 리포지토리에 의존하지 않고, npm 패키지를 중간 경로로 받아오는 구조였습니다.
이를 악용해 공격자는 기존 배포 채널에 악성 코드를 삽입한 뒤,
정상 업데이트로 위장하여 배포했습니다.
패키지 관리자는 이러한 변조를 즉시 감지하지 못했고,
결과적으로 개발자의 로컬 환경이 공격자에게 노출되었습니다.
또한, IDE 확장의 접근 권한 범위가 광범위했다는 점도 문제였습니다.
Nx Console은 프로젝트 설정, 파일 시스템, Git CLI 등 다양한 리소스에 접근할 수 있었습니다.
공격자는 이 권한을 이용해 토큰, 프로젝트 구조, 심지어 SSH 설정 파일까지 열람할 수 있었습니다.
이러한 공격 방식은 단순한 코드 주입이 아니라, 개발 도구를 통한 지속적 위협(Advanced Persistent Threat, APT)의 형태로 발전하고 있음을 보여줍니다.
4. 범인 추적과 교훈
범인을 특정하기 위한 과정은 복잡했습니다. 초기에는 npm 패키지 감염 가능성, 글로벌 캐시 오염, 로컬 빌드 스크립트 변조 등 여러 가설이 제시되었습니다.
그러나 조사 결과, IDE 확장 프로그램이 가장 유력한 원인으로 좁혀졌습니다.
로그를 분석한 결과, 보안 사고가 발생한 시간대에 Nx Console이 활성화되어 있었고,
이때 외부로 비정상적인 HTTPS 요청이 전송된 흔적이 발견되었습니다.
요청 도메인은 러시아 소재 서버로 확인되었으며, 이 서버는 이후 빠르게 폐쇄되었습니다.
결정적인 단서는 해당 확장이 자동 실행 스크립트를 통해 npm install 명령을 호출한다는 점이었습니다.
이 과정에서 별도의 악성 모듈이 설치되며, 이를 통해 시스템이 추가 감염될 수 있었습니다.
결국 Nx Console 확장이 공급망 공격의 매개체로 사용되었음이 확인되었습니다.
이 사건을 통해 얻은 교훈은 명확합니다.
개발 도구라 하더라도, 보안 검증이 충분하지 않으면 공격의 출발점이 될 수 있습니다.
IDE 확장은 반드시 공식 검증을 거친 버전만 설치하고, 출처가 불분명한 확장 기능은 피해야 합니다.
5. 향후 보안 대응 전략
이번 사건 이후 보안 팀은 IDE 및 개발 환경 전반에 대한 보안 체계를 재정비했습니다.
첫째, 모든 확장 프로그램에 대해 서명 검증 절차를 추가했습니다.
코드 해시를 비교하고, 공식 리포지토리 외의 소스는 자동 설치되지 않도록 차단했습니다.
둘째, CI/CD 파이프라인 보안 강화입니다.
환경 변수 관리 시스템을 HashiCorp Vault로 이전하여, 토큰이나 인증키가 평문으로 노출되지 않게 했습니다.
또한 배포 자동화 과정에서 서명되지 않은 패키지는 자동으로 거부되도록 정책을 설정했습니다.
셋째, 보안 교육 및 모의 훈련입니다.
개발자들에게 공급망 공격 시나리오를 교육하고, 가상의 악성 확장을 설치하는 실습을 통해
위험 인식을 강화했습니다.
마지막으로, 보안 모니터링 도구를 통해 IDE의 네트워크 요청을 실시간으로 감시하고,
외부로의 비정상 트래픽을 즉시 차단할 수 있도록 구성했습니다.
결론: 신뢰는 검증을 통해 확보된다
Nx Console 공급망 공격 사례는 개발 생태계에서 신뢰가 얼마나 취약한 기반 위에 놓여 있는지를 보여줍니다.
편리함을 위해 도입한 도구가 역설적으로 가장 위험한 보안 취약점이 될 수 있음을 확인했습니다.
이번 사건을 계기로, 개발자와 조직 모두 “신뢰는 검증을 통해서만 확보된다”는 원칙을 실천해야 합니다.
보안은 개발의 마지막 단계가 아니라, 시작점에서부터 고려되어야 하는 기본 조건입니다.
지속적인 모니터링, 정기 점검, 그리고 개인의 보안 습관이 모여 공급망 보안을 완성합니다.
.png)
