4월, 2026의 블로그

2026년 3월 24일 발생한 LiteLLM 공급망 침해는 고립된 사건이 아닙니다.

이는 JFrog Security Research가 수년간 추적해 온, 진화하는 공격자 플레이북의 가장 최근 사례이자 어쩌면 가장 위험한 사일 수 있습니다.

이제 공격 대상은 개발자에서, 개발자가 소프트웨어를 구축하기 위해 의존하는 AI 에이전트로 옮겨갔습니다.

개발자는 늘 공격의 표적이었습니다

공급망 공격은 단순한 공식을 따릅니다. 신뢰받는 오픈소스 패키지를 찾고, 그것을 오염시킨 뒤, 생태계가 그 배포를 대신하게 만드는 것입니다.

2025년 9월 처음 보고되었고 JFrog Security Research 팀이 광범위하게 분석한 Shai-Hulud는 그 좋은 사례였습니다.

npm 패키지에 삽입된 자기복제 웜을 기반으로, 이 공격은 개발자 토큰을 탈취하고 해당 개발자들이 유지 관리하던 다른 패키지들까지 자동으로 다시 감염시키도록 설계되었습니다.

공격자의 직접적인 개입 없이 기하급수적으로 확산되었기 때문에, 이는 기록상 가장 심각한 자바스크립트 공급망 공격 중 하나로 평가되었습니다.

조직이 이러한 유형의 위협으로부터 스스로를 보호할 수 있도록, JFrog Curation은 악성 및 취약한 오픈소스 패키지가 개발자 환경에 도달하기 전에 차단하는 자동화된 게이트키핑 계층을 제공합니다.

SDLC는 변화하고 있으며, 공격 표면도 함께 바뀌고 있습니다.

개발자 자체뿐 아니라, 악의적인 행위자들은 AI가 생성한 코드에서도 취약점을 찾아내고 있습니다. 이제 소프트웨어 개발자는 더 이상 자신의 코딩 역량에만 의존하지 않습니다.

대신 코드 생성, 테스트, 리서치, 배포를 위해 여러 AI 에이전트를 동시에 운영하고 있습니다. 개발 수명주기는 인간이 주도하는 선형적인 흐름에서, 분산된 멀티 에이전트 파이프라인으로 진화했습니다.

AI 생성 코드 이전

AI 생성 코드 이후

이제 각 개발자는 여러 에이전트를 병렬로 실행할 수 있으며, 각 에이전트는 AI 패키지, MCP 서버, 모델, 스킬과 상호작용합니다. 그 결과 공격 표면은 빠르게 확장되고 있습니다.

에이전트가 어떻게 작동하는지 이해하는 것은 이러한 새로운 공격 표면을 이해하는 데 중요합니다.

AI 에이전트는 단일 모델이 아니라 여러 AI 구성요소가 결합된 구조입니다.

그 중심에 있는 LLM
그 동작 방식을 형성하는 룰과 메모리
에이전트가 실행할 수 있는 스킬
외부 시스템 및 데이터와 연결해 주는 MCP 서버

이 구성요소 각각은 모두 잠재적인 공격 경로이자 위험 요소입니다.

AI 에이전트의 구조

에이전트가 이제 새로운 표적이 되었습니다

공급망 통제로 개발자 환경을 오염시키는 것이 더 어려워지나, 공격자들은 방향을 틀었습니다. 개발자를 뚫을 수 없다면, 그들이 사용하는 도구를 노리면 되기 때문입니다.

2025년 9월, postmark-mcp: 실제 환경에서 발견된 최초의 악성 MCP 서버

공격자는 정상적인 Postmark MCP 저장소를 복제한 뒤, 거의 동일한 npm 패키지를 배포했습니다. 15개 버전 동안 이 패키지는 아무 문제 없이 작동했고, 수백 개의 워크플로우에서 개발자들의 신뢰를 받았습니다.
그러다 버전 1.0.16에서 단 한 줄의 코드가 추가됐습니다. 숨겨진 BCC 기능이 삽입된 것입니다. 이 코드는 MCP 서버를 통해 전송되는 모든 이메일을 공격자가 제어하는 도메인으로 조용히 전달했습니다.
비밀번호 재설정 메일, 청구서, 내부 메모까지, 커넥터를 전적으로 신뢰하고 있던 AI 에이전트 워크플로우 내부에서 은밀하게 유출되었습니다.

