npm 패키지 탈취는 유지관리자만의 문제가 아니다. 패키지가 의존성 트리 깊숙한 곳에 있으면, 평소의 빌드와 배포 과정이 위험한 산출물을 여러 서비스에 전달할 수 있다.

Wiz Research는 여러 keyv/cacheable npm 패키지에 영향을 주는 진행 중인 공급망 공격을 조사하고 있다고 밝혔다. 제공된 공개 자료만으로 모든 영향 버전이나 동작을 단정할 수 없으므로, 조직이 실제로 내려받은 아티팩트를 확인해야 한다.

전이 의존성이 영향 범위를 키우는 방식

manifest만으로는 충분하지 않다. 락파일은 특정 시점에 해석된 버전을 기록하며, 간접 의존성은 여러 경로로 유입될 수 있다. 저장소마다 해석된 릴리스도 다를 수 있다.

따라서 첫 질문은 “keyv를 직접 import하는가?”가 아니다. “어떤 커밋, 빌드 결과물, 환경이 경고 범위의 아티팩트를 해석하거나 실행했는가?”여야 한다.

빌드 증적에서 사고 대응을 시작하라

1. 긴급 패치 경로는 유지하되 불필요한 의존성 업데이트는 일시 중지한다.
2. 락파일, CI 캐시, 사용 가능한 SBOM, 컨테이너 이미지, 설치 로그에서 실제 패키지 버전을 찾는다.
3. 관련 저장소·빌드·릴리스를 연결하고, 시크릿 접근 또는 패키지 배포 권한이 있는 시스템을 우선한다.
4. 공식 지침이 나오면 해당 버전을 업데이트하거나 제거하고 깨끗한 환경에서 다시 빌드한다.

락파일 수정만으로 조사가 끝나지 않는다

버전 고정은 다음 설치를 통제할 뿐, 이전 아티팩트가 어디서 실행됐는지는 알려 주지 않는다. 의심스러운 빌드가 CI 변수나 배포 자격 증명을 읽을 수 있었다면 실제 권한을 기준으로 시크릿 교체를 검토해야 한다.

다음으로 볼 항목

keyv/cacheable 조사 업데이트와 레지스트리·유지관리자 권고를 함께 추적하라. 자동 업데이트를 정상화하기 전 의존성 정책, provenance 검증, 배포 권한을 점검하는 편이 안전하다.

5분 요약

• 직접 의존성뿐 아니라 전이 의존성을 조사한다.
• 락파일, CI 로그, 이미지를 증적으로 활용한다.
• 수정 후 깨끗한 환경에서 재빌드한다.
• 빌드의 실제 권한을 기준으로 시크릿 교체를 판단한다.

참고 자료

• Securing open source software, together
• Supply Chain Security Analysis of a 9.5M-Install VS Code Extension
• Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns
• How to Investigate GitHub PAT Compromise: Lessons From a Multi-Organization Campaign
• Closing the Blind Spot: Securing Personal Repositories in the Software Supply Chain
• keyv and cacheable npm Package Hijacked in Supply Chain Attack