LiteLLM 공급망 공격 사태와 보안 대책 (2026)

1. 사태 개요

2026년 3월, 전 세계적으로 널리 사용되는 오픈소스 AI API 게이트웨이 시스템인 LiteLLM 패키지가 심각한 형태의 소프트웨어 공급망 공격(Software Supply Chain Attack)에 노출되었습니다.

해커 그룹(TeamPCP)은 LiteLLM 프로젝트의 CI/CD 파이프라인에서 사용되던 서드파티 보안 스캐너(Trivy)의 취약점을 악용하여 PyPI(Python Package Index) 배포 권한을 탈취했습니다. 그 결과, 공격자가 심어 놓은 악성 코드가 포함된 공식 릴리즈 버전(1.82.7, 1.82.8)이 수많은 사용자 및 기업의 프로덕션 환경에 배포되었습니다.

피해 양상

이 악성 버전은 설치되는 즉시 호스트 시스템을 탐색하여 치명적인 권한 탈취(Credential Harvesting)를 시도했습니다:

AWS, GCP, Azure 등 주요 클라우드 서비스의 자격 증명 탈취
SSH 키, 시스템 환경변수(Env), 그리고 Kubernetes Secrets 유출
.pth 파일 변조를 통한 영구적인 백도어(Persistence) 확보
Kubernetes 클러스터 내부에서의 횡적 이동(Lateral Movement) 시도

2. AI 인프라에서 왜 이 사태가 치명적인가?

일반적인 패키지 해킹 시나리오보다, LiteLLM과 같은 AI Gateway의 피격이 훨씬 더 위험한 이유는 아키텍처 상의 위치 때문입니다.

키 관리의 중앙집중화: LiteLLM의 핵심 역할이 OpenAI, Anthropic, Gemini 등 수백 개의 상용 LLM API Key를 중앙에서 로드하고 라우팅하는 것입니다. 이 공간이 뚫렸다는 것은 기업이 보유한 모든 AI 서비스 제공자의 과금/제어 권한이 한 번에 유출됨을 의미합니다.
높은 클라우드 접근 권한: 라우팅 서버는 지연율과 대규모 트래픽 처리를 위해 핵심 VPC 망에 배포되며, DB 연동 등을 위해 높은 인프라(K8s, IAM 등) 접근 권한을 가진 경우가 많습니다.

3. 유사 문제 해결 및 방어를 위한 아키텍처 전략

서드파티 라이브러리(OSS)의 공급망 공격을 100% 막는 것은 불가능하지만, 공격을 당했을 때 시스템(에이전트 인프라)이 파괴되거나 자격 증명이 대량 유출되는 것을 막기 위한 심층 방어(Defense in Depth) 아키텍처를 구축해야 합니다.

A. 네트워크 격리 (Egress Filtering)

개념: 서버가 꼭 필요한 외부 주소로만 통신하고, 그 외의 주소(해커의 C2 서버 등)로는 트래픽을 내보내지 못하게 막는 기법입니다.
적용: LiteLLM 파드(Pod) 또는 도커 컨테이너는 허용된 엔드포인트(api.openai.com 등)로만 나갈 수 있도록 K8s Network Policy 나 AWS Security Group 레벨에서 Outbound 트래픽을 화이트리스트 기반으로 통제합니다.

B. 런타임 위협 탐지 및 컨테이너 무결성 보장

개념: 애플리케이션이 실행 중(Runtime)일 때 허가되지 않은 프로세스가 뜨거나 예상 밖의 파일(예: site-packages 내 .pth 악성 스크립트)이 생성되는 것을 즉각 차단합니다.
적용: Falco나 eBPF 기반의 런타임 보안 도구를 사용하여, 패키지가 내부 인프라에서 권한 상승을 시도하는 순간 컨테이너를 강제 종료하고 격리시킵니다.

C. 최소 권한의 원칙 (Rootless & IAM IAM)

개념: 패키지가 실행되는 환경 자체의 권한을 극도로 제한합니다.
적용:
- 컨테이너를 절대 root 유저로 실행하지 않습니다. (Rootless Container 환경 필수)
- LiteLLM 파드가 구동되는 K8s Worker Node에 불필요한 EC2/GCP IAM Role 부여를 최소화합니다. (이번 사태처럼 클라우드 메타데이터 API 탈취를 무효화하기 위함)
- 환경 변수(.env) 대신 AWS Secrets Manager, HashiCorp Vault와 같은 안전한 Vault 인프라를 활용해 런타임 시스템 메모리에만 잠시 키를 적재하고 파일로는 남기지 않습니다.

D. 엄격한 패키지 및 종속성 관리

버전 핀(Pinning) 및 해시 검증: requirements.txt 또는 poetry.lock 파일에 패키지 버전을 명시할 뿐 아니라, 해시(Hash)값을 함께 등록하여 PyPI에 업로드된 파일이 중간에 변조되지 않았음을 설치 시마다 검증합니다.
자동화된 업데이트 유보 체계: latest 태그 사용을 절대 금지하고 새로운 릴리즈가 배포된 후 침해 사고 보고가 없는지 일정 기간(ex: 1~2주) 모니터링 후 프로덕션에 적용하는 보수적 배포 파이프라인(Staged Rollout)을 구현합니다.