이 공격이 특히 위험했던 이유는 MCP 서버가 에이전트 툴체인 안에서 높은 수준의 신뢰와 광범위한 권한을 가지고 실행되기 때문입니다. 악성 MCP 서버는 단순히 하나의 코드베이스를 오염시키는 데 그치지 않습니다.

그것은 전체 AI 기반 워크플로우와 연결된 모든 시스템을 조작할 수 있는, 지속적인 상위 제어 지점이 됩니다.

postmark-mcp 공격은 경고탄이었습니다. LiteLLM 침해는 그보다 한 단계 더 격화된 사건이었습니다.

LiteLLM 공격: 한층 더 정교해진 수준

LiteLLM은 AI 생태계에서 가장 중요한 패키지 중 하나로, OpenAI, Anthropic, AWS Bedrock, Google VertexAI를 포함한 100개 이상의 LLM API로 연결되는 범용 게이트웨이 역할을 합니다.

이 패키지는 하루 약 340만 건의 다운로드를 기록하고 있으며, 클라우드 환경의 36%에 존재합니다. 또한 MCP 플러그인과 AI 에이전트 프레임워크에서 흔히 사용되는 필수 종속석 패키지이기 때문에 공격 대상이 되었습니다.

자세한 내용은 JFrog Security Research의 전체 기술 분석 보고서를 참고하시기 바랍니다.

이번 공격은 Aqua Security의 Trivy 스캐너와 Checkmarx의 KICS GitHub Action을 해킹한 TeamPCP에 의해 수행되었습니다.
이는 우발적인 공격이 아니라, 조직적이고 연쇄적인 공격 캠페인이었습니다.

어떻게 발생했는가

LiteLLM의 CI/CD 파이프라인은 빌드 과정의 일부로 Trivy를 실행하고 있었으며, 버전은 고정되어 있지 않았습니다. 3월 19일, TeamPCP는 이미 Trivy의 GitHub Action을 침해한 상태였습니다.

이후 LiteLLM의 빌드가 실행되자, 손상된 Trivy 액션은 GitHub Actions 러너에서 프로젝트의 PyPI 게시 토큰을 유출했습니다.

이 자격 증명을 손에 넣은 공격자들은 3월 24일 아침, LiteLLM의 정상적인 릴리스 워크플로우를 완전히 우회하는 악성 페이로드가 포함된 litellm 1.82.7 및 1.82.8 버전을 게시했습니다.

악성코드는 무엇을 했는가

실행이 시작되면, 이 페이로드는 3단계 공격을 수행했습니다.

SSH 키, AWS, GCP 및 Azure 클라우드 토큰, Kubernetes 시크릿, 암호화폐 지갑, .env파일 등의 자격 증명을 수집
Kubernetes 클러스터 전체에 걸쳐 권한 있는 Pod를 모든 노드에 배포하여 클러스터 간 수평 이동을 시도
공격자가 제어하는 인프라에서 추가 바이너리를 주기적으로 수집하는 영구적인 systemd 백도어를 설치. 수집된 모든 데이터는 암호화되어 models.litellm.cloud합법적인 LiteLLM 인프라를 사칭하는 도메인(공격 당일 등록된 도메인)으로 유출되었습니다.

특히 1.82.8 버전은 Python의 .pth 파일 메커니즘을 악용했기 때문에 더욱 공격적이었습니다.

이 메커니즘은 LiteLLM이 명시적으로 import되지 않더라도, Python 인터프리터가 시작될 때마다 실행됩니다. 또한 이 페이로드는 정적 분석을 피하기 위해 이중 base64 인코딩 처리되어 있었습니다.

어떻게 발견되었는가 – 에이전트 내부에서

