오픈소스 라이브러리 한 줄을 가져다 썼을 뿐인데, 우리 회사 클라우드 자격 증명이 외부로 새어 나가는 일이 가능할까요?

지난 2026년 3월, Python 패키지 저장소 PyPI에서 실제로 그런 일이 일어났습니다. litellm이라는 라이브러리에 악성 코드가 포함된 버전이 배포됐고, 이 패키지를 설치한 환경의 환경 변수와 API 토큰까지 빨려나갈 수 있는 구조였죠.

흥미로운 건 공격이 시작된 곳이 litellm 자체가 아니었다는 점인데요. 공격자는 패키지를 직접 손대지 않았어요. 대신 그 패키지를 배포하던 CI/CD 파이프라인을 먼저 침해해서, 정식 경로로 악성 버전을 올렸습니다.

이번 글에서는 litellm 사건이 어떤 구조로 일어났는지 짚어보고, 우리 회사 CI/CD를 같은 패턴으로부터 지키기 위해 인프라 관점에서 무엇을 점검해야 하는지 정리해 드릴게요!

PyPI litellm 사건, 무슨 일이 있었나요?

2026년 3월 24일, PyPI에서 배포되던 litellm 패키지에 악성 코드가 포함된 버전이 발견됐습니다.

litellm은 OpenAI·Anthropic·Gemini 같은 여러 LLM API를 하나의 인터페이스로 호출할 수 있게 해주는 Python 라이브러리예요. 요즘 AI 기능을 백엔드에 붙이는 회사라면 한 번쯤 만져보는 패키지인 만큼, 영향 범위가 크다는 점에서 큰 주목을 받았습니다.

이 사건에서 주목할 점은 패키지 코드 자체에 취약점이 있던 게 아니라, litellm을 PyPI에 올리던 배포 파이프라인이 먼저 침해됐다는 점입니다.

좀 더 정확히 풀어보면 이런 순서로 일어났습니다.

왜 이런 공급망 공격이 가능했을까요?

요즘 공급망 공격은 개발과 배포 과정 전체를 하나의 연결된 신뢰 체인(Trust Chain)으로 보고, 그중 가장 약한 연결을 노려 침투하는 구조로 행해집니다.

현대 소프트웨어 개발 환경을 떠올려볼게요. 우리 회사 개발팀은 외부 오픈소스 라이브러리를 패키지 매니저로 가져다 쓰고, CI/CD 파이프라인이 빌드·테스트·배포를 자동으로 하고, 각 단계 사이에 외부 SaaS와 클라우드 API가 연동돼 있을 거예요. 이 구조가 업무 생산성을 높여주긴 하지만 외부 의존이 늘어난다는 의미이기도 합니다.

특히 GitHub Actions처럼 서드파티 Action을 적극적으로 가져다 쓰는 환경은 이 위험을 더 키웁니다. Action은 본질적으로 외부에서 만든 코드를 우리 회사 빌드 환경 안에서 실행하는 구조니까요. 평소엔 편리하지만, 그 Action 하나가 변조되는 순간 우리 회사 파이프라인의 자격 증명·소스코드·빌드 결과물이 동시에 위험해질 수 있습니다.

이번 litellm 사건이 단적인 예시예요. 공격자는 litellm 코드를 직접 손대지 않았고, 그 패키지를 배포하던 파이프라인의 의존 도구(Trivy Action) 하나만 공격했습니다. 그게 자격 증명을 노출시키고, 자격 증명이 패키지 배포 권한을 열고, 그 권한이 다시 수많은 후속 환경으로 공격 영향을 퍼뜨렸습니다.

그래서 공급망 공격 방어는 애플리케이션 보안만으로는 부족합니다. 개발 파이프라인 자체를 하나의 보안 영역으로 보고, 그 안의 자격 증명·외부 코드·권한 부여 범위를 다시 들여다봐야 해요.

우리 회사 CI/CD를 지키는 3가지 방법