최근 한 달여 사이에 보안 사고가 연달아 터졌다.
3월 24일, litellm이라는 Python 라이브러리의 PyPI 패키지에서 공급망 공격이 발견됐다.
litellm 1.82.7, 1.82.8 버전이 영향을 받았는데, GitHub에는 존재하지 않는 버전이 PyPI에 직접 올라간 거다.
정상 릴리스 프로세스를 완전히 우회한 악성 배포였다.
이게 무서운 이유는, 설치만 되면 .pth 파일이 Python 프로세스가 시작될 때마다 자동 실행된다는 것이다.
SSH 키, .env 파일, AWS/GCP/Azure 인증 정보, K8s 설정, DB 비밀번호, 쉘 히스토리까지 전부 수집한다.
수집한 데이터를 AES-256-CBC로 암호화해서 외부 도메인으로 전송하고, K8s 서비스 어카운트 토큰이 있으면 클러스터 전체 시크릿을 읽고 백도어 Pod를 생성하는 "횡이동"(Lateral Movement)까지 시도한다.
litellm은 OpenAI, Claude, Gemini 등 여러 LLM API를 통합 호출해주는 프록시 라이브러리다.
직접 쓰지 않더라도 다른 패키지의 의존성으로 딸려 설치될 수 있다.
실제로 Cursor의 MCP 플러그인 의존성으로 딸려 들어와서 발견된 케이스도 있다.
이게 끝이 아니었다.
3월 31일, 이번엔 axios에서 공급망 공격이 확인됐다.
axios 리드 메인테이너의 npm 계정이 탈취돼서, GitHub CI/CD를 우회하고 npm CLI로 직접 악성 버전이 수동 배포됐다.
영향받는 버전은 axios 1.14.1과 0.30.4.
두 버전 모두 plain-crypto-js@4.2.1이라는 가짜 의존성을 주입하는데, 이 패키지는 axios 소스코드 어디에서도 import하지 않고 postinstall 스크립트로 악성코드(RAT, 원격 접근 트로이목마)를 실행하는 게 유일한 목적이다.
OS 임시 폴더와 Windows ProgramData에 페이로드 파일을 복사하고, 외부 C2 서버와 통신하면서 OS별 2차 페이로드를 받아오고, 실행 후 자기 자신을 삭제해서 포렌식 증거를 없앤다.
설치만 되면 키들이 전부 탈취될 수 있다.
같은 시기, 다른 축에서도 사고가 터졌다.
2월 중순에는 Chrome 취약점(CVE-2026-2441)이 공개됐다.
악성 HTML 페이지를 렌더링하는 것만으로 브라우저 샌드박스 내부 코드 실행으로 이어질 수 있었고, 이미 실제 악용 정황이 확인돼 즉시 업데이트가 필요했다.
이건 공급망 공격과는 다른 축이다.
AI가 직접 만든 위험이 아니라 원래 있던 기본 보안 운영 부담인데, AI 도구 리스크는 이 부담 위에 추가된다.
AI 자체가 문제가 아니라, AI 도구를 둘러싼 의존성 체인과 실행 환경이 완전히 공격 표면이 되었다.
이건 "AI 네이티브"를 지향하는 조직일수록 더 심각한 문제가 된다.
요즘 많은 조직이 "AI 네이티브"를 지향한다.
전 직원이 Cursor를 쓰고, Claude Code를 쓰고, MCP 플러그인을 설치하고, npm 패키지를 받고, pip install을 한다.
개발자가 아닌 사람도 AI 도구를 쓰기 위해 터미널을 열고 패키지를 설치한다.
이건 그 자체로는 좋은 일이다.
하지만 한 가지 문제가 있다.
AI 도구를 설치한다는 건, 의존성 체인 위에 올라탄다는 뜻이다.
litellm을 직접 쓰지 않아도, Cursor MCP 플러그인이 litellm을 의존성으로 가져올 수 있다.
axios를 직접 쓰지 않아도, 어떤 MCP 서버가 내부에서 axios를 쓰고 있을 수 있다.
실제로 axios 사건 직후, Datadog의 CI/CD 도구인 datadog-ci와 serverless-plugin-datadog, junit-upload-github-action도 점검 대상이 됐다.
세 도구 모두 axios를 의존성으로 가지고 있어서, 악성 버전이 배포된 3월 31일 새벽 시간대에 fresh install이 일어난 CI 환경이나 개발 머신이라면 영향을 받았을 수 있다.
Datadog은 인프라 모니터링 도구다.
보안을 지키기 위해 설치한 모니터링 도구의 의존성이 오히려 공격 경로가 된 셈이다.
전 직원이 AI 도구를 설치하면, 전 직원의 머신이 공급망 공격의 표면이 된다.
그리고 그 중에는 SSH 키가 뭔지 모르는 사람도 있고, .env 파일이 왜 위험한지 모르는 사람도 있다.
보안팀이 빵빵한 조직이라면 이걸 감당할 수 있다.
전 직원의 머신에 EDR(Endpoint Detection and Response)을 깔고, 패키지 설치를 모니터링하고, 이상 행위를 탐지하고, 사고가 나면 즉시 격리하고 복구할 수 있다.
그런데 보안/데브옵스 인력이 충분하지 않은 조직이라면?
litellm 사건이 터졌을 때, 전 직원의 머신에서 pip show litellm을 확인하고, ~/.config/sysmon/sysmon.py 파일이 있는지 점검하고, 영향이 확인되면 "모든 인증 정보를 탈취당한 것으로 간주"하고 SSH 키, 클라우드 크레덴셜, API 키, DB 비밀번호를 전체 로테이션해야 한다.
axios 사건이 터졌을 때는, 모든 프로젝트의 lockfile에서 axios 1.14.1이나 0.30.4가 있는지 확인하고, node_modules/plain-crypto-js/가 있는지 확인하고, 감염된 머신의 모든 크레덴셜을 교체해야 한다.
크롬 제로데이가 나왔을 때는, 전 직원에게 브라우저 업데이트를 즉시 공지하고, 업데이트 여부를 확인해야 한다.
이걸 한 달 사이에 세 번이나 해야 한다.
그리고 이런 빈도는 앞으로 더 잦아질 것이다.
보안 전담 인력 없이 이걸 할 수 있는 조직이 얼마나 될까.
그래서 상방과 하방 사이의 딜레마가 생긴다.
상방을 열면 하방이 부실해진다.
전 직원에게 AI 도구를 열어주고, 생산성을 끌어올리고, 경쟁사보다 빠르게 움직이려는 건 좋다.
하지만 보안팀이 빵빵하지 않으면, 한 달 사이에 세 번이나 터지는 전사 대응을 감당할 수가 없다.
반대로 하방을 단단히 지키려고 하면 상방이 닫힌다.
충분한 지식을 가진 사람만 도구를 설치하고, 의존성을 통제하고, 환경을 관리하면 보안은 지킬 수 있다.
하지만 그러면 "전 직원이 AI를 자유롭게 쓰는 조직"과는 거리가 멀어진다.
AI 네이티브 조직이 되고 싶은데, 정작 AI 도구를 자유롭게 쓸 수 없는 아이러니가 생긴다.
상방을 열자니 하방이 너무 부실해지고, 하방을 단단히 하자니 상방이 너무 닫힌 구조로 간다.
이건 "정답이 있는 문제"가 아니라 "각 조직이 자기 상황에 맞게 어디쯤에 서야 하는지 고민해야 하는 문제"다.
보안/데브옵스 인력이 충분한 조직과 그렇지 않은 조직의 답이 같을 수 없고, 다루는 데이터의 민감도에 따라서도 답이 달라진다.
다만 한 가지 분명한 건, 이 고민 자체를 하지 않는 조직이 제일 위험하다는 것이다.
"우리도 AI 네이티브 해야지"라는 상방의 매력에만 끌려서, 하방이 어떤 상태인지 돌아보지 않는 것.
그게 가장 큰 리스크다.
litellm, axios, 크롬 제로데이까지 한 달여 사이에 연달아 터진 이 사건들은 앞으로도 빈도는 줄어들지 않을 것 같다.
AI 도구의 생태계가 커질수록 공격 표면도 같이 커지니까.
AI 네이티브 조직일수록, 상방만큼 하방도 충분히 고민해봐야 한다.