이 공격은 Cursor 내부에서 실행 중이던 MCP 플러그인이 전이 의존성으로 해당 패키지를 가져오면서 처음 발견되었습니다.
한 연구원의 머신이 RAM 고갈로 인해 응답하지 않게 되었는데, 이는 악성코드 자체의 포크밤(Fork bom) 버그로 인한 부작용이었습니다.

즉, 사람이 의식적으로 설치하기도 전에 악성 패키지가 AI 에이전트의 런타임까지 도달한 상태였습니다.

조직에 미치는 영향

LiteLLM은 일반적으로 애플리케이션과 여러 AI 서비스 제공자 사이에 직접 위치하기 때문에, 조직의 전체 AI 스택에 대한 API 키, 환경 변수, 민감한 구성 데이터를 보유하게 됩니다.

따라서 단 한 번의 손상된 설치만으로도, 조직이 사용하는 모든 AI 서비스의 자격 증명이 노출될 수 있습니다. 그리고 그 범위는 LiteLLM이 실행되는 모든 환경, 즉 개발자 머신, CI/CD 파이프라인, 스테이징, 운영 환경 전체에 걸칩니다.

해당 악성 버전은 약 3시간 동안 PyPI에 게시된 상태로 존재했습니다. 패키지의 다운로드 규모를 고려하면, 그 시간 동안의 잠재적 노출 범위는 상당했습니다.

명확한 패턴

공격	벡터	목표
Shai-Hulud(npm)	오픈소스 패키지에서 발견된 자가 복제 웜	개발자 환경
postmark-mcp(npm)	악성 MCP 서버	AI 에이전트 워크플로
LiteLLM(PyPI)	손상된 CI 도구를 통해 악성 AI 인프라 패키지가 배포	에이전트 런타임 + CI/CD

공격 대상 범위가 넓어졌을 뿐만 아니라, 각 개발자가 실행하는 에이전트 수만큼 증가했습니다. 단 하나의 AI 종속성이 손상되면 에이전트가 동시에 작동하는 모든 환경으로 파급 효과가 발생할 수 있습니다.

오픈소스 AI 게이트웨이의 문제

생태계 안에서 LiteLLM이 맡고 있는 역할은 면밀히 살펴볼 필요가 있습니다. LiteLLM은 본질적으로 애플리케이션과 모든 LLM API 사이에 위치하는 단일 라우팅 계층을 사용하는 오픈 소스 AI 게이트웨이입니다.

이러한 아키텍처적 위치는 매우 강력하지만, 동시에 매우 매력적이고 파괴적인 공격 경로가 될 수 있는 요인이기도 합니다.

모든 AI 트래픽을 단일 오픈소스 패키지를 통해 라우팅한다는 것은, 그 패키지의 무결성, 그 패키지를 유지 관리하는 사람들의 보안 관행, 그리고 그것을 배포하는 파이프라인에 지대한 신뢰를 두는 일입니다.

LiteLLM 침해 사건은 그 신뢰가 얼마나 취약할 수 있는지를 보여주었습니다. CI 워크플로우 안에서 버전이 고정되지 않은 단 하나의 의존성만으로도, 공격자에게 조직 전체 AI 인프라의 열쇠가 넘어갈 수 있었습니다.

여기에는 모든 모델 API 키, 모든 클라우드 자격 증명, 그리고 해당 환경 내 모든 비밀정보가 포함됩니다.

물론 이것이 AI 게이트웨이의 강점을 활용하지 말라고 주장하는 것은 아닙니다. 다만 우리는 그것을 올바른 보안 기반 위에서 구축해야 한다는 점을 강조하고 싶습니다.
여러분의 에이전트형 공급망 중심에 위치하는 AI 게이트웨이라면, 공용 레지스트리에서 가져와 잘 되기만을 바라는 방식이 아니라, 엔터프라이즈급 통제를 바탕으로 관리되어야 합니다.

신뢰할 수 있는 에이전트형 공급망 구축

