AI 공급망 공격이란? 개발 파이프라인 보안 점검 체크리스트

AI 공급망 공격은 개발자가 직접 짠 코드가 아니라, 그 코드가 의존하는 오픈소스 패키지·빌드 도구·CI/CD 파이프라인을 노려 악성코드를 심는 방식이다. 2026년 들어 이 유형의 침해가 폭발적으로 늘었다. CloudSEK는 LiteLLM PyPI 패키지의 1.82.7·1.82.8 버전에 TeamPCP라는 위협 조직이 악성코드를 삽입한 사건을 "2026년 최대 규모 AI 공급망 침해"로 규정했는데, 침투 경로가 다름 아닌 빌드 파이프라인 내 Trivy 스캐너였다는 점에서 개발자들에게 충격을 줬다. 보안 스캐너 자체가 감염 경로가 됐다는 사실은, 지금까지 "믿고 쓰던" 도구조차 재점검이 필요하다는 신호다.

📌 핵심 요약

  • LiteLLM PyPI 침해로 2,500개 이상 기업, 약 43만 4천 개 CI/CD 파이프라인이 노출됐다 (CloudSEK)
  • 2026년 상반기 공급망 공격은 37개 캠페인·497개 악성 패키지로, 전년 대비 캠페인 2.6배·패키지 4.5배 증가했다 (Phoenix Security)
  • 59개 캠페인 전수 조사 결과 CVE 등록 건수는 0건 — 기존 취약점 스캐너로는 탐지되지 않는다
  • Mini Shai-Hulud 웜은 npm·PyPI 172개 패키지·404개 악성 버전을 감염시키며 Mistral AI, TanStack 등 AI 생태계를 표적으로 삼았다
  • FBI는 2026년 7월 FLASH 권고를 통해 LiteLLM 관련 탈취 자격증명이 장기간 악용될 수 있다고 경고했다

AI 공급망 공격이란 무엇인가 – 정의와 작동 원리

AI 공급망 공격은 애플리케이션이 아니라 애플리케이션을 만드는 데 쓰이는 의존성 체인을 공격 표면으로 삼는다. 패키지 저장소(npm, PyPI), 빌드 스크립트의 postinstall 훅, CI/CD 파이프라인의 시크릿 저장소, 심지어 보안 스캐너 자체가 침투 지점이 될 수 있다. 전통적인 해킹이 서버나 애플리케이션 로직의 취약점을 뚫는 것이었다면, 공급망 공격은 개발자가 매일 실행하는 npm install, pip install 명령 한 줄에 악성코드를 얹어 유포한다.

2026년 3월 발생한 Axios NPM 계정 탈취 사건이 대표적이다. Zscaler ThreatLabz 분석에 따르면, 공격자는 정상 계정을 탈취해 악성 postinstall 스크립트를 배포했고, 이 스크립트는 macOS·Windows·Linux 전 플랫폼에서 RAT(원격 접속 트로이목마)를 설치했다. 개발자가 패키지를 설치하는 순간 자동으로 실행되는 postinstall 훅의 특성상, 별도 클릭이나 실행 없이도 감염이 이뤄진다는 점이 위험성을 키운다.

Phoenix Security의 2026년 상반기 조사는 이 흐름을 통계로 뒷받침한다. 37개 캠페인, 497개 악성 패키지가 확인됐고 이는 전년도 전체 대비 캠페인 수 2.6배, 패키지 수 4.5배 증가한 수치다. 더 우려스러운 대목은 59개 캠페인을 전수 조사한 결과 CVE(공통 취약점 번호)가 단 한 건도 등록되지 않았다는 점이다. 즉 기존의 취약점 데이터베이스 기반 점검, 이른바 SCA(소프트웨어 구성 분석) 툴만으로는 이런 공격을 걸러낼 수 없다는 뜻이다.

AI 공급망 공격이란? 개발 파이프라인 보안 점검 체크리스트

2026년 실제 침해 사례 – LiteLLM부터 Shai-Hulud까지

