본문으로 건너뛰기
피드

샤이훌루드 공급망 공격 재확산, 서명된 패키지도 더는 안심 못 함

security 약 6분

샤이훌루드 공급망 공격이 npm과 PyPI를 다시 덮치면서 TanStack, Mistral AI, UiPath, OpenSearch 등 개발자들이 많이 쓰는 생태계가 영향을 받았다. 공격자는 GitHub Actions와 OIDC 기반 배포 흐름을 악용해 정상 출처 증명처럼 보이는 악성 패키지를 올렸고, 설치 환경에서 토큰과 키를 훔쳐 감염을 확장했다.

  • 1

    TanStack 생태계에서 42개 패키지와 84개 악성 버전이 확인됨

  • 2

    GitHub Actions 캐시 포이즈닝과 OIDC 토큰 탈취가 정상 배포 파이프라인 악용에 쓰임

  • 3

    GitHub 토큰, npm 토큰, AWS 키, Kubernetes 서비스 계정 토큰, SSH 키 등이 탈취 대상

  • 4

    패키지 서명과 출처 증명만으로는 공급망 공격을 걸러내기 어려워짐

  • 샤이훌루드 공급망 공격이 npm과 PyPI를 다시 건드림

    • 이번에 영향권으로 언급된 이름이 꽤 큼. TanStack, Mistral AI, UiPath, OpenSearch, Guardrails AI 같은 개발자 친화 패키지들이 포함됨
    • 공개 시점은 5월 11일부터 12일 사이로, 단발성 장난이 아니라 배포 생태계 자체를 노린 캠페인에 가까움
  • 공격 방식은 단순히 '이상한 패키지 올려두기'가 아니었음

    • 개발자 계정이나 배포 권한을 훔친 뒤, 정상 패키지처럼 보이는 악성 버전을 올림
    • 그 패키지를 설치한 개발자 PC나 빌드 서버에서 다시 GitHub 토큰, npm 토큰, AWS 키 같은 자격증명을 털어 확산하는 구조임
    • 감염 지점이 개인 노트북이면 끝이 작아 보일 수 있지만, CI/CD 서버면 다음 패키지 변조와 조직 내부 침투로 바로 이어질 수 있음

중요

> 이번 사건의 찝찝한 지점은 일부 악성 패키지가 암호학적으로 정상처럼 보였다는 점임. 서명과 출처 증명이 있어도 배포 파이프라인 자체가 털렸다면 안전 신호가 깨질 수 있음.

  • TanStack 쪽 사후 분석이 특히 중요함

    • 공격자는 위험한 pull request target 워크플로, GitHub Actions 캐시 포이즈닝, 실행 환경 메모리의 OIDC 토큰 탈취를 연결해서 정상 배포 흐름을 악용함
    • TanStack 생태계에서는 42개 패키지에서 84개 악성 버전이 배포된 것으로 확인됨
    • 보안업체별 집계는 다르지만 npm과 PyPI를 합치면 수백 개 악성 패키지 버전이 나온다는 분석도 있음
  • 악성코드가 노린 건 개발자의 '작업 환경 전체'였음

    • GitHub 토큰, npm 배포 토큰, git 자격증명, AWS 키, Kubernetes 서비스 계정 토큰, HashiCorp Vault 토큰, SSH 키가 수집 대상에 들어감
    • Claude Code 설정, Visual Studio Code 작업 파일, 환경설정 파일까지 봤다는 점도 눈에 띔
    • 요즘 개발 환경이 로컬, IDE, 에이전트, 클라우드 토큰으로 촘촘히 연결돼 있다는 걸 공격자가 너무 잘 알고 있다는 얘기임
  • Mistral AI 관련 PyPI 패키지 일부도 공격 대상에 포함됨

    • 리눅스 환경에서 추가 악성 파일을 내려받아 실행하는 코드가 들어간 사례가 보고됨
    • 공격자가 파일명을 transformers.pyz로 쓴 것도 노골적임. 자연어 처리 쪽에서 익숙한 Transformers 라이브러리 이름을 빌려 의심을 줄이려는 의도로 보임
  • 일부 악성코드에는 지역·언어 환경에 따른 실행 분기까지 들어감

    • 러시아어 환경에서는 실행을 피하는 로직이 확인됨
    • 이스라엘이나 이란으로 보이는 환경에서는 일정 확률로 파일 삭제 명령을 실행하는 파괴적 기능도 보고됨
    • 이전 Kubernetes 환경을 노린 CanisterWorm 공격과 비슷한 특징으로 평가됨
  • 방어 전략도 이제 한 단계 더 빡세져야 함

    • 패키지 서명 확인만으로 끝내면 부족함. 설치 시점의 행위 분석, lockfile 기반 설치, 자동 업데이트 제한이 같이 필요함
    • CI/CD 권한은 최소화하고, 빌드 환경은 격리해야 함
    • 특히 패키지 배포 토큰과 클라우드 키가 같은 실행 환경에 오래 남아 있는 구조라면 이번 사건을 계기로 바로 손봐야 함

