라이트LLM 공급망 공격, 가짜 보안 인증까지 겹친 이중 참사

하루 340만 회 다운로드되는 AI 오픈소스 프로젝트 라이트LLM(LiteLLM)이 공급망 공격을 당했다. 공격 그룹 팀PCP(TeamPCP)가 보안 스캐너 트리비(Trivy)를 먼저 장악한 뒤 라이트LLM의 PyPI 배포 토큰을 탈취해 악성 패키지를 유포했다. 라이트LLM이 보유한 SOC2 인증을 발급한 델브(Delve)마저 494건의 감사 보고서 조작 혐의를 받으면서, 보안 도구와 컴플라이언스 인증이 동시에 무너진 전례 없는 사태로 확산되고 있다.

공격의 시작: 보안 스캐너가 백도어가 되다

2026년 3월 24일 오전 10시 39분(UTC), 라이트LLM의 파이선(Python) 패키지 관리 저장소 PyPI에 버전 1.82.7이 등록됐다. 13분 뒤인 10시 52분에는 더 정교한 악성코드를 탑재한 1.82.8 버전이 뒤따랐다. 공격을 수행한 것은 팀PCP(TeamPCP)로 알려진 해커 그룹이다. 이들은 2025년 12월부터 활동을 시작해 텔레그램 채널을 운영하며 피해자 목록을 공개하는 등 대담한 행보를 보여왔다. 핵심 공격 경로는 라이트LLM의 CI/CD 파이프라인에서 버전 고정 없이 사용되던 오픈소스 보안 스캐너 트리비(Trivy)였다. 팀PCP는 2월 말 트리비의 깃허브 액션(GitHub Action) 워크플로 취약점을 이용해 관리자 자격증명을 탈취했고, 3월 19일 트리비 액션의 76개 릴리스 태그를 악성 버전(v0.69.4)으로 덮어씌웠다. 이 오염된 트리비가 라이트LLM의 빌드 과정에서 실행되면서 PyPI 배포 토큰이 공격자 손에 넘어갔다.

3단계 악성코드: 수집-암호화-지속 침투

악성코드의 구조는 세 단계로 설계됐다. 1단계에서는 호스트 시스템의 민감 정보를 체계적으로 수집한다. SSH 키, AWS·GCP·애저(Azure) 클라우드 자격증명, 쿠버네티스(Kubernetes) 시크릿과 인증서, .env 파일, 깃(Git) 설정, 셸 히스토리, 데이터베이스 비밀번호, 도커(Docker) 레지스트리 인증 정보, 심지어 암호화폐 지갑 파일까지 50개 이상 카테고리의 데이터를 대상으로 한다. AWS 시크릿 매니저(Secrets Manager)와 SSM 파라미터 스토어에 직접 질의하는 기능도 포함됐다.

2단계에서는 수집된 데이터를 AES-256-CBC 방식으로 암호화하고, 세션 키를 하드코딩된 4,096비트 RSA 공개키로 이중 암호화한다. 암호화된 번들은 tpcp.tar.gz라는 파일명으로 라이트LLM 공식 도메인을 사칭한 models.litellm.cloud로 전송된다. 3단계에서는 ~/.config/sysmon/sysmon.py 경로에 백도어 스크립트를 설치하고 시스템d(systemd) 서비스로 등록해 5분마다 공격자 서버(checkmarx.zone)로부터 추가 명령을 수신한다. 쿠버네티스 환경에서는 kube-system 네임스페이스에 특권(privileged) 파드를 생성해 클러스터 전체 노드로 횡적 이동(lateral movement)을 시도한다.

특히 v1.82.8에 추가된 litellm_init.pth 파일은 라이트LLM을 임포트하지 않아도, pip 설치나 IDE 실행 등 파이선 인터프리터가 기동되는 모든 순간에 악성코드를 실행하는 기법(MITRE ATT&CK T1546.018)을 사용했다. 보안 연구원 안드레이 카르파시(Andrej Karpathy)는 “라이트LLM 공급망 공격이 빠르게 발견된 것은 악성코드의 버그로 시스템 충돌이 발생했기 때문”이라고 지적했다.

피해 확산: DSPy부터 크루AI까지 다운스트림 비상

라이트LLM은 오픈AI(OpenAI), 앤스로픽(Anthropic), 구글, 애저 오픈AI(Azure OpenAI), 허깅페이스(Hugging Face) 등 수십 개 AI 제공 업체의 API 키를 관리하고 프록시하는 게이트웨이 역할을 한다. 깃허브 스타 4만 개 이상, Y콤비네이터(Y Combinator) 졸업 기업이라는 배경 덕에 기업과 개발자 사이에서 광범위하게 채택됐다. 클라우드 환경의 36%에 설치돼 있다는 통계는 이번 사건의 잠재적 피해 규모를 가늠하게 한다.

