Date: 2026-05-21 Topic: Security Primary source: Microsoft Security Blog
소프트웨어 공급망 공격은 이제 "어떤 서버가 해킹됐다"는 식의 단순한 사건으로 설명하기 어렵습니다. 이번 Mini Shai-Hulud 캠페인은 개발자가 평소처럼 npm install을 실행하는 순간, 또는 CI/CD 파이프라인이 자동으로 의존성을 설치하는 순간부터 시작됩니다. 문제가 된 것은 Alibaba 계열 데이터 시각화 생태계로 알려진 @antv npm 패키지들입니다. Microsoft는 공격자가 @antv 유지관리자 계정을 탈취해 널리 쓰이는 패키지의 악성 버전을 배포했고, 그 영향이 하위 의존성까지 번졌다고 분석했습니다.
겉으로는 평범한 패키지 업데이트처럼 보이지만, 실제 목적은 코드 실행 그 자체가 아니라 개발 환경 안에 있는 비밀값을 훔치는 데 있었습니다. GitHub 토큰, npm 토큰, AWS 자격 증명, Kubernetes 서비스 계정, Vault 토큰처럼 회사 시스템을 움직이는 열쇠들이 공격 대상이었습니다.
Core Lens
이번 사건은 오픈소스 패키지 하나의 문제가 아니라, 개발자 PC와 빌드 서버가 기업 보안의 핵심 경계가 됐다는 신호입니다.
What Actually Happened
Microsoft에 따르면 공격자는 @antv npm 생태계를 노렸습니다. @antv는 차트와 그래프, 대시보드 구현에 쓰이는 데이터 시각화 패키지 묶음입니다. 이런 패키지는 서비스의 핵심 비즈니스 로직이 아니어서 보안 검토에서 상대적으로 덜 눈에 띄지만, 실제로는 많은 프론트엔드와 내부 관리 도구에 깊숙이 들어갑니다.
공격 흐름은 대략 이렇게 볼 수 있습니다.
- 유지관리자 계정이 탈취되면서 공격자가 패키지를 배포할 권한을 얻었습니다.
- 악성 버전은 설치 과정에서 자동 실행되는 스크립트를 포함했습니다.
- 스크립트는 GitHub Actions 같은 Linux 기반 CI 환경을 특히 의식해 동작했습니다.
- 실행 뒤에는 GitHub, npm, AWS, Vault, Kubernetes 등 여러 곳의 자격 증명을 찾고 외부로 빼내려 했습니다.
- 훔친 토큰이 있으면 또 다른 저장소나 패키지로 공격이 번질 수 있습니다.
Snyk와 Chainguard는 이 공격이 2026년 5월 19일 UTC 기준 짧은 시간 동안 수백 개 패키지 버전을 밀어 넣은 자동화된 배포였다고 설명합니다. 숫자 자체보다 중요한 점은 속도입니다. 사람이 릴리스 노트를 읽고 판단하기 전에, 자동 설치와 자동 빌드가 먼저 움직이는 구조가 공격자에게 유리하게 작동했습니다.
The Security Angle
이번 공격에서 특히 불편한 지점은 "서명과 자동화"를 공격자가 역이용했다는 점입니다. 최근 소프트웨어 공급망 보안은 패키지 출처, 빌드 증명, 토큰 권한 제한 같은 장치에 기대고 있습니다. 그런데 Microsoft는 이번 악성 페이로드가 SLSA provenance 위조까지 시도했다고 밝혔습니다. 쉽게 말하면, 겉으로는 정상적인 공급망 증명처럼 보이게 만드는 시도가 있었다는 뜻입니다.
또 하나의 핵심은 CI/CD입니다. 예전에는 개발자 노트북의 악성 코드 실행이 주로 개인 환경 문제로 취급됐습니다. 하지만 지금의 빌드 서버는 배포 권한, 클라우드 권한, 패키지 게시 권한을 동시에 가지고 있습니다. 공격자가 CI 환경에서 실행되는 설치 스크립트를 장악하면 단순히 소스코드를 읽는 수준이 아니라 다음 배포물까지 오염시킬 수 있습니다.
| Risk | Why It Matters |
|---|---|
| npm token theft | 다른 패키지를 다시 오염시켜 공격을 확산할 수 있습니다. |
| GitHub token theft | 저장소 조작, 워크플로 추가, 조직 비밀값 접근으로 이어질 수 있습니다. |
| Cloud credential theft | 애플리케이션 밖의 인프라와 데이터까지 위험해질 수 있습니다. |
| Forged attestations | "서명됐으니 안전하다"는 단순 판단을 흔듭니다. |
GitHub가 악성 패키지 제거와 대규모 npm 토큰 무효화를 진행했다는 점은 대응이 빠르게 이뤄졌다는 신호입니다. 하지만 이미 영향을 받은 환경에서는 패키지를 지우는 것만으로 충분하지 않습니다. 설치가 한 번이라도 실행됐다면, 그 시점에 접근 가능했던 비밀값을 기준으로 사고 범위를 다시 계산해야 합니다.
What Changes for Developers
개발팀 입장에서 이번 사건은 의존성 업데이트 정책을 다시 보게 만듭니다. "최신 버전이면 좋다"는 습관은 보안과 충돌할 수 있습니다. 특히 운영 배포와 연결된 CI에서는 자동 업데이트, 느슨한 semver 범위, 설치 스크립트 허용이 함께 있을 때 위험이 커집니다.
현실적인 대응은 거창한 보안 체계를 새로 만드는 것보다 기본기를 촘촘히 다시 보는 데서 시작됩니다.
- lockfile을 기준으로 실제 설치된 버전을 확인해야 합니다.
- 의심 기간에 빌드가 실행된 환경은 자격 증명 노출 가능성을 전제로 조사해야 합니다.
- npm install 과정의
preinstall,postinstall스크립트 실행을 제한할 수 있는지 검토해야 합니다. - CI 토큰은 필요한 저장소와 작업에만 접근하도록 권한을 줄여야 합니다.
- 패키지 서명과 증명은 유용하지만, 그것만으로 안전 판정을 끝내면 안 됩니다.
AI 코딩 도구가 늘어나는 흐름도 이 문제와 연결됩니다. 개발 환경에는 이제 코드 편집기 확장, 패키지 매니저, GitHub Actions, 클라우드 CLI, AI 에이전트 설정이 한 공간에 모입니다. 이 모든 도구가 편의성을 높이지만, 동시에 공격자가 한 번 들어왔을 때 얻을 수 있는 권한도 커집니다.
The Bigger Shift
오픈소스 보안은 더 이상 "내가 직접 가져다 쓴 라이브러리"만의 문제가 아닙니다. 요즘 애플리케이션은 직접 의존성보다 간접 의존성이 훨씬 많고, 빌드 과정에서 도구가 알아서 내려받는 코드도 많습니다. 공격자는 이 복잡성을 잘 알고 있습니다. 인기 패키지의 핵심 코드를 바꾸지 않아도, 설치 스크립트 하나와 유지관리자 계정 하나만으로 넓은 범위에 접근할 수 있습니다.
이 사건이 말해주는 방향은 분명합니다. 기업 보안은 사용자 계정과 서버 방화벽만 볼 수 없습니다. 개발자가 사용하는 패키지, 확장 프로그램, 빌드 러너, 토큰 발급 방식이 모두 보안 경계가 됩니다. 특히 내부 도구나 대시보드처럼 "외부 고객이 직접 쓰는 서비스가 아니니 괜찮다"고 여겨지는 영역이 오히려 더 느슨할 수 있습니다.
앞으로 봐야 할 질문은 세 가지입니다.
- 우리 팀은 어떤 패키지가 빌드 중 자동 스크립트를 실행하는지 알고 있는가?
- CI/CD 환경의 토큰은 유출돼도 피해 범위가 작게 설계돼 있는가?
- 패키지 서명, SBOM, Dependabot 알림을 실제 사고 대응 절차와 연결하고 있는가?
이번 Mini Shai-Hulud 사건은 개발 속도를 늦추자는 이야기가 아닙니다. 자동화된 개발 환경을 계속 쓰려면, 그 자동화가 공격자에게도 같은 속도를 준다는 사실을 보안 설계에 반영해야 한다는 이야기입니다.