axios 공급망 공격 이슈의 시작과 끝

axios 공급망 공격, 무엇이었나

axios 공급망 공격은 전 세계에서 아주 많이 쓰이는 JavaScript 요청 도구인 Axios가 노려진 사건입니다. 공격자는 Axios를 직접 뜯어고치지 않고, npm에서 이 도구를 올리고 관리하던 사람의 계정을 먼저 훔쳤어요. 그다음 이 계정으로 정상 버전처럼 보이는 새 패키지를 올렸는데, 여기 안에 plain-crypto-js라는 가짜 패키지를 살짝 끼워 넣었습니다. 이 의존성은 설치할 때 한 번만 돌고 사라지는 설치 뒤 실행 코드를 가지고 있었고, 그 순간에 원격 접근 악성코드를 내려받아 깔도록 짜여 있었어요. 덕분에 사용자 눈에는 그냥 axios 업데이트처럼 보였지만, 실제로는 아주 짧은 시간 열린 뒤쪽 문이 돼 버렸습니다.

공격 방식의 핵심과 피해 범위

이번 axios 공급망 공격이 특히 무서웠던 이유는 소스 코드 한 줄 안 건드리고도 성공했다는 점이에요. 평소 눈여겨보지 않던 의존성 하나와 postinstall 스크립트만으로 길을 뚫은 셈이죠. 공격자는 먼저 깨끗한 plain-crypto-js를 미리 올려 두고, 평판을 쌓은 뒤에 악성 버전을 짧은 시간 끼워 넣었습니다. 이 덕분에 자동 검사 도구 일부는 이상 징후를 늦게 알아챘어요. 그 사이에 Axios의 엄청난 인기 때문에 여러 빌드 시스템이 악성 버전을 가져갔고, macOS와 Windows, Linux를 가리지 않고 원격 접근 트로이 목마를 설치당할 위험을 안게 됐습니다. 다행히 보안 회사가 게시 후 몇 분 안에 이상을 찾아내 npm에서 문제 버전을 내리면서, axios 공급망 공격이 더 오래 이어지지는 않았어요. 그래도 일부 환경에서는 실제로 감염된 장치가 보고됐고, 정확한 피해 규모는 아직 다 드러나지 않았다는 점이 불안 요소로 남아 있습니다.

개발자가 바로 점검해야 할 것들

axios 공급망 공격 이후로 많은 개발자가 자기 환경부터 다시 살펴봤습니다. 당시 특정 시간대에 Axios 1.14.1이나 0.30.4를 설치했는지, 그리고 설치 기록이나 lock 파일에 흔적이 남았는지를 먼저 보는 식이에요. plain-crypto-js가 지금은 안 보이더라도, 그 시간 동안 한 번이라도 설치를 했다면 의심하고 체크하는 편이 안전합니다. 또 한 번 이런 일이 벌어진 뒤로는 의존성 보안 검사 도구를 빌드 과정에 붙이고, npm 패키지에 낯선 설치 뒤 실행 스크립트가 있는지 꼼꼼하게 보는 흐름이 강해졌어요. 팀 안에서는 누가 언제 버전을 올렸는지 기록을 남기고, 계정 보안을 더 세게 묶어 두는 분위기도 퍼졌습니다. 결국 axios 공급망 공격이 한 번 지나간 뒤에야, 많은 사람이 “라이브러리도 결국 남의 컴퓨터에서 온 코드”라는 너무 당연한 사실을 다시 떠올리게 된 셈이에요.

이번 사건을 보면, 짧은 시간에 올라왔다 내려간 패키지 하나가 얼마나 많은 환경을 흔들 수 있는지 알 수 있습니다. 계정 탈취, 가짜 의존성, 설치 뒤 실행 스크립트까지 이어지는 과정이 맞물리면서 axios 공급망 공격이 현실이 됐어요. 저는 이 이야기를 통해 자주 쓰는 도구일수록 설치 순간과 의존성을 더 신중하게 볼 필요가 있다는 점을 다시 떠올리게 되네요.