누군가 상수원에 독을 풀었다. 말 그대로는 아니지만, 소프트웨어 세계에서 그에 상응하는 일이 벌어졌고, 그 결과는 어쩌면 더 심각할 수 있다.
오픈소스 Python 패키지로서 애플리케이션과 대규모 언어 모델 API 사이의 만능 번역기 역할을 하는 LiteLLM이 공급망 공격을 받았다. 수천 개의 AI 애플리케이션이 가장 민감한 호출을 라우팅하기 위해 의존하는 바로 그 계층이 침해된 것이다. OpenAI, Anthropic, Cohere 또는 기타 주요 LLM 제공업체와 단일 인터페이스를 통해 통신하는 무언가를 만들었다면, LiteLLM이 당신의 의존성 트리 어딘가에 자리 잡고 있을 가능성이 높다. 그리고 일정 기간 동안, 그 의존성은 단순히 API 호출을 라우팅하는 것 이상의 일을 하고 있었다.
PyPI의 악성 패키지, 수백만 명의 잠재적 피해자
이번 공격은 Python 생태계의 기본 패키지 저장소 역할을 하는 Python 패키지 인덱스, PyPI에서의 LiteLLM 배포를 표적으로 삼았다. LiteLLM GitHub 저장소에 게시된 보안 권고에 따르면, 침해된 버전을 설치하거나 업데이트한 모든 애플리케이션에서 API 키와 환경 변수를 포함한 민감한 데이터를 유출하도록 설계된 코드가 포함된 악성 버전의 패키지가 게시되었다.
잠깐 이 사실을 곱씹어 보자. LiteLLM의 존재 이유 자체가 애플리케이션과 LLM 제공업체 사이에 위치하는 것이다. 인증을 처리한다. API 키를 전달한다. 프롬프트를 라우팅한다. 이 패키지의 침해된 버전은 단순히 코드에 접근하는 것이 아니라, AI 애플리케이션이 작동하는 데 필요한 모든 비밀에 접근할 수 있다.
BerriAI의 LiteLLM 메인테이너들은 침해가 확인된 후 신속하게 대응했으며, PyPI와 협력하여 영향을 받은 버전을 제거하고 패치된 릴리스를 게시했다. 그러나 비교적 짧은 기간이었다 하더라도, 노출 기간은 수백만 건의 다운로드 수를 가진 패키지에 영향을 미쳤다.
LiteLLM이 아무도 예상하지 못한 최고 가치의 표적인 이유
내가 계속 되새기고 있는 부분이 있다. AI 생태계에서 공급망 공격을 이야기할 때, 대부분의 사람들은 모델 포이즈닝을 떠올린다 — 오염된 학습 데이터, 백도어가 심어진 가중치. 물론 이것들은 실제 위협이다. 하지만 이를 위해서는 정교한 ML 전문 지식과 인내심 있는 장기적 실행이 필요하다.
미들웨어 계층을 공격하는 것은? 그것은 가장 매력적인 표적을 겨냥한 고전적인 소프트웨어 공급망 공격이다.
LiteLLM은 조용히 필수적인 존재가 되었다. GitHub에서 18,000개 이상의 스타를 보유하고 PyPI에서 가장 많이 다운로드되는 AI 관련 패키지 중 하나로 꾸준히 순위에 올라 있는 LiteLLM은 별생각 없이 끌어오게 되는 종류의 의존성이다. GPT-4와 Claude를 통합 코드 재작성 없이 전환하고 싶어서 설치한다. 팀이 LLM 제공업체 전반에 걸쳐 통합 로깅 계층을 원해서 설치한다. 지난 1년간 읽은 모든 튜토리얼이 추천해서 설치한다.
바로 그 보편성이 위험한 이유다. LiteLLM은 보안 연구자들이 의존성 그래프에서 "병목 지점"이라고 부르는 위치를 차지하고 있다 — 수십 개의 서로 다른 LLM API에 대한 자격 증명과 프롬프트를 처리하는 하나의 패키지가 수천 개의 프로덕션 애플리케이션에 설치되어 있는 것이다. 의존성 트리에서 말단 노드가 아니다. 줄기 그 자체다.
비교를 위해, 2018년 event-stream 사건을 떠올려 보자. 한 명의 악성 메인테이너가 인기 있는 npm 패키지를 침해하여 하나의 특정 애플리케이션에서 암호화폐 지갑 자격 증명을 탈취했다. 단 하나의 앱. LiteLLM의 위치는 성공적인 침해가 LiteLLM을 사용하는 모든 애플리케이션에서, 지원하는 모든 제공업체에 걸쳐 API 키를 수집할 수 있다는 것을 의미한다.
이 공격이 AI 미들웨어의 사각지대를 악용하는 방식
왜 이 유형의 공격이 AI 미들웨어 맥락에서 특히 악랄한지 설명하겠다.
고객 지원 챗봇을 구축한 스타트업을 운영하고 있다고 상상해 보자. 애플리케이션은 비용과 지연 시간에 따라 요청을 다른 제공업체로 라우팅하기 위해 LiteLLM을 사용한다. 평소에 고객이 주문 상태에 대해 물어본다. 앱은 LiteLLM을 통해 해당 프롬프트를, 예를 들어 Claude로 보낸다. LiteLLM은 Anthropic API 키를 첨부하고, 요청을 전달하며, 응답을 받아 다시 전달한다. 단순한 배관 작업이다.
이제 침해된 버전을 떠올려 보자. 동일한 흐름이 실행된다 — 고객은 답변을 받고, 모든 것이 정상으로 보인다. 하지만 백그라운드에서 악성 코드는 조용히 API 키, 프롬프트(고객 데이터가 포함되어 있을 수 있는), 그리고 환경 변수를 외부 서버로 복사하고 있다. 애플리케이션의 동작을 지켜보는 것만으로는 절대 알 수 없다. 응답은 여전히 도착한다. 지연 시간이 몇 밀리초 정도 늘어날 수 있다. 모니터링에 아무것도 걸리지 않는다.
이것이 미들웨어에 대한 공급망 공격이 그토록 교활한 이유다. 악성 코드는 애플리케이션의 가시적인 동작을 변경할 필요가 없다. 그저 지켜보기만 하면 된다.
자체 성장의 무게에 짓눌리는 오픈소스 AI 인프라
이번 사건은 2025년을 거쳐 2026년까지 가속화되어 온 패턴에 부합한다. AI 생태계는 폭발적으로 성장했고, 이를 지탱하는 오픈소스 인프라는 더 오래된 생태계가 갖추고 있는 보안 성숙도를 발전시킬 시간이 없었다.
수치를 살펴보자. PyPI 다운로드 통계에 따르면, AI 및 ML 관련 패키지의 다운로드 수는 지난 2년간 몇 자릿수 단위로 급증했다. 새로운 AI 스타트업마다, 기업의 "AI 전환" 이니셔티브마다, 주말 해커톤 프로젝트마다 이러한 패키지를 수십 개씩 끌어온다. 그리고 이들 중 많은 패키지가 — LiteLLM처럼 — 스타트업 속도로 운영되는 소규모 팀에 의해 유지 관리되고 있다.
LiteLLM 뒤에 있는 회사인 BerriAI는 보안 문제에 대해 신속하고 투명하게 대응해 왔다. GitHub 저장소를 보면 보안 보고서에 적극적으로 관여하고 있음을 알 수 있다. 하지만 근본적인 문제는 특정 메인테이너의 성실성에 관한 것이 아니다. 구조적인 문제다.
Python 패키징 생태계는 최근 몇 년간 상당한 개선에도 불구하고 여전히 신뢰에 크게 의존하고 있다. PyPI는 신뢰할 수 있는 퍼블리셔와 주요 프로젝트에 대한 필수 2단계 인증 같은 기능을 도입했다. 그러나 공격 표면은 여전히 광대하다: 타이포스쿼팅, 계정 탈취, 합법적 패키지에 대한 악성 업데이트. 이것들은 npm, RubyGems, 그리고 다른 모든 패키지 레지스트리를 괴롭혀 온 것과 동일한 벡터다. 차이점은 AI 미들웨어 패키지가 유독 민감한 페이로드를 운반한다는 것이다.
이 탭을 닫기 전에 해야 할 일
이번 주에 충분히 많은 개발자들과 이야기를 나눠본 결과, 반응이 두 부류로 나뉜다는 것을 알게 되었다. 첫 번째 부류는 이미 pip freeze | grep litellm을 실행하고 잠금 파일을 감사하고 있다. 좋다. 두 번째 부류는 "우리는 다른 프레임워크를 통해 LiteLLM을 사용하니까 괜찮을 거야"라고 생각하고 있다. 두 번째 부류가 오히려 더 걱정해야 한다. 전이적 의존성이야말로 공급망 공격이 숨는 곳이다.
실질적인 행동 지침은 다음과 같다.
모든 버전을 고정하라 — 특히 AI 의존성
아직 LiteLLM의 정확한 버전을 고정하지 않았다면(솔직히 말해, 모든 AI 의존성에 대해), 오늘부터 시작하라. litellm>=1.0이라고 적힌 requirements.txt는 열린 초대장이다. 검증된 특정 버전으로 고정하라. 도구가 지원한다면 해시 검증을 사용하라.
전체 의존성 트리를 매핑하라
프로젝트에 대해 pip-audit 또는 유사한 도구를 실행하라. 특히 AI 미들웨어 패키지를 찾아보라 — LiteLLM뿐만 아니라 API 키를 처리하거나 외부 서비스로 요청을 라우팅하는 모든 패키지를. pip-audit 같은 도구는 설치된 패키지를 알려진 취약점 데이터베이스와 대조하여 확인할 수 있다.
노출된 모든 API 키를 교체하라
영향을 받은 버전을 설치했을 가능성이 조금이라도 있다면, LiteLLM이 접근할 수 있었던 모든 API 키를 교체하라. 전부 다. OpenAI, Anthropic, Cohere, Azure — 모두. 번거로운 일이라는 것을 안다. 그래도 하라.
네트워크 수준에서 이그레스를 잠가라
프로덕션 배포의 경우, AI 미들웨어는 알려진 LLM API 엔드포인트에만 접근할 수 있어야 한다. LiteLLM 인스턴스가 예기치 않은 호스트에 연결하고 있다면, 그것이 바로 경고 신호다. Kubernetes의 네트워크 정책, 클라우드 제공업체의 이그레스 규칙, 심지어 단순한 방화벽 규칙이라도 침해된 의존성의 피해 범위를 제한할 수 있다.
보안 권고를 구독하라 — 저장소에 스타만 누르지 말고
LiteLLM 팀은 GitHub 저장소에 보안 권고를 게시해 오고 있다. 팔로우하라. 패키지에 API 키를 맡기고 있다면, 해당 패키지의 보안 알림을 구독해야 한다.
AI 산업이 더 이상 피할 수 없는 대화
이 모든 것 아래에 더 어려운 질문이 있으며, 이는 LiteLLM을 훨씬 넘어서는 문제다.
우리는 지난 3년간 LLM 통합을 더 쉽게 만들기 위해 점점 더 복잡한 오픈소스 도구 스택을 구축해 왔다 — 오케스트레이션 프레임워크, 프롬프트 관리 라이브러리, 평가 도구, API 라우팅 레이어. 이 각각은 잠재적인 공급망 표적이며, 각각은 유출될 경우 민감하거나 심지어 치명적일 수 있는 데이터를 다루고 있다.
전통적인 오픈소스 보안 모델은 많은 눈이 모든 버그를 얕게 만든다고 가정한다. 하지만 AI 미들웨어 생태계는 너무 빠르게 움직이고 있어서, 그 눈들은 보안이 아닌 기능에 집중되어 있다. 메인테이너들은 위협 모델링을 수행하는 것이 아니라 새로운 제공업체 통합을 배포하고 있다. 그리고 이러한 도구 위에 구축하는 기업들은 철저한 의존성 감사가 감당할 수 없는 사치처럼 느껴지는 속도로 움직이고 있다.
이것은 특정 프로젝트나 팀에 대한 비판이 아니다. 보안 인프라를 넘어서 성장해 버린 생태계에 대한 묘사다. 문제는 이 같은 공격이 더 발생할 것인가가 아니다 — 발생할 것이다. 문제는 커뮤니티가 그 공격이 발생했을 때 피해를 줄일 수 있는 도구, 관행, 그리고 자금 모델을 구축할 것인가이다.
10분 투자의 성과 — 지금 당장 하라
터미널을 열어라. AI 애플리케이션을 실행하는 모든 Python 환경에서 pip list --format=json | python3 -c "import sys,json; [print(p['name'], p['version']) for p in json.load(sys.stdin) if 'llm' in p['name'].lower() or 'ai' in p['name'].lower() or 'openai' in p['name'].lower()]"을 실행하라. 이것으로 모든 AI 관련 패키지와 정확한 버전의 빠른 인벤토리를 얻을 수 있다. 각 프로젝트의 보안 권고에 나열된 안전한 버전과 대조하라. 10분이면 된다. 아주 끔찍한 한 주를 면할 수 있을지도 모른다.