AI 개발 라이브러리에 악성코드가 숨어 있었다면? 공급망 공격과 외주 개발의 리스크 (semgrep.dev)

한줄 요약

AI 학습 라이브러리에 숨겨진 악성코드, 외주 개발팀의 클라이언트 환경까지 위협한다.

본문

오픈소스 패키지 하나가 악성코드의 운반체가 되는 소프트웨어 공급망 공격은 더 이상 이론적 위협이 아니다. 최근 AI 학습에 널리 쓰이는 파이썬 딥러닝 패키지에서 악성코드가 발견된 사건은, 외주 개발과 에이전시 업무 방식 전반을 다시 점검하게 만드는 계기가 됐다.

어떤 공격이었나?

문제의 패키지는 pip install 한 줄로 설치되고, 모듈을 import하는 순간 자동으로 실행됐다. 별도의 사용자 행동이 필요 없었다. 악성 코드는 패키지 내부 숨겨진 디렉터리에 난독화된 JavaScript 형태로 포함돼 있었고, 실행 즉시 다음을 수행했다.

• 로컬 파일 시스템에서 인증 토큰과 자격증명 탈취
• 환경변수 전체 덤프 (API 키, 클라우드 시크릿 포함)
• CI/CD 파이프라인 메모리에서 GitHub Actions 시크릿 추출
• AWS, Azure, GCP 클라우드 자격증명 열거 및 유출
• npm 배포 권한이 있을 경우 해당 패키지까지 감염시켜 전파

공격자는 탈취한 데이터를 네 가지 경로로 동시에 외부로 빼냈다. HTTPS로 직접 전송하고, GitHub 커밋 메시지를 암호화된 토큰 전달 채널로 활용하며, 공개 저장소에 결과를 올리고, 피해자 본인의 저장소에 직접 푸시하는 방식이었다. 하나의 경로가 막혀도 나머지로 데이터가 빠져나가는 구조다.

특히 Claude Code와 VS Code의 자동 실행 훅을 악용해 개발자가 프로젝트를 열기만 해도 악성코드가 재실행되는 지속성(Persistence) 메커니즘까지 심었다. 실제 공격에서 AI 코딩 도구의 훅 시스템이 악용된 것은 이번이 처음 보고된 사례 중 하나다.

에이전시와 외주 개발팀이 유독 위험한 이유

일반 기업 개발팀과 달리, IT 에이전시와 외주 개발 조직은 구조적으로 더 넓은 공격 표면을 갖는다.

첫째, 동시에 여러 클라이언트의 저장소에 접근한다. 개발자 한 명이 토큰 하나로 다수의 고객사 GitHub 조직에 접근하는 경우가 흔하다. 하나의 로컬 환경이 감염되면 클라이언트 전체가 연쇄적으로 노출될 수 있다.

둘째, 프로젝트마다 의존성 구성이 다르고 변경 속도가 빠르다. AI 기능을 붙이는 프로젝트가 늘면서 딥러닝 라이브러리가 의존성 트리 어딘가에 들어오는 경우도 잦아졌다. 직접 설치하지 않아도, 다른 패키지가 내부에서 끌고 오는 간접 의존성이 문제가 될 수 있다.

셋째, 클라이언트로부터 받은 클라우드 계정 접근 권한이 개발 환경에 남아 있는 경우가 많다. 배포를 위한 AWS IAM 키, GCP 서비스 계정, Azure 구독 접근 권한이 .env 파일이나 환경변수 형태로 개발 머신에 존재한다. 이번 악성코드는 바로 이 지점을 정확히 노렸다.

에이전시가 지금 당장 해야 할 것

공급망 공격에 완벽한 방어선은 없다. 하지만 피해 범위를 줄이는 실질적인 조치는 존재한다.

의존성 고정과 검증을 습관화한다. pip install lightning 처럼 버전을 명시하지 않은 설치는 공격자가 악성 버전을 올리는 순간 자동으로 감염된다. requirements.txt나 pyproject.toml에 정확한 버전을 고정하고, 해시 검증을 추가하는 것이 기본이다.

CI/CD 환경과 로컬 개발 환경을 분리한다. 배포 권한을 가진 자격증명은 파이프라인 내부에서만 작동하도록 격리한다. 개발자 노트북에 프로덕션 시크릿이 존재하는 환경 자체가 위험이다.

클라이언트별 자격증명을 분리 관리한다. 프로젝트가 끝난 뒤 자격증명을 회수하고, 진행 중인 프로젝트도 최소 권한 원칙을 적용한다. 하나의 토큰이 여러 클라이언트 환경에 동시 접근 가능한 구조를 없애야 한다.

패키지 보안 스캐닝을 자동화한다. 코드 리뷰 단계에서 의존성 취약점을 자동으로 검출하는 도구를 CI 파이프라인에 연결한다. 이상 파일(.claude/, .vscode/ 내 예상치 못한 스크립트 등)을 감지하는 규칙도 추가할 수 있다.