해답은 AI 도입 속도를 늦추거나 금지하는 것이 아닙니다. 해답은 AI 계층을 맹목적으로 신뢰하는 일을 멈추고, 나머지 소프트웨어 공급망에 적용해 온 것과 동일한 수준의 엄격함으로 이를 관리하기 시작하는 것입니다.

바로 이런 이유로, JFrog는 에이전트의 신뢰성은 에이전트가 소비하고, 구축하고, 배포하는 데이터만큼만 중요하다는 원칙을 기반으로 처음부터 설계된 JFrog AI Catalog 와 AI Gateway를 출시했습니다.

AI Gateway: 설계 단계부터 신뢰를 내장하다

단순히 트래픽을 라우팅하고 결과를 기다리는 오픈 소스 게이트웨이와 달리, JFrog AI 게이트웨이는 보안 정책이 적용된 연결 계층으로 설계되었습니다.

이 게이트웨이는 모델, MCP 서버, 에이전트 스킬 등 모든 AI 소비 대상을 하나의 중앙 통제 지점을 통해 라우팅함으로써, 전체 AI 사용 범위를 통합 거버넌스 아래에 둡니다.

또한 모든 요청이 인증되도록 보장하고, 하위 자산에 대한 접근이 허용되기 전에 각각이 충분히 검증되도록 합니다.

핵심적인 아키텍처적 차이점은 바로 이것입니다. JFrog AI 게이트웨이는 단순히 트래픽을 프록시하는 데 그치지 않고, 에이전트가 검증되지 않은 모델이나 MCP 서버에 접근하기 전에 연결 지점에서 신뢰를 구축합니다.

JFrog MCP Registry: 더 이상 맹목적인 신뢰는 없다

JFrog MCP Registry는 postmark-mcp와 LiteLLM이 보여준 바로 그 유형의 공격에 대한 직접적인 대응입니다.

JFrog는 오래전부터 소프트웨어 패키지를 관리하고 보호해 온 방식 그대로, MCP 서버 역시 스캐닝, 정책 강제, 버전 관리 기능이 내장된 완전히 통제 가능한 아티팩트로 다룹니다.

MCP Registry가 제공하는 핵심 기능은 다음과 같습니다.

설계 단계부터 보안을 강화하여, 침해 후 탐지하는 대신 에이전트가 악성 또는 규정을 준수하지 않는 MCP 서버를 다운로드하거나 실행하기 전에 사전에 차단합니다.
중앙 집중식 거버넌스 개발자는 공개 레지스트리에서 가져올 필요 없이 IDE(Cursor, Claude Code, VS Code)에서 사전 승인된 MCP 서버 레지스트리에 직접 액세스할 수 있습니다.
엔터프라이즈급 정책 시행으로 "맹목적인 신뢰"를 프로젝트 수준의 세부적인 권한 설정으로 대체하여 에이전트가 연결할 수 있는 MCP 서버를 정확하게 제어합니다.
로컬 MCP 게이트웨이는 개발자 컴퓨터에서 인증 및 권한 확인을 투명하게 처리하는 경량 프록시로, 코딩 에이전트가 사전 검증된 서버에만 연결되도록 보장합니다.

postmark-mcp 공격이 성공한 이유는 개발자가 공용 레지스트리에서 MCP 서버를 가져와 전적인 신뢰를 부여했기 때문입니다. LiteLLM 공격이 성공한 이유는 빌드 파이프라인이 버전 고정되지 않은 오픈소스 패키지를 암묵적으로 신뢰했기 때문입니다.

JFrog MCP Registry는 모든 MCP 서버를 통제되는 아티팩트로 다루고, 승인되지 않은 것은 입구에서 차단하기 때문에, 이런 상황이 개발자에게 경고 없이 발생할 수 없도록 설계되었습니다.

에이전트 기반 공급망 전체를 위한 단일 기록 시스템

더 큰 비전은 에이전트가 소비하고 생성하는 모든 계층을 통제하는 통합 기록 시스템를 구축하는 것입니다.

모델, MCP 서버, 에이전트 스킬, AI 생성 코드, 조립된 아티팩트까지 모두 한곳에서 관리하며, 더 넓은 소프트웨어 공급망에 적용되는 것과 동일한 보안 및 컴플라이언스 통제 아래 두는 것입니다.