올해 보고된 사건들을 시간순으로 짚어보면 공격의 규모와 정교함이 눈에 띄게 커졌다. LiteLLM PyPI 침해는 약 20일간 감염 상태가 지속됐고, 그 사이 수많은 조직의 CI/CD 파이프라인이 자격증명 유출 위험에 노출됐다. Cloud Security Alliance Lab Space는 2026년 5월 4일부터 12일까지 확산된 Mini Shai-Hulud 웜이 npm·PyPI 생태계의 172개 패키지, 404개 악성 버전을 감염시켰다고 밝혔다. 표적이 된 곳은 Mistral AI, TanStack, Guardrails AI, UiPath 등 AI 개발 도구와 밀접한 생태계였다.

같은 보고서는 2026년 3월 GitHub PAT(개인 접근 토큰) 하나가 완전히 회수되지 않은 데서 시작된 5일간의 CI/CD 공격도 언급한다. 여러 보안 도구에 걸쳐 110개 이상의 버전 태그가 강제로 푸시됐는데, 이는 토큰 하나의 관리 소홀이 얼마나 넓은 파급력을 가질 수 있는지 보여주는 사례다.

사건명 시기 침투 경로 영향 규모
LiteLLM PyPI 침해 2026년 (약 20일 지속) 빌드 파이프라인 내 Trivy 스캐너 기업 2,500개 이상, CI/CD 파이프라인 약 43만 4천 개
Axios NPM 계정 탈취 2026년 3월 30일 탈취 계정의 악성 postinstall 스크립트 macOS·Windows·Linux 대상 RAT 설치
Mini Shai-Hulud 웜 2026년 4월 29일~5월 12일 npm·PyPI 악성 버전 배포 172개 패키지, 404개 악성 버전
GitHub PAT 미회수 사건 2026년 3월 미완전 회수된 개인 접근 토큰 5일간 110개 이상 버전 태그 강제 푸시

434,000개

LiteLLM 공급망 침해로 노출된 CI/CD 파이프라인 수 · 출처: CloudSEK

왜 지금 AI 공급망 공격이 급증하는가 – 트렌드와 배경

AI 개발 도구 생태계가 폭발적으로 커지면서 공격 표면도 함께 넓어졌다. AI 에이전트, LLM 프록시, 벡터 데이터베이스 클라이언트 같은 신생 패키지들은 아직 보안 검증 체계가 성숙하지 않은 상태로 빠르게 배포되고 있다. 개발팀은 신규 기능 개발 속도를 우선하다 보니 의존성 하나하나의 출처를 검증할 여유가 부족한 경우가 많다.

또 하나 눈여겨볼 점은 CVE 등록률이다. Phoenix Security가 조사한 59개 캠페인 중 CVE로 등록된 건수는 0건이었다. 이는 공격자가 알려진 취약점을 재활용하는 대신, 정상 계정 탈취나 빌드 파이프라인 오염처럼 전통적인 취약점 스캐너의 탐지망 밖에 있는 방식을 선호한다는 뜻이다. 결국 조직 입장에서는 CVE 패치 관리만으로는 부족하고, 패키지 무결성 검증·행위 기반 모니터링 같은 별도 계층이 필요해졌다.

FBI가 2026년 7월 발령한 FLASH 권고도 같은 맥락이다. LiteLLM 침해 당시 탈취된 자격증명이 곧바로 폐기되지 않고 장기간 암시장에서 유통·악용될 수 있다는 경고인데, 이는 침해 발생 이후에도 사후 대응(자격증명 순환, 시크릿 재발급)이 얼마나 중요한지를 보여준다. 보안 담당자 입장에서는 "패치했으니 끝"이 아니라, 침해 시점 전후로 발급된 모든 토큰과 API 키를 재발급하는 절차까지 표준 대응 매뉴얼에 넣어야 한다.

개발 파이프라인 보안 점검 체크리스트

