LiteLLM 악성 패키지 유포 대응 체크리스트 (국가사이버안보센터 3/31 권고 기준)

LiteLLM 악성 패키지 유포 대응 체크리스트

국가사이버안보센터 보안권고(3/31.) 이슈 기준 · 영향 범위 확인 → 점검 → 복구 → 재발 방지

개요

핵심 요약 LiteLLM의 특정 버전(1.82.7, 1.82.8)이 공식 배포 경로(PyPI)에서 악성 코드가 포함된 상태로 유포된 정황이 공유되었습니다.
해당 버전은 자격 증명(환경변수, API 키, 클라우드 키, SSH 키 등) 탈취 및 외부 전송 시도가 문제로 지적되며, 운영 환경에서는 “설치 여부 확인”과 “비밀정보 회전(rotate)”이 최우선입니다.

본 문서는 “일반오류형(확장형 매뉴얼)” 흐름으로, 조직 내 서버/개발PC/CI 파이프라인에 LiteLLM이 포함되었을 가능성을 기준으로 작성했습니다. 실제 사용 시에는 “직접 설치”뿐 아니라 “간접 의존성(트랜지티브)”도 함께 보셔야 합니다. 실무 기준으로 보면, 이 유형은 패키지 교체만으로 끝나지 않고 키/토큰 교체가 동반되어야 안전합니다.

관련 공지 확인(운영 시 참고) LiteLLM 측 보안 업데이트: docs.litellm.ai
보호나라(KISA) 공지(제품 사용 주의 권고): boho.or.kr

환경

• Python 패키지 설치 경로: pip install litellm (또는 요구사항 파일/빌드 스크립트에서 설치)
• 빌드/배포: CI/CD(GitHub Actions, GitLab CI, Jenkins 등)에서 패키지 설치 후 이미지 빌드
• 컨테이너: Dockerfile 내 pip install 수행 또는 런타임 설치
• 간접 의존성: 에이전트/오케스트레이션 도구, 플러그인/서버(MCP 등)에서 LiteLLM이 끌려올 수 있음
• 주요 보호 대상: API 키(LLM 공급자), 클라우드 키(AWS/GCP/Azure), DB 계정, SSH 키, 쿠버네티스 토큰/시크릿

증상

이상 징후(있으면 “심화 분석”으로 즉시 이동) 1) 설치/업데이트 이력에 litellm==1.82.7 또는 litellm==1.82.8 존재
2) 서버/개발PC에서 평소와 다른 외부 통신(특히 빌드/실행 직후) 증가
3) 갑작스러운 API 키 오남용/과금 급증, 클라우드 리소스 비정상 생성
4) CI 로그에서 “버전 고정 없이 설치”된 흔적(예: pip install litellm 단독)
5) 코드 변경 없이 인증 실패/권한 오류가 늘어남(키 탈취 후 공격자가 먼저 회전했을 가능성 포함)

1차 점검

1) 설치 여부/버전 확인

# 서버/개발PC
pip show litellm

# 가상환경 목록이 많다면(예시)
python -c "import pkgutil; print('litellm' in [m.name for m in pkgutil.iter_modules()])"

2) 위험 버전 즉시 차단

권고 방향(조직 정책에 따라 택1) (A) 안전 버전으로 업그레이드: LiteLLM 측 공지 기준으로 v1.83.0 이상 사용(검증된 릴리스 기준)
(B) 보수적 다운그레이드: 1.82.6 이하로 낮추고(조직 검증 완료 버전) 즉시 키/토큰 회전 진행
※ 운영 정책상 “상향 업데이트 승인 절차”가 오래 걸리면, 우선 (B)로 서비스 안정화 후 (A)로 이행하는 전략도 가능합니다.

# 제거 후 재설치(예시)
pip uninstall -y litellm

# 업그레이드(예시)
pip install -U "litellm>=1.83.0"

# 또는 다운그레이드(예시)
pip install -U "litellm<=1.82.6"

3) 비밀정보 회전(가장 중요)

회전 대상 체크 LLM 공급자 API 키(OpenAI/Anthropic/Google 등)
클라우드 키(AWS Access Key, GCP SA 키, Azure SP 비밀값)
Git 토큰(GitHub PAT 등), 레지스트리 토큰, CI 비밀값(Secrets/Variables)
DB 계정/비밀번호, SSH 키(배포키 포함), K8s Secret/Token
※ “패키지 제거”만 하고 키 회전을 안 하면, 이미 유출된 키로 2차 피해가 이어질 수 있습니다.

4) 영향 범위 빠른 스코프 확장