약 3시간의 노출 기간 동안 DSPy, MLflow, 오픈핸즈(OpenHands), 크루AI(CrewAI), 아리즈 피닉스(Arize Phoenix) 등 주요 다운스트림 프로젝트가 영향권에 들었다. 이들 프로젝트는 긴급하게 라이트LLM 의존성을 v1.82.6 이하로 고정하는 보안 패치를 배포했다. 라이트LLM 측은 구글의 맨디언트(Mandiant) 보안팀에 포렌식 분석을 의뢰했으며, 영향 받은 사용자에게 모든 시크릿을 즉시 교체하고 파일 시스템에서 litellm_init.pth 파일을 검색·제거하라고 권고했다.

팀PCP의 캠페인은 라이트LLM에 그치지 않았다. 3월 20일에는 npm 생태계에서 캐니스터웜(CanisterWorm)을 활용해 60초 만에 28개 패키지를 오염시켰고, 3월 22일에는 도커 허브(Docker Hub)에 악성 이미지를 등록했으며, 3월 23일에는 체크막스(Checkmarx)의 KICS 깃허브 액션 35개 태그를 모두 장악했다. 피해는 미국, 중국, 브라질, 인도, 한국 등 전 세계로 확산됐다.

델브(Delve)의 가짜 SOC2 인증: 보안 신뢰 사슬의 붕괴

이번 사건의 파장을 키운 것은 라이트LLM이 웹사이트에 게시한 SOC2 및 ISO 27001 보안 인증이다. 해당 인증을 발급한 것은 Y콤비네이터 출신의 보안 컴플라이언스 자동화 스타트업 델브(Delve)다. 그런데 델브는 바로 일주일 전인 3월 22일, 테크크런치(TechCrunch) 보도를 통해 494건의 SOC2 감사 보고서를 조작한 혐의가 공개됐다. 3,200만 달러(약 464억 원)를 투자받은 이 스타트업은 독립 감사가 실제로 이뤄지기 전에 감사 결론과 테스트 절차, 최종 보고서를 미리 생성하는 ‘구조적 사기’를 벌인 것으로 의심받고 있다.

2025년 12월 유출된 구글 스프레드시트에 대한 독립 저널리스트의 분석에 따르면, 보고서의 99.8%가 동일한 서식 언어를 사용했고, 테스트 값란에는 “sdf”, “dlkjf” 같은 무의미한 입력이 다수 발견됐다. 약 400개 이상의 기업이 무효화될 수 있는 SOC2 인증을 보유하고 있는 셈이다. 델브 CEO는 이를 “AI가 생성한 이메일에 기반한 허위 주장”이라고 반박했으나, 구체적 증거에 대해서는 답변하지 않았다. SEC와 AICPA 등 규제 기관이 이 사기를 사전에 감지하지 못했다는 점도 비판의 대상이다.

전망: AI 공급망 보안, 근본적 재설계가 필요하다

이번 사건은 두 가지 교훈을 남긴다. 첫째, CI/CD 파이프라인에서 사용하는 보안 도구 자체가 공격 벡터가 될 수 있다는 점이다. 트렌드마이크로(Trend Micro) 분석팀은 “CI/CD 보안 도구는 배포 도구와 동일한 접근 권한을 가진다. 보안 도구가 침해되면 모든 다운스트림이 노출된다”고 경고했다. 둘째, 컴플라이언스 인증 자체의 신뢰성 문제다. SOC2 인증이 있다는 이유만으로 소프트웨어 공급망의 보안을 신뢰한 기업들이 이중 피해를 입었다.

한국에서도 라이트LLM은 AI 서비스 개발 현장에서 널리 사용되고 있으며, 트렌드마이크로 보고서에 따르면 한국도 피해 영향권 국가에 포함된다. 국내 기업들은 의존성 버전을 암호화 해시로 고정하고, 새 릴리스 배포 전 격리 기간을 두며, 쿠버네티스 클러스터에서 kube-system 네임스페이스의 비인가 파드를 점검해야 한다. 보안 도구가 공격 경로가 되고 인증 제도까지 무력화된 이번 사태는, AI 생태계 전반의 소프트웨어 공급망 보안 체계를 근본부터 재검토해야 한다는 경고등이다.