실무에서 바로 적용할 수 있는 점검 항목을 단계별로 정리했다. 대규모 보안팀이 없는 조직이라도 아래 항목만 주기적으로 확인하면 침해 위험을 크게 줄일 수 있다.

점검 영역 점검 포인트 권장 주기
패키지 버전 고정 lockfile로 정확한 버전을 고정하고 자동 업데이트를 비활성화 매 배포 시
postinstall 스크립트 검토 신규·업데이트 패키지의 설치 스크립트 변경 여부 확인 주 1회
CI/CD 토큰 관리 PAT·시크릿의 만료 기한 설정, 퇴사·프로젝트 종료 시 즉시 회수 월 1회 전수 점검
SBOM 생성 소프트웨어 자재 명세서로 전체 의존성 트리를 문서화 배포 파이프라인 통합
스캐너 자체 검증 보안 스캐너·도구 자체의 버전과 해시값을 별도 검증 업데이트마다
이상 행위 모니터링 빌드 서버의 비정상 외부 통신·프로세스 실행 탐지 상시
💡 참고: lockfile 고정만으로는 신규 설치 시점의 악성 버전을 막지 못한다. 패키지 해시값 검증까지 함께 적용해야 postinstall 스크립트 변조를 실질적으로 차단할 수 있다.

체크리스트를 스스로 운영하기 부담스러운 팀은 CI/CD 보안 플랫폼 구독 요금제나 SCA 툴 라이선스를 도입해 자동화하는 방법도 있다. 최근에는 월 단위 요금제로 패키지 무결성 검증, 시크릿 스캐닝, 빌드 로그 이상 탐지를 한 번에 제공하는 클라우드 보안 컨설팅 서비스도 늘고 있어, 인력이 부족한 스타트업도 진입 장벽이 낮아진 편이다.

▶️ [클릭] 개발 파이프라인 보안 점검 체크리스트 다운로드하기 👈

조직 차원의 대응 전략 – 사고 대비와 인력 역량 강화

기술적 점검만큼 중요한 것이 조직의 대응 체계다. 먼저 침해 발생 시 자격증명을 즉시 순환(rotation)할 수 있는 절차를 사전에 마련해야 한다. FBI FLASH 권고가 경고하듯, 탈취된 토큰은 침해가 종료된 후에도 오랫동안 악용될 수 있으므로 "패치 완료"와 "자격증명 재발급"은 별개의 체크박스로 관리하는 것이 안전하다.

사람 역량도 빼놓을 수 없다. 개발 조직 내부에 공급망 보안 담당자를 지정하고, 클라우드 보안 자격증(예: 국제적으로 통용되는 보안 관련 자격증)이나 관련 온라인 코딩 강의·부트캠프를 통해 최신 위협 동향을 학습하도록 지원하는 것도 실질적인 방어책이다. 최근에는 공급망 보안을 전문으로 다루는 실무형 교육 과정과 단기 워크숍도 늘고 있어, 학원 수강료나 온라인 강의 구독료를 투자해 팀 전체의 보안 리터러시를 끌어올리는 기업이 많아지는 추세다.

마지막으로, 사고 발생 시 골든타임을 줄이는 훈련이 필요하다. 침해 탐지부터 격리, 영향 범위 파악, 이해관계자 공지까지 걸리는 시간을 정기적으로 시뮬레이션하고 측정해야 한다. Cloud Security Alliance는 GitHub PAT 사건에서 5일간 110개 이상의 버전 태그가 강제 푸시된 사례를 들며, 초기 탐지 시간이 피해 규모를 좌우한다고 강조했다.

2026년 공급망 공격은 캠페인 수 2.6배, 악성 패키지 수 4.5배로 늘었지만 CVE 등록은 0건에 가까웠다. 취약점 패치 중심의 점검에서 벗어나, 패키지 무결성 검증·토큰 관리·이상 행위 모니터링을 아우르는 다층 방어 체계로 전환하는 것이 지금 개발 파이프라인이 가장 먼저 해야 할 일이다.