LiteLLM 1.107.0 침해, 소스 검토만으로 못 막는 이유

SafeDep가 보고한 범위는 특정 배포물이다

SafeDep는 10월 21일 LiteLLM 1.107.0 분석에서 PyPI에 올라온 해당 버전에 자격증명 탈취 코드와 원격 코드 실행 백도어가 포함됐다고 보고했다. 분석에 따르면 Linux·macOS·Windows용 wheel 7개에 문제 파일이 들어갔고, PyPI는 이후 해당 릴리스를 제거했다. 이 글의 세부 침해 설명은 작성 중 열람한 SafeDep의 공개 분석에 근거하며 독립 포렌식 결과를 뜻하지 않는다. 원문 링크는 재확인 때 404를 반환했지만, 공식 블로그 목록과 RSS에서도 해당 보고서의 제목과 핵심 요약을 확인했다.

중요한 구분은 공개 LiteLLM 저장소의 소스와 실제 설치 배포물이 일치하지 않았다는 것이다. SafeDep는 공개 소스에는 문제 코드가 없다고 설명했다. 또한 비교한 1.106.2와 1.107.0rc1·rc2에서는 같은 침해를 발견하지 않았다고 밝혔다. 이 결과를 모든 이전·이후 버전이 안전하다는 보장으로 넓혀서는 안 된다.

LiteLLM처럼 여러 모델 제공업체를 연결하는 소프트웨어는 편리한 공통 인터페이스를 제공한다. 동시에 운영 환경에 여러 업체의 키가 모일 수 있어 침해 시 영향 범위도 커진다. 이번 사건이 단순한 Python 패키지 뉴스가 아니라 AI 운영 뉴스인 이유다.

모델을 호출하지 않아도 실행될 수 있는 경로

보고서에 따르면 문제 파일은 Python의 시작 처리 경로를 이용한다. 따라서 설치된 문제 환경에서 LiteLLM을 직접 import하지 않는 Python 작업도 영향을 받을 수 있다. Python의 site 모듈 공식 문서는 경로 설정 파일의 실행 가능한 줄과 사용자 정의 초기화 모듈이 시작 시 처리될 수 있음을 설명한다. 단, 모든 Python 실행 모드가 동일한 것은 아니므로 실제 환경과 옵션을 확인해야 한다.

이 차이는 조사 대상을 바꾼다. ‘문제 버전으로 추론 요청을 보냈는가’만 확인하면 IDE 보조 프로세스, CI 작업, 관리 스크립트에서 발생한 실행을 놓칠 수 있다. 설치된 환경, 실행 시각, 그 프로세스가 읽을 수 있었던 비밀값을 연결해야 한다. 소프트웨어를 지웠다는 사실과 이미 노출된 자격증명이 무효화됐다는 사실도 다르다.

원인 추정과 확정 증거를 구분해야 한다

SafeDep는 배포 파일의 구조와 빌드 흔적이 정상 파이프라인 출력과 유사하다는 점을 근거로, 비공개 릴리스 경로가 변조된 소스를 빌드했을 가능성을 제시했다. 그러나 유지관리자 자격증명, 봇 계정, 비공개 브랜치 등 어떤 경로가 실제로 이용됐는지는 공급자의 내부 로그가 필요하다고 명시했다. 그러므로 ‘PyPI 자체가 해킹됐다’거나 ‘특정 계정이 범인’이라고 단정할 수 없다.

배포 출처를 확인하는 방법으로 PyPI의 디지털 증명 문서를 참고할 수 있다. 출처 증명은 검증할 정보를 늘려주지만, 서명이나 자동 배포 인증이 붙었다고 악성 변경까지 자동으로 배제하는 것은 아니다. 어떤 소스 참조와 작업이 증명됐는지 읽어야 한다.

이는 Docker Agent의 실행 재현성과 맞닿아 있다. 동일한 설정을 재현하는 능력과 그 설정이 안전하다는 판단은 분리해야 한다. Anthropic Scion의 에이전트 규모 소스 관리 역시 변경량이 늘수록 소스에서 배포까지의 연결 증거가 중요해지는 배경이다.

한국 AI 팀의 대응: 업데이트보다 먼저 범위를 확인한다

실무적으로는 문제 버전이 포함된 가상환경·컨테이너 이미지·CI 캐시를 식별하고, 의심 환경을 격리한 상태에서 설치 이력과 로그를 보존하는 것이 우선이다. 확인을 위해 의심 환경의 Python을 무심코 다시 실행하는 방식은 피해야 한다. 검증된 별도 환경에서 파일과 기록을 조사하는 편이 합리적이다.

이어 노출 가능성이 있는 자격증명의 발급처에서 기존 키를 폐기하고 새 키를 발급해야 한다. AI 키만이 아니라 해당 프로세스의 권한으로 읽을 수 있었던 클라우드·저장소·배포용 자격증명도 범위에 포함될 수 있다. 다만 특정 회사의 피해가 확인되지 않았는데 모든 데이터가 유출됐다고 공표하는 것도 옳지 않다. 설치·실행·접근 증거에 따라 범위를 좁혀야 한다.

오픈소스 프록시와 관리형 게이트웨이의 경쟁에서는 기능 수 외에 패치 운영, 비밀값 격리, 감사 가능성이 중요해진다. 직접 운영하면 통제권이 커지는 대신 공급망 검증 책임도 커진다. 관리형 서비스도 공급자 사고에서 자유롭지는 않다. 에이전트 자격증명의 실행 경계를 먼저 설계하고, 모델 라우팅의 편리함을 그 경계 안에 넣어야 한다.

FAQ

LiteLLM 전체가 악성 소프트웨어라는 뜻인가?

아니다. 보고서의 대상은 PyPI에 게시된 1.107.0 배포물이다. 프로젝트 전체의 의도나 모든 버전을 같은 범주로 볼 근거는 없다.

패키지를 설치했지만 추론에 쓰지 않았다면 괜찮나?

그것만으로 안전하다고 판단할 수 없다. 문제 환경에서 Python이 시작될 때 실행될 수 있는 경로가 보고됐다.

버전을 낮추면 사고 대응이 끝나나?

아니다. 이미 실행된 코드의 흔적과 자격증명 노출을 별도로 조사해야 하며, 오염 환경을 신뢰 가능한 상태로 복구해야 한다.

SafeDep가 깨끗하다고 한 버전은 영구적으로 안전한가?

특정 비교 분석의 결론이지 영구 보증이 아니다. 공급자 공지와 현재의 배포 파일을 함께 확인해야 한다.

공격의 최초 진입점은 밝혀졌나?

공개 분석은 릴리스 파이프라인 관련 가설을 제시하지만 최종 원인은 확정하지 않았다. 내부 빌드·계정 로그를 통한 확인이 필요하다.