"우리 회사는 괜찮겠지"라고 생각하시나요?
이미 해킹 당하고 있다는 사실조차 모를 수 있습니다!
2026년 3월 31일, 전 세계 1,700만 개 이상의 프로젝트가 의존하는 핵심 라이브러리 Axios가 공격당했습니다. 불과 2시간 54분 만에 30만 개 시스템의 자격증명이 탈취되었습니다.
오픈소스 생태계를 뒤흔든 이 사건의 전말, 우리를 갈등에 빠뜨리는 보안 업데이트의 딜레마,
그리고 지금 당.장. 취해야 할 조치들을 정리합니다.
1. 치밀하게 계획된 공격과 긴박했던 수습 과정
이번 공격은 고도의 기술적 취약점이 아닌, 인간의 심리를 먼저 파고든 뒤 보안 시스템의 맹점을 노리는 방식으로 진행되었습니다.
1. 신뢰 구축 북한 해커 그룹은 'Mercor'라는 기술 스타트업으로 위장해 Axios 메인테이너 Jason Saayman에게 수 주간 접근하며 신뢰를 쌓았습니다. 이후 화상 미팅 도중 가짜 MS Teams 업데이트 설치를 유도했고, 설치 순간 브라우저의 세션 쿠키가 복제되어 2단계 인증(2FA)마저 무력화되었습니다. 이로써 npm과 GitHub 계정 권한이 탈취되었습니다.
2. 신뢰 위장 포석 해커는 악성 코드를 배포하기에 앞서, npm에 plain-crypto-js@4.2.0을 게시했습니다. 이 버전은 악성 코드가 없는 '클린' 패키지로, 보안 솔루션들이 이를 안전한 패키지로 학습하도록 유도하는 치밀한 사전 작업이었습니다.
3. 보이지 않는 침입 사전 포석을 완료한 뒤, 해커는 설치 시 자동 실행되는 악성 스크립트를 심은 plain-crypto-js@4.2.1을 게시했습니다. 이어 탈취한 계정으로 Axios 본체 코드는 그대로 두고 의존성 목록에만 해당 악성 패키지를 조용히 추가해 배포했습니다.
공급망 공격은 다음 세 경로로 확산되었습니다.
•
자동화된 CI/CD 파이프라인: 리소스 절약을 위해 야간에 자동으로 빌드와 테스트를 실행하는 파이프라인이 최신 악성 패키지를 스스로 끌어들였습니다.
•
자동 의존성 업데이트: CVE 취약점 대응을 위해 패키지를 항상 최신 상태로 유지하도록 설정한 기업들은, 최신 버전을 가장한 악성 패키지를 그대로 설치하게 되었습니다.
•
데스크톱 앱 자동 업데이트: VS Code 플러그인처럼 실행 시 의존 패키지를 자동으로 업데이트하는 환경에서는, 앱을 여는 순간 개발자 워크스테이션에 악성 패키지가 설치되었습니다.
4. 수습 과정 공격 직후 보안 업계의 긴박한 대응이 이어졌습니다.
•
Sonatype: AI 인텔리전스가 배포 이상 징후를 감지해 '잠재 위협' 태그를 달았고, 연구자의 수동 분석을 통해 악성 여부가 확정되었습니다. 공격 발생 43분 만에 axios@1.14.1을 공식 악성 패키지로 등록·격리했으며, 그 43분 동안에도 해당 패키지를 의심 패키지로 분류해 다운로드를 원천 차단했습니다.
•
보안 연구자들: Axios 커뮤니티에 이슈를 등록했지만, 해커가 관리자 권한으로 이슈를 계속 삭제했습니다. 이에 npm과 X(구 트위터) 등 외부 채널을 통해 상황을 알린 연구자들 덕분에 npm의 공식 대응이 가능했습니다.
•
npm: 공격 발생 2시간 54분 만에 모든 악성 패키지를 삭제하고 탈취된 Saayman의 자격증명을 전부 만료시켜 추가 공격을 차단했습니다. 터미널에 붉은 경고문을 출력해 모든 사용자에게 즉각적인 자격증명 폐기와 재발급을 촉구했으며, 재발 방지를 위해 패키지 배포 시 2차 인증 의무화 및 주요 패키지에 디지털 서명(Sigstore) 검증을 도입했습니다.
2. 보안 담당자의 딜레마: '빠른 패치' vs '지연 업데이트'
이번 사태는 보안 업계에 뼈아픈 역설을 남겼습니다.
"취약점에 대응하기 위해 빠르게 업데이트해야 하는가, 아니면 공급망 공격을 피하기 위해 업데이트를 미뤄야 하는가."
'빠른 업데이트'의 함정 기존 보안 관행은 알려진 취약점(CVE)에 대응하기 위해 의존성을 항상 최신 상태로 유지하는 것이었습니다. 그러나 이번 공격에서 이 모범 사례는 오히려 독이 되었습니다. 자동 업데이트를 설정해 둔 CI/CD 파이프라인들이 밤사이 앞다투어 악성 버전을 스스로 끌어들였고, 악성 버전 게시 후 단 89초 만에 최초 감염이 발생했습니다.
'지연 업데이트'의 필요성 일반적인 취약점은 패치가 공개된 직후 해커와의 속도전이 펼쳐지지만, 공급망 공격은 해커가 악성 코드를 담은 무기를 '직접 주입'해 유포하는 방식입니다. 따라서 악성 패키지가 확산되는 즉시 자동화 파이프라인을 중단하고 업데이트를 잠시 멈춰야 피해를 막을 수 있습니다. 그러나 업데이트를 무작정 지연하면 기존의 치명적인 취약점에 시스템이 무방비로 노출되는 모순에 빠지게 됩니다.
3. 해커들의 진짜 표적: 당신의 마스터키
해커들은 더 이상 운영 서버를 정면으로 뚫으려 하지 않습니다. 그들의 진짜 표적은 워크스테이션과 CI/CD 파이프라인에 저장된 자격증명, 즉 npm 토큰, SSH 키, 클라우드 접근 키입니다.
자격증명 탈취가 위험한 이유는 단 하나입니다. 프로덕션으로 이어지는 열쇠이기 때문입니다.
"개발자 수준의 자격증명 탈취는 프로덕션 에어갭(air-gap)을 논리적으로 우회합니다. 로컬 워크스테이션 감염이 클라우드 컨트롤 플레인 침해로 직결됩니다." — Vectra AI
이 마스터키를 손에 쥔 해커는 '정상 직원'의 신분으로 내부망에 로그인합니다. EDR이나 방화벽은 경보를 울리지 않습니다. 피해 기업이 해킹 사실을 인지하기까지 평균 194일이 걸리며, 그 긴 잠복 기간 동안 고객 데이터와 핵심 정보는 조용히 빠져나갑니다.
4. 지금 내가 당.장 해야 할 5가지 STEP!
시스템이 조용하다고 해서 안전한 것이 아닙니다. 해커가 문을 부수지 않았기 때문에 조용한 것입니다.
STEP 1 : 즉각적인 자격증명 갱신
모든 권한이 유출되었다고 가정하고, AWS·GitHub 토큰, SSH 키 등
보유한 모든 자격증명을 즉시 재발급하세요.
STEP 2 : 레포지토리 방화벽 구축
공급망 공격은 패키지가 설치되는 순간 이미 끝납니다. Sonatype이나 Veracode 같은
레포지토리 방화벽을 도입해 악성 패키지가 내부망에 들어오기 전에 차단하세요.
STEP 3 : SLSA 프레임워크 적용
글로벌 보안 표준인 SLSA를 도입해 빌드부터 배포까지 모든 단계를 검증 가능한 구조로 전환하세요.
STEP 4 : 보안 교육 강화
Saayman은 보안 관행을 지키지 않아서 당한 게 아닙니다.
사회공학적 공격은 원칙을 지키는 사람도 당합니다.
공급망 공격의 개념조차 모르는 개발자들은 더욱 취약합니다.
보안의 가장 약한 고리는 결국 사람!!입니다.
STEP 5 : 제로 트러스트 도입
정상 계정이더라도 이상 행동 패턴이 감지되면
즉시 차단하는 행위 기반 제로 트러스트 체계를 구축하세요.
마무리
소프트웨어 공급망의 신뢰가 무너진 지금, 당신의 마스터키는 안전한가요?
이 글을 읽은 직후, 자격증명 관리 페이지를 여십시오. 행동하지 않는 보안은 보안이 아닙니다!
참고 자료
현지일 프로
(AI 기술로 오픈소스를 안전하게 사용할 수 있는 방법에 대해서 고민하는 개발자 입니다. )
)