기술 맥락

  • 이번 공격에서 중요한 건 OIDC를 썼다는 사실 자체가 아니라, OIDC가 연결된 배포 흐름이 뚫렸다는 점이에요. OIDC는 원래 장기 토큰을 줄이려고 쓰는 방식인데, 실행 중인 워크플로 메모리에서 임시 토큰을 훔치면 공격자 입장에서는 정상 배포 권한을 잠깐 빌린 셈이 되거든요.

  • GitHub Actions 캐시 포이즈닝이 위험한 이유는 CI가 캐시를 신뢰한다는 데 있어요. 빌드 속도를 높이려고 저장한 캐시가 오염되면, 다음 실행에서 정상 스크립트가 악성 내용을 자연스럽게 끌어올 수 있어요.

  • 패키지 서명과 출처 증명은 여전히 필요하지만, 이번처럼 정상 배포 파이프라인이 악용되면 신호가 약해져요. 그래서 lockfile 고정, 설치 후 스크립트 제한, CI 권한 분리처럼 실행 단계의 방어가 같이 붙어야 해요.

  • 특히 한국 개발팀도 npm, PyPI, GitHub Actions를 거의 기본 인프라처럼 쓰기 때문에 남의 일이 아니에요. 개인 개발자 PC보다 더 무서운 건 배포 권한이 있는 CI 서버가 감염되는 경우고, 그때는 내부 서비스와 패키지 소비자까지 연쇄적으로 맞을 수 있어요.

이번 사건의 포인트는 악성 패키지가 그냥 수상한 파일로 올라온 게 아니라 정상 배포 절차를 타고 들어왔다는 점임. 이제 패키지 신뢰 모델은 '서명됐나'에서 '설치 시점에 뭘 하냐'로 무게중심을 옮겨야 함.

댓글

댓글

댓글을 불러오는 중...

security

메가존클라우드 HALO, “이제는 사람이 아닌 계정을 검증해야 할 때”

메가존클라우드의 보안 브랜드 HALO가 에이전틱 AI 시대의 보안 전략을 공개했다. 핵심은 해커의 AI가 사람 지시 없이 취약점을 찾고 우회하는 속도에 맞서, 방어도 AI가 탐지부터 조치까지 자동으로 수행해야 한다는 주장이다.

security

SAP, 엔비디아 오픈셸로 ERP 안 AI 에이전트 보안 강화

SAP가 엔비디아의 오픈소스 런타임 오픈셸을 SAP 비즈니스 AI 플랫폼에 내장한다. ERP처럼 민감한 기업 핵심 시스템 안에서 AI 에이전트가 움직이려면 격리, 접근 제어, 실행 추적 같은 보안·거버넌스 장치가 필수라는 판단이다.

security

마이크로소프트, 100개 넘는 AI 에이전트로 취약점 찾는 보안 시스템 공개

마이크로소프트가 100개 이상의 AI 에이전트를 조율해 소프트웨어 취약점을 탐지하는 보안 시스템 MDASH를 공개했다. 공개 벤치마크 CyberGym에서 1,507개 취약점 재현 과제 중 88.4% 성공률을 기록했고, 윈도우 네트워킹·인증 스택에서 신규 취약점 16건도 찾아냈다.

security

윈도우 11 BitLocker 우회 취약점 ‘YellowKey’ 공개, WinRE 경로가 문제로 지목됨

YellowKey라는 BitLocker 우회 취약점 공개 글이 올라왔고, 작성자는 Windows Recovery Environment에만 있는 특정 구성요소가 보호된 볼륨 접근을 허용한다고 주장한다. 공개 내용은 Windows 11과 Windows Server 2022/2025가 영향권이고 Windows 10은 제외된다고 설명하며, Microsoft 보안 조직과의 공개 조율도 언급한다.

security

해고 직후 정부 DB 96개 삭제 혐의, 내부자 접근권 회수의 무서운 사례

미국 정부 고객을 상대하던 IT 업체에서 해고된 쌍둥이 형제가 몇 분 뒤 정부 정보가 담긴 데이터베이스 96개를 삭제한 혐의를 받고 있다. 기사에는 이들이 이전에도 컴퓨터 범죄 전력이 있었고, 회사 네트워크에서 5,400개 계정 정보를 모아 Python 스크립트로 외부 서비스 로그인을 시도했다는 정황도 나온다.