수천 개 팀이 OpenAI, Anthropic을 비롯한 수십 개 LLM 제공업체로의 호출을 라우팅하기 위해 의존하는 AI 프록시 미들웨어 LiteLLM의 1.82.7 및 1.82.8 버전이 PyPI에서 변조되었다. 악성 패키지는 인덱스에 그대로 게시되어 있었다. 개발자들은 이를 설치했다. 그리고 Python의 기본 패키지 매니저인 pip은 이 문제에 대해 아무런 경고도 하지 않았다.
이 이야기는 Hacker News에서 306포인트를 기록했다. BerriAI의 GitHub 이슈 스레드는 빠르게 채워졌다. 세 건의 개별 분석 글이 수 시간 만에 피해 범위를 파악했다. 하지만 모든 글이 공격 자체에만 집중했다. 뻔한 후속 질문을 던진 글은 단 하나도 없었다: pip은 왜 아직도 누가 빌드했는지 검증하지 않고 패키지를 배포하는가?
이것이야말로 파고들어야 할 질문이다.
일상적인 공급망 공격이 AI 인프라에 도달한 경위
변조된 LiteLLM 버전에는 빌드 및 업로드 파이프라인 과정에서 주입된 수정 코드가 포함되어 있었다. 커뮤니티가 제출한 GitHub 이슈에 따르면, 이 공격은 PyPI의 배포 아티팩트를 직접 겨냥했다. 정교한 제로데이 공격이 아니었다. 공급망 공격의 가장 오래된 수법이었다: 개발자들이 자동으로 내려받는 패키지에 악성 코드를 슬쩍 끼워 넣는 것.
LiteLLM은 특히 위험한 위치에 있다. API 키를 처리하고, 모델 제공업체로의 요청을 라우팅하며, 인증 토큰을 관리하는 AI 인프라의 배관 역할을 한다. 변조된 버전은 단순히 노트북에서 악성 코드를 실행하는 것에 그치지 않는다. 환경에 있는 모든 LLM API 키를 탈취할 수 있다.
해당 버전은 결국 삭제되었다. 하지만 업로드와 삭제 사이의 시간 간격, 바로 그것이 문제의 전부다.
pip이 실제로 검증하는 것 — 그리고 검증하지 않는 것
나는 pip의 보안 설치 문서, PEP 740의 디지털 증명 명세, 그리고 Sigstore의 아키텍처를 직접 살펴보았다. 실제 명세를 면밀히 읽어본 결과는 다음과 같다.
Q: pip install litellm을 실행할 때 pip은 무엇을 검증하는가?
pip은 패키지가 HTTPS를 통해 PyPI로부터 도착했는지, 그리고 다운로드된 파일의 해시가 PyPI 인덱스에 명시된 값과 일치하는지를 검증한다. 그것이 전부다. pip의 보안 설치 문서에 명시되어 있듯이, 기본 워크플로우는 인덱스를 전적으로 신뢰한다. 누가 패키지를 업로드했는지, 빌드가 재현 가능한지, 아티팩트가 특정 소스 커밋에 대응하는지에 대한 검증은 없다.
스마트 컨트랙트 개발자가 이해할 수 있는 용어로 표현하자면: pip은 초기 DeFi 프로토콜이 오라클 피드를 신뢰하던 방식으로 레지스트리를 신뢰한다. 맹목적으로.
Q: 누군가 업로드 토큰이나 메인테이너 계정을 탈취하면, pip이 대체를 감지할 수 있는가?
없다. 해시 검증은 인덱스가 제공하는 것을 그대로 받았는지만 확인한다. 인덱스가 오염된 아티팩트를 제공하고 있다면, 해시는 그 오염된 것과 일치한다. 대역 외 확인이 없다. 개발자 신원에 기반한 별도의 서명이 없다. 아티팩트를 특정 CI 실행이나 소스 저장소에 연결하는 증명이 없다.
Q: PEP 740은 무엇을 바꾸는가?
PEP 740은 PyPI와 같은 패키지 인덱스가 배포 파일과 함께 디지털 증명을 저장하고 제공할 수 있는 메커니즘을 도입한다. 이 증명은 패키지 아티팩트를 특정 신원 및 빌드 환경에 결합하는 암호학적 진술이다 — "이 정확한 wheel은 이 GitHub Actions 워크플로우에서, 이 커밋으로부터, 이 인증된 퍼블리셔에 의해 빌드되었다"는 공증된 영수증이다.
이 명세는 증명 형식, 인덱스가 이를 제공하는 방식, 그리고 인스톨러가 이를 소비하는 방식을 정의한다. 설치 시점에 출처 검증을 가능하게 하는 배관 계층인 셈이다.
Q: 그리고 Sigstore가 서명 백엔드를 제공하는 것인가?
Sigstore는 서명 및 검증 인프라를 제공한다. 개발자에게 장기 GPG 키 관리를 요구하는 대신 — 사실상 아무도 패키지에 서명하지 않았던 이유가 바로 이것이었다 — Sigstore는 OIDC 신원에 연결된 단기 인증서를 사용한다. 개발자가 기존 GitHub 또는 Google 계정으로 인증하면 임시 서명 인증서를 받고, 아티팩트에 서명하며, 그 서명은 Rekor라 불리는 투명성 원장에 기록된다.
이 모델은 키 관리를 완전히 제거한다. 교체하거나, 유출되거나, 분실할 개인 키가 없다. 투명성 로그는 모든 서명 이벤트를 공개적으로 감사할 수 있음을 의미한다. 누군가 악성 패키지에 서명하면, 그 서명은 영구적으로 기록에 남는다.
Q: 그렇다면 왜 이것이 pip의 기본 동작으로 적용되지 않았는가?
여기서부터 불편해진다. 명세는 존재한다. PyPI는 증명 지원을 확대해 왔다. Sigstore의 도구는 프로덕션 수준이다. 그런데도 pip의 기본 설치 경로는 증명을 요구하지도, 확인하지도 않는다. 인프라는 구축되어 있다. 적용만 안 되고 있을 뿐이다.
그 이유 중 하나는 하위 호환성이다. PyPI의 수백만 개 패키지에는 증명이 없다. 하룻밤 사이에 이를 필수로 만들면 생태계 대다수에서 설치가 깨질 것이다. 하지만 LiteLLM 사건은 기다림의 대가를 적나라하게 드러낸다.
AI 미들웨어가 위험을 증폭시키는 이유
그 대가는 보이는 것보다 크다. LiteLLM은 무명의 유틸리티가 아니기 때문이다. 여러 LLM 제공업체를 활용하는 팀들의 핵심 의존성이다. GitHub 저장소의 스타가 10,000개를 넘는다. 프로덕션 AI 시스템의 API 키 라우팅과 요청 프록싱을 처리한다. 이 패키지가 변조되면, 피해 범위는 그것이 접근하는 모든 시크릿에 미친다.
AI 도구 생태계는 빠르게 움직이며, npm의 left-pad 시대가 소박해 보일 정도의 속도로 의존성을 끌어들이고 있다. 새로운 LLM 래퍼, 에이전트 프레임워크, RAG 파이프라인이 추가될 때마다 의존성 그래프에 노드가 하나씩 더해진다. 그리고 그 노드 하나하나는 업로드 체인의 가장 약한 고리만큼만 안전하다.
이는 2021년경 Solidity 생태계가 겪었던 패턴의 재현이다. 당시 개발자들은 GitHub에서 검증되지 않은 컨트랙트를 임포트하고 잘 되기를 바랄 뿐이었다. 차이점은: 스마트 컨트랙트 커뮤니티는 뼈아프게 교훈을 얻고 검증 도구를 만들었다는 것이다. Python 패키지 생태계는 그 도구를 이미 갖추고도 아직 스위치를 올리지 않고 있다.
개발자가 지금 당장 해야 할 일
첫째, LiteLLM 1.82.7 또는 1.82.8을 설치했는지 확인하라. 설치했다면, 해당 라이브러리가 접근할 수 있었던 모든 API 키를 교체하라. 내일이 아니다. 지금 당장.
둘째, 핵심 의존성에 대해 pip의 해시 확인 모드를 사용하기 시작하라. requirements 파일에 정확한 해시를 고정하라. 출처 검증은 아니지만, 이미 검증한 아티팩트가 은밀하게 대체되는 것을 방지한다.
셋째, PyPI에 패키지를 관리하고 있다면 Trusted Publishers를 활성화하라. 이는 PyPI 업로드를 특정 GitHub Actions 워크플로우에 연결하며 — 완전한 증명 지원을 향한 첫 단계다. 업로드 토큰을 완전히 제거하여, 공급망 변조의 가장 흔한 공격 벡터를 차단한다.
넷째, PEP 740 구현 진행 상황을 주시하라. pip이 증명을 필수로 요구하는 기능을 갖추는 순간, 프로젝트에 이를 활성화하라.
자물쇠는 있다. 채우기만 하면 된다.
LiteLLM 침해 사건은 새로운 것이 아니다. PyPI를 대상으로 한 공급망 공격은 이전에도 있었고 앞으로도 발생할 것이다. 이번 사건을 의미 있게 만드는 것은 공격 대상이다: 설계상 시크릿을 처리하는 광범위하게 배포된 AI 미들웨어 라이브러리. 그리고 이를 잡아냈어야 할 방어 수단 — 설치 시점의 암호학적 증명 — 은 이미 PEP 번호와 작동하는 인프라를 갖추고 있다.
PEP 740과 Sigstore는 프로덕션 구현을 갖춘 완성된 명세다. 격차는 채택과 적용에 있다. pip의 기본 워크플로우가 출처 확인 없이 인덱스를 신뢰하는 매주가, 다음 LiteLLM급 침해 사건이 탈취된 인증 정보 하나로 가능한 또 한 주다.
당신의 pip install은 인터넷에서 서명되지 않은 코드를 실행하고 이를 의존성이라 부른다. 오늘날 존재하는 도구들을 감안하면, 2026년에 이것은 워크플로우가 아니다. 이것은 리스크다.