JFrog는 이를 신뢰할 수 있는 에이전트형 공급망, 즉 Trusted Agentic Supply Chain이라고 부릅니다.

이는 불변성, 출처 추적, 정책 강제, 지속적인 스캐닝과 같이 수십 년간 소프트웨어 공급망을 지배해 온 원칙을, 에이전트가 의존하는 새로운 AI 자산군 전체로 확장한 개념입니다.

또한 이는 NVIDIA 같은 파트너와의 통합을 통해 검증되고 있으며, NVIDIA의 OpenShell 런타임은 엔터프라이즈 규모에서 검증된 AI 스킬을 배포하기 위한 관리형 엔드포인트로 JFrog Platform을 사용하고 있습니다.

JFrog가 에이전트형 공급망 보호를 지원하는 방법

JFrog와 협력하면, 다음과 같은 조치를 통해 최신 공급망 공격으로부터 조직을 보호하기 시작할 수 있습니다.

에이전트와 MCP 플러그인이 가져오는 전이적 의존성을 포함해 AI 의존성 체인을 감사하세요.
버전을 반드시 고정하세요. LiteLLM 공격은 공급망 여러 지점에서 버전이 고정되지 않은 의존성을 악용했습니다.
오픈소스 AI 게이트웨이를 본질적으로 신뢰할 수 있는 인프라로 취급하지 마세요. 정책 강제가 가능한 엔터프라이즈급 거버넌스 게이트웨이를 통해 AI 트래픽을 라우팅하세요.
MCP 서버를 통제하세요. JFrog MCP Registry를 사용해 에이전트가 검증되고 승인된 서버에만 연결할 수 있도록 하세요.
침해가 의심되는 경우에는 패키지 제거에 그치지 말고, 시스템 전체가 침해되었을 가능성을 전제로 자격 증명을 적극적으로 교체하세요.
신뢰할 수 있는 AI 카탈로그를 구축하세요. JFrog AI Catalog를 모델, MCP, 스킬, AI 패키지를 위한 단일 기록 시스템으로 활용하세요.

핵심 요약

SDLC(소프트웨어 개발 수명주기)가 변화했습니다. 개발자는 더 이상 파이프라인의 유일한 주체가 아니라, 기계 속도로 AI 자산을 소비하는 에이전트 플릿을 지휘하는 역할을 합니다.

공격자들은 개발자들이 활동하는 모든 새로운 환경, 심지어 에이전트 워크플로까지 추적합니다.

LiteLLM은 경종을 울리는 사건이었습니다. 이 사건은 AI 인프라의 중심에 있는 오픈 소스 AI 게이트웨이가 중립적인 인프라가 아니라 매우 가치 있는 공격 대상이라는 사실을 보여주었습니다.

문제는 여러분의 트러스트 모델이 이러한 현실에 대비되어 있느냐는 것입니다.

JFrog는 신뢰가 플랫폼에 내장되어야 하며, 당연한 것으로 전제되거나 사후에 덧붙여져서는 안 된다고 믿습니다.
이는 오픈소스 패키지를 큐레이션하고, AI 모델을 통제하며, 실행 전에 정책을 강제하는 레지스트리를 통해 MCP 서버를 보호하고, 신뢰를 최우선으로 두는 게이트웨이를 통해 모든 AI 트래픽을 라우팅하는 것을 의미합니다.

AI로 가속되는 세상에서, 속도는 그 기반이 신뢰할 수 있을 때에만 진정한 이점이 되기 때문입니다.

JFrog 솔루션에 대해 더 알고싶다면 커브에 문의하세요. 제품 소개 및 평가판 지원 또한 JFrog AI Catalog, JFrog MCP Registry, JFrog Curation에 대해서도 더 자세히 알아보실 수 있습니다.

출처 : From Shai-Hulud to LiteLLM: Supply Chain Attackers Are Coming for Your Agents by Yuval Fernbach, CTO, JFrog ML 2026. 3. 30.

블로그