당신이 신뢰했던 그 PyPI 패키지? 네, 침해되었습니다

공급망 공격 (Supply chain attacks)에 대해 알아야 할 점은 이것입니다. 공격자들은 당신의 화려한 인증 시스템이나 제로 트러스트 네트워크 (Zero-trust network)에는 관심이 없습니다. 그들은 단지 관리자 한 명이 운 나쁜 하루를 보내기만을 바랄 뿐입니다.

지난주, litellm v1.82.7 및 v1.82.8 버전이 PyPI에 게시되었습니다. 만약 해당 버전들이 게시되어 있던 시간 사이에 pip install을 통해 설치했다면, 침해된 패키지를 가져온 것입니다.

무슨 일이 일어났는지, 왜 이것이 중요한지, 그리고 당신이 영향을 받았는지 어떻게 확인할 수 있는지 자세히 살펴보겠습니다.

타임라인

• v1.82.7 게시 — 정상적으로 보이고 정상적으로 작동하지만, 침해된 CI/CD 파이프라인으로부터 주입된 코드를 포함하고 있음
• v1.82.8 게시 — 동일한 문제, 다른 버전 번호
• 커뮤니티의 이상 징후 감지 — 누군가가 자신의 litellm 프로세스에서 예상치 못한 외부 연결 (Outbound connections)을 발견함
• BerriAI 조사 — 침해 사실을 발견하고 몇 시간 이내에 PyPI에서 두 버전을 모두 삭제함
• 현재 상태 — v1.82.9+ 버전은 안전합니다. 문제가 된 패키지들은 삭제되었습니다.

근본 원인은 무엇일까요? Trivy 공급망 파이프라인 (Supply-chain pipeline)이 침해되었습니다. 특정 의존성 (Dependency)의 오타 때문도 아니고, 개발자의 노트북이 해킹당한 것도 아닙니다. 패키지를 빌드하고 게시하는 실제 CI/CD 파이프라인이 침해된 것입니다.

침해된 코드가 수행한 작업

전체 역컴파일된 페이로드 (Decompiled payload)를 확인하지는 못했지만, 이러한 공격에서 일반적으로 발생하는 일은 다음과 같습니다:

# 침해된 post-install hook의 단순화된 예시
# 이것은 실제 페이로드가 아니라 패턴일 뿐입니다
import os
...

보통 다음과 같은 작업을 수행하는 setup.py post-install hook 형태입니다:

1. OPENAI_API_KEY, ANTHROPIC_API_KEY, AWS_ACCESS_KEY_ID 등을 스캔합니다.
2. 이를 하나로 묶습니다.
3. 공격자가 제어하는 엔드포인트 (Endpoint)로 전송합니다.

무서운 점은 무엇일까요? 당신의 pip install이 이를 자동으로 실행했다는 것입니다. 사용자의 상호작용이 전혀 필요하지 않았습니다.

영향을 받았는지 확인하는 방법

# 현재 litellm 버전을 확인하세요
pip show litellm | grep Version

...

하지만 "아마 괜찮을 것"이라는 말에는 문제가 있습니다. 단순히 버전 번호만 확인해서는 안 됩니다. 침해로 인해 다음과 같은 일이 발생했을 수 있기 때문입니다:

1. API 키 교체 (Rotated your API keys) — 공격자가 이제 해당 키를 보유하고 있습니다.
2. 데이터베이스 자격 증명 유출 (Exfiltrated database credentials) — 만약 환경 변수 (env vars)에 저장되어 있었다면 유출되었습니다.
3. 지속성 메커니즘 설치 (Left persistence mechanisms) — cron 작업 (cron jobs)이나 수정된 시작 스크립트 (startup scripts) 등을 남겨두었을 수 있습니다.

수동 해결 방법 (The Manual Fix)

# 1단계: 침해된 패키지 제거
pip uninstall litellm

...

이것이 실제로 의미하는 바

이것은 litellm에만 국한된 문제가 아닙니다. 이것은 **"우리 모두는 오픈 소스 패키지에 의존하고 있으며, 그들의 CI/CD 파이프라인 (CI/CD pipelines)은 공격 표면 (attack surfaces)이다"**라는 문제입니다.

동일한 공격 벡터 (attack vector)가 다음 대상들에게도 작동합니다:

• 자동 게시 기능이 있는 모든 PyPI 패키지
• CI/CD 자동 배포 기능이 있는 모든 npm 패키지
• 침해된 베이스 이미지로부터 빌드된 모든 Docker 이미지

익숙하게 들리시나요? 익숙해야 합니다. 이것은 event-stream npm 사건, colors 및 faker 사보타주(sabotage), 그리고 제가 셀 수 없을 정도로 많이 겪었던 수십 가지의 다른 사건들과 동일한 패턴입니다.

스스로를 보호하는 방법

단기적 대책:

• 의존성 (dependencies)을 특정 버전으로 고정 (Pin) 하세요.
• 락파일 (lockfile)과 함께 pip install --require-hashes를 사용하세요.
• 예상치 못한 외부 연결 (outbound connections)이 있는지 환경을 모니터링하세요.

장기적 대책:

• 새 버전에 대해 수동 승인 절차를 거치는 자체 내부 PyPI 미러 (PyPI mirror)를 운영하세요.
• 의존성을 캐싱하고 차이점 검사 (diff-check)를 수행하는 컨테이너 빌드를 사용하세요.
• 예상치 못한 프로세스 동작에 대해 경고를 보내는 런타임 모니터링 (runtime monitoring)을 구현하세요.

# 예시: 해시값이 포함된 requirements.txt 생성
pip freeze --require-hashes > requirements-hashed.txt

...

아무도 이야기하지 않는 부분

공격자는 BerriAI의 GitHub에 침입할 필요가 없었습니다. 유지 관리자 (maintainer)를 대상으로 사회 공학 (social-engineer) 기법을 쓸 필요도 없었습니다. 그들은 패키지를 빌드하고 배포하는 자동화 시스템인 **CI/CD 파이프라인 (CI/CD pipeline)**을 침해했습니다.

그것이 가장 무서운 부분입니다. 대부분의 팀은 보안 예산을 빌드 파이프라인이 아닌 프로덕션 인프라 (production infrastructure)에 사용하기 때문입니다. 그리고 빌드 파이프라인은 모든 것에 접근할 수 있는 권한을 가지고 있습니다.

다음에 어떤 일이 벌어질지 예상되시나요?

누군가는 또 다른 파이프라인 취약점(vulnerability)을 찾아낼 것입니다. 이번에는 npm일 수도 있고, GitHub Actions 러너(runner)일 수도 있습니다. 혹은 여러분 회사의 내부 패키지 레지스트리(internal package registry)일 수도 있습니다.

해결책은 "오픈 소스를 사용하지 마라"가 아닙니다. 해결책은 "CI/CD 파이프라인을 프로덕션 환경(production environment)처럼 취급하라"는 것입니다. 왜냐하면 그것이 공격자가 타격할 수 있는 가장 가치 있는 목표이기 때문입니다.

여러분의 pip freeze 출력 결과를 확인하세요. 키(key)들을 교체(rotate)하세요. 그리고 금요일에는 프로덕션 의존성(production dependencies)을 자동 업데이트하지 않는 것이 좋습니다.

AI 에이전트(AI agents)를 디버깅하는 것이 마치 매트릭스(The Matrix)를 읽는 것처럼 느껴져서는 안 됩니다.
신뢰할 수 있는 자율 워크플로우(autonomous workflows)를 구축하고 있는 다른 엔지니어들과 함께 저희 커뮤니티에 참여하세요: TracePilot Discord