Keyv 감염, npm 공급망은 설치 순간이 전장이다
이번 사건의 핵심은 취약한 코드가 아니라 정상 릴리스 경로가 악성 릴리스를 운반했다는 점이다. 한국 개발 조직은 패키지 버전 고정, 설치 스크립트 제한, CI 비밀 최소화를 기본 보안선으로 올려야 한다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
정상 릴리스가 악성 배포가 됐다
Aikido는 2026년 8월 4일 key-value 저장 라이브러리 keyv 유지보수자의 GitHub 계정이 침해됐고, 관련 npm 패키지군에 credential-stealing worm이 주입됐다고 공개했다. Aikido 설명에 따르면 공격자는 악성 파일을 main 브랜치에 직접 넣은 뒤 새 릴리스를 만들었고, 이 때문에 악성 버전도 GitHub Actions가 서명한 정상 provenance를 갖고 npm에 올라갔다.
초기 목록에는 keyv, flat-cache, file-entry-cache, cacheable-request, cacheable, cache-manager 등 널리 쓰이는 패키지가 포함됐다. Aikido는 업데이트에서 최소 434개 패키지와 1,381개 버전이 감염됐고 월간 설치 합계가 20억 회를 넘었다고 밝혔다. PyTorch Lightning Shai-Hulud 공급망에서 보았던 위험이 다시 npm 생태계의 중심부를 건드린 셈이다.
preinstall은 작은 훅이 아니다
공격 방식은 단순하지만 치명적이다. 패키지에는 setup.mjs와 Math_Symbol.js가 추가됐고 package.json에는 preinstall 스크립트가 들어갔다. 사용자가 감염 버전을 설치하면 setup.mjs가 먼저 실행되고, Bun 런타임을 내려받아 실제 페이로드를 실행한다. 페이로드는 npm 토큰, GitHub 토큰, AWS 자격 증명, Kubernetes 서비스 계정, Vault 토큰, Stripe와 Slack 토큰, .env와 SSH 키를 광범위하게 훑는다.
npm scripts 문서는 lifecycle 스크립트가 설치 과정에서 자동 실행될 수 있음을 설명한다. 정상 기능으로 설계된 훅이 공급망 공격에서는 실행 엔진이 된다. GitHub Actions 보안 강화 가이드는 토큰 권한 최소화와 비밀 노출 방지를 강조하지만, 설치 스크립트가 러너 메모리와 환경변수까지 건드리면 방어는 훨씬 어려워진다.
| 공격 지점 | 탈취 대상 | 한국 팀의 대응 |
|---|---|---|
| 로컬 개발자 PC | .npmrc, .env, SSH 키 | 패키지 설치 격리, 개인 토큰 회전 |
| CI 러너 | GitHub, npm, OIDC 토큰 | 기본 권한 read-only, job별 토큰 분리 |
| 클라우드 환경 | AWS 키와 Secrets Manager | 단기 자격 증명, IMDSv2 강제 |
| Kubernetes | 서비스 계정과 namespace secrets | namespace별 최소 권한, 비밀 마운트 제한 |
AI 시대에는 전파 속도가 더 문제다
이번 Aikido 글은 직접적으로 공격자가 AI를 썼다고 단정하지 않는다. 하지만 공급망 공격의 운영 조건은 AI 자동화와 잘 맞는다. 감염된 토큰으로 어떤 패키지를 릴리스할지 고르고, README와 릴리스 노트를 위장하고, 이슈 대응을 자동화하고, 피해 조직의 공개 저장소를 분석하는 일은 모두 에이전트가 가속할 수 있다. Keyv 사건의 Hacker News 토론에서도 피해 후속 침해가 빠르게 번질 수 있다는 우려가 나왔다.
허깅페이스 침해 타임라인, 에이전트 보안의 현실과 OpenAI 사이버 평가 사고는 자동화된 공격 주체가 평가와 실제 시스템 사이의 경계를 빠르게 시험한다는 점을 보여준다. 공급망 보안도 같은 방향으로 봐야 한다. 사람의 수동 대응 속도는 악성 릴리스와 자동 설치 속도를 따라가기 어렵다.
실무 대응은 지루한 기본기에서 시작된다
한국 개발 조직은 즉시 세 가지를 확인해야 한다. 첫째, lockfile에 감염 버전이 들어왔는지 확인한다. 둘째, 2026년 8월 4일 전후 CI와 개발자 장비에서 사용된 npm, GitHub, 클라우드, Slack, Stripe 토큰을 회전한다. 셋째, 설치 스크립트가 필요한 패키지와 필요 없는 패키지를 구분하고 빌드 환경에서 ignore-scripts 또는 allowlist 전략을 검토한다.
OpenSSF Scorecard와 SLSA 프레임워크는 공급망 위험을 줄이는 좋은 출발점이다. 하지만 provenance만으로 충분하지 않다는 점도 이번 사건이 보여줬다. 악성 변경이 정상 계정과 정상 CI에서 나가면 서명은 운반 경로의 진짜성을 보증할 뿐, 의도의 안전성을 보증하지 않는다. 루트리스 컨테이너, AI 서비스의 기본선이 되다에서 다룬 격리 원칙이 개발 도구 설치에도 적용돼야 한다.
자주 묻는 질문
Q1: keyv를 쓰면 모두 감염됐나요?
A: 감염된 특정 버전을 설치했는지가 핵심이다. lockfile과 npm 캐시, CI 로그를 확인해야 한다.
Q2: provenance가 있었는데 왜 막지 못했나요?
A: 공격자가 유지보수자 계정과 릴리스 경로를 이용했기 때문이다. provenance는 누가 어떻게 배포했는지를 보이지만 악성 의도를 자동 판정하지 않는다.
Q3: 가장 먼저 회전할 비밀은 무엇인가요?
A: npm, GitHub, 클라우드, Kubernetes, Vault, Stripe, Slack 토큰을 우선순위로 봐야 한다.
Q4: 설치 스크립트를 전부 막아도 되나요?
A: 일부 패키지는 빌드에 필요하다. 기본 차단 뒤 필요한 패키지만 allowlist하는 접근이 현실적이다.
Q5: AI 에이전트 개발팀에는 어떤 의미인가요?
A: 에이전트가 코드를 수정하고 의존성을 설치하는 환경일수록 비밀 최소화와 격리된 작업 공간이 필수다.
관련 토픽 더 보기
📰 원본 출처
aikido.dev이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.