• 요구사항 파일: requirements.txt, poetry.lock, pipfile.lock에서 litellm 검색
• CI 설정: 워크플로/파이프라인 YAML에서 pip install 구문과 버전 고정 여부 확인
• Dockerfile: 이미지 빌드 단계에서 버전 고정 없는 설치가 있는지 확인

심화 분석

1) 설치/업데이트 타임라인 확인

포인트 LiteLLM 측 업데이트에서는 문제가 된 PyPI 버전이 짧은 시간 동안 유포되었다는 안내가 있으며,
조직 내부 로그(빌드 로그/배포 로그/패키지 캐시)를 통해 “그 시간대에 설치가 발생했는지”를 우선 확인합니다.

2) 의심스러운 외부 통신(egress) 점검

• 방화벽/프록시/DNS 로그에서 빌드 노드·런타임 서버의 신규 도메인 접속 여부 확인
• CI 러너/빌드 서버에서 설치 직후 HTTP POST 요청 증가, 비정상적인 암호화/압축 트래픽 징후 확인
• 컨테이너 환경이라면: 빌드 단계(Builder)와 런타임 단계(Runtime) 각각 분리해서 네트워크 로그 확인

3) 파일/프로세스 흔적 점검(환경별)

운영 환경 기준으로 점검 범위 예시 (1) 해당 버전이 설치된 Python site-packages 경로 확인
(2) 실행 시점에 자동 로드되는 경로(.pth 등) 및 비정상 스크립트 생성 여부 확인
(3) 같은 호스트에서 API 키 파일(.env), SSH 키, K8s 설정(~/.kube) 접근 흔적 점검

4) “간접 의존성” 확인

# 현재 환경에서 의존성 트리 확인(도구에 따라 택1)
pip freeze | grep -i litellm

# pipdeptree 사용 시(설치되어 있다면)
pipdeptree | grep -i -n "litellm"

복구

1) 격리 및 교체

• 의심 호스트/러너를 네트워크 격리(가능하면 즉시)
• 위험 버전 제거 후 안전 버전으로 재배포(버전 고정 적용)
• 빌드 캐시/패키지 캐시 초기화(조직 정책에 맞춰 수행)

2) 비밀정보 회전(전면)

운영 우선순위(권장) 1) 외부 노출 시 피해가 큰 키(클라우드/결제/관리자 권한)부터 즉시 폐기/재발급
2) CI/레지스트리 토큰 교체 후 파이프라인 재서명/재배포
3) 서비스 계정/DB 계정 교체 및 접근 제어 점검
4) 교체 후 “기존 키가 더 이상 동작하지 않는지” 테스트로 확인

3) 침해 의심 시 대응

• 정황이 확인되면 내부 IR 절차(티켓/에스컬레이션/증적 보존) 즉시 개시
• 로그 보존(프록시/DNS/CI/서버 감사 로그) 및 포렌식용 스냅샷 확보
• 조직의 대외 신고/공유 프로세스에 따라 진행(공공/교육/기업 기준 상이)

재발 방지

1) 버전 고정과 검증을 “기본값”으로

실행 항목 요구사항 파일에 버전 고정(또는 lock 파일 운영)을 필수화
CI에서 “버전 미고정 설치”를 정책으로 차단(예: pip install litellm 단독 금지)
릴리스 승인 절차에 “공급망 사고 발생 시 긴급 예외 프로세스” 포함

2) 빌드/배포 단계 보안 강화

• 빌드 러너 격리(권한 최소화, 네트워크 egress 제한, 단기 토큰 사용)
• SBOM 생성 및 배포 아티팩트 서명/검증(가능한 범위부터 단계적으로)
• 의존성 다운로드를 내부 프록시/미러로 통제하고, 승인된 패키지만 통과

3) 키/토큰 운영 원칙 재정비

• 장기 고정 키 지양: 단기 토큰/워크로드 아이덴티티 우선
• 키 사용 범위 최소화(권한/리전/리소스 제한)
• 키 유출 탐지(이상 과금, 비정상 지역 접근, 대량 호출) 알림 룰 상시 운영

운영 환경에서는 “오픈소스 문제 → 패키지 교체”로 끝내기보다,
“비밀정보 회전 + egress 통제 + 의존성 통제”까지 묶어야 동일 유형의 공급망 사고에 반복 노출되지 않습니다.

빠른 체크리스트

• [ ] 우리 조직에 litellm==1.82.7 / 1.82.8 설치 이력이 있는가
• [ ] CI/CD, Dockerfile, requirements/lock 파일에 “버전 미고정 설치”가 있는가
• [ ] 해당 환경에서 사용된 API 키/클라우드 키/CI 토큰을 회전했는가
• [ ] 빌드 노드 및 런타임 서버의 egress 로그를 확인했는가
• [ ] 재발 방지로 버전 고정/정책 차단/승인 절차를 적용했는가