본문으로 건너뛰기
피드

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

security 약 6분
vote
0
댓글
북마크

샤이훌루드 공급망 공격이 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

AI 에이전트 보안, 이제 권한이 아니라 ‘실행 증거’ 싸움으로 간다

오페이크가 AI 에이전트의 ID, 실행 환경, 도구 호출, 정책 적용 여부를 암호학적으로 검증하는 오페이크 3.0을 공개했다. 핵심은 에이전트 매니페스트와 컨피덴셜 MCP라는 두 오픈소스 기술이며, 기밀 컴퓨팅과 서명된 실행 증거를 결합해 감사자나 규제기관도 독립적으로 확인할 수 있게 하는 방향이다. AI 에이전트가 업무 시스템과 데이터를 직접 만지는 시대에는 접근 권한보다 ‘무슨 일을 했는지 증명할 수 있느냐’가 더 중요해지고 있다.

security

취약점 제보가 더 이상 특별하지 않은 시대가 왔다

전 Go 보안팀 리드였던 필리포 발소르다가 LLM 이후 취약점 제보의 의미가 바뀌었다고 주장한다. 예전에는 희소한 통찰과 비공개 제보가 귀했지만, 이제는 잠재 취약점을 찾는 것보다 실제 영향도를 빠르게 가려내는 triage가 병목이라는 얘기다.

security

스패로우, AI가 만든 코드 취약점 잡는 ‘Sparrow MCP’ 출시

스패로우가 AI 코딩 에이전트가 생성한 코드의 보안 취약점과 사용된 오픈소스를 실시간으로 검사하는 보안 어시스턴트 ‘Sparrow MCP’를 출시했다. 핵심 기능은 취약점 분석과 소프트웨어 자재명세서(SBOM) 생성이며, 앤트로픽의 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI와 연결할 수 있다는 점이다. AI 코딩이 빨라질수록 보안 검증과 오픈소스 추적이 개발 파이프라인 안으로 더 깊게 들어오는 흐름이다.

security

오픈AI, 오픈소스 취약점 고치는 ‘패치 더 플래닛’ 시작

오픈AI가 트레일 오브 비츠와 함께 주요 오픈소스 프로젝트의 취약점을 AI로 찾고, 사람 검토를 거쳐 실제 패치까지 연결하는 프로그램을 시작했다. 파이썬, 고, cURL, 시그스토어, NATS 서버 같은 핵심 프로젝트가 초기 대상이고, 지금까지 수백 건의 보안 이슈와 수십 건의 병합된 패치가 나왔다. 핵심은 AI가 보안팀을 대체하는 게 아니라, 탐지·검증·패치·공개 조율을 빠르게 만드는 보조 엔진이라는 점이다.

security

오픈AI, 취약점 찾기부터 패치까지 돕는 ‘코덱스 시큐리티’ 공개

오픈AI가 사이버보안 이니셔티브 데이브레이크를 확대하면서 보안 전용 도구 코덱스 시큐리티와 GPT-5.5-사이버를 공개했다. 목표는 취약점 탐지에서 끝나는 게 아니라 검증, 위험도 평가, 패치 개발, 테스트, 배포까지 AI로 지원하는 것이다. cURL, Go, Python, Sigstore 등 30개 이상 오픈소스 프로젝트도 패치 지원 프로그램에 참여한다.