Bitwarden CLI npm 하이재킹이 드러낸 CI/CD 공급망 보안 설계

2026년 4월 22일, @bitwarden/cli@2026.4.0은 악성 버전으로 교체된 채 npm에 배포됐다. 노출 시간은 93분이었고, 설치 과정에서 GitHub 토큰과 SSH 키, 클라우드 인증정보를 수집할 수 있는 preinstall 훅이 실행됐다. 패키지 하나의 변조가 개발자 로컬 환경과 CI/CD 시크릿까지 이어지는 이유가 이 사건에 담겨 있다.

npm 배포 경로를 침해한 Bitwarden CLI 사건

이번 공격은 Bitwarden의 CI/CD 파이프라인에 포함된 악성 GitHub Action을 출발점으로 삼았다. Checkmarx Supply Chain Campaign으로 명명된 캠페인은 npm 배포 권한을 가진 경로를 침해해 악성 패키지를 배포하는 방식이었다.

공격 흐름은 다음과 같다.

2026년 4월 22일 오후 5시 57분 — 악성 패키지(@bitwarden/cli@2026.4.0) npm 배포 시작
오후 7시 30분 — Bitwarden 측 인지 및 패키지 차단 (93분간 노출)
동일 일자 — Bitwarden 공식 성명 발표 및 대응 지침 공개

악성 패키지는 설치 시점에 preinstall 훅을 실행했고, 수집 대상에는 다음 항목이 포함됐다.

GitHub 및 npm 토큰
SSH 개인 키 (~/.ssh/)
쉘 히스토리 (~/.bash_history, ~/.zsh_history)
.env 파일의 환경변수
GitHub Actions CI 시크릿
AWS, GCP, Azure 클라우드 자격증명

Bitwarden은 일반 사용자 데이터는 영향을 받지 않았다고 밝혔지만, 해당 기간에 npm install @bitwarden/cli를 실행한 개발자 시스템과 CI 환경은 전수 조사 대상이다.

npm 의존성이 공격 경로가 되는 방식

패키지 생태계에서 공급망 공격은 계정 탈취, 타이포스쿼팅, 의존성 혼동으로 나뉜다. 세 방식 모두 개발자나 빌드 시스템이 신뢰하는 설치 과정을 악용한다.

배포 권한을 겨냥하는 계정 탈취

Bitwarden 사건은 패키지 관리자 계정 자체를 탈취하거나, 그 계정에 연결된 GitHub Actions를 침해해 배포 권한을 얻는 유형에 해당한다. MFA가 설정되지 않은 계정, 만료된 도메인 이메일 주소의 재등록, 재사용된 비밀번호가 주요 진입점이 된다.

오타를 노리는 타이포스쿼팅

타이포스쿼팅은 정상 패키지와 매우 비슷한 이름의 악성 패키지를 npm에 등록하는 방식이다. lodash와 1odash, express와 expres처럼 한 글자 차이를 이용한다. 2025년 한 해에만 npm에서 454,648개의 악성 패키지가 탐지됐다.

공개 레지스트리를 악용하는 의존성 혼동

기업 내부 레지스트리의 프라이빗 패키지와 같은 이름으로 공개 npm 레지스트리에 패키지를 올리는 공격이다. npm 클라이언트가 공개 레지스트리를 먼저 조회하도록 설정돼 있으면, 더 높은 버전 번호의 악성 패키지가 자동 설치될 수 있다. npm은 자체적으로 의존성 혼동 공격을 탐지하는 메커니즘을 갖추고 있지 않다.

⤢✕

자동화된 빌드 환경에 권한과 시크릿이 모이는 이유

2025년 공급망 공격은 전년 대비 두 배 이상 증가했고, 전체 조직의 70% 이상이 서드파티 소프트웨어 관련 침해를 경험했다. 피해 규모는 600억 달러이며, 2031년까지 1,380억 달러로 성장할 전망이다.

CI/CD 파이프라인은 패키지를 자동으로 설치하고 실행한다. 사람이 설치 과정을 직접 확인하지 않기 때문에 의심스러운 동작을 발견하기 어렵다. 동시에 운영 환경 배포 권한, 클라우드 API 키, 코드 서명 인증서처럼 가치가 높은 시크릿도 한곳에 집중된다.

하나의 악성 패키지가 수천 개 파이프라인에 동시에 설치될 수 있다는 점도 문제다. 2025년 3월 GhostAction 사건에서는 침해된 GitHub Action 하나가 수천 개 저장소에서 CI/CD 시크릿을 유출했다. Bitwarden 사건 역시 이와 같은 신뢰 사슬을 겨냥했다.

가시성·무결성·출처를 연결하는 공급망 방어

공급망 보안은 구성 요소를 파악하는 SBOM, 아티팩트 무결성을 확인하는 Sigstore/Cosign, 빌드 출처를 검증하는 SLSA를 함께 적용하는 구조로 볼 수 있다.

빌드 산출물의 구성 목록을 남기는 SBOM

SBOM은 소프트웨어 제품을 이루는 모든 구성 요소의 목록이다. SPDX와 CycloneDX가 주요 형식으로 자리잡았으며, CI/CD에서는 빌드 단계에 SBOM 생성을 포함해야 한다.

# Syft로 SBOM 생성 (CycloneDX JSON 형식)
syft packages . -o cyclonedx-json > sbom.cdx.json

# Grype로 CVE 매칭
grype sbom:sbom.cdx.json

# Trivy로 악성 패키지 여부 확인
trivy fs --scanners vuln,secret .

Bitwarden의 CI 파이프라인이 빌드 시점에 SBOM을 만들고 이전 빌드와 비교했다면, 2026.4.0 버전에 주입된 preinstall 스크립트 변경을 빌드 시작 직후 탐지할 수 있었을 것이다.

서명으로 아티팩트 무결성을 확인하는 Sigstore와 Cosign

Sigstore는 코드 서명을 위한 오픈소스 인프라다. 개발자는 별도 키 관리 없이 OIDC 기반 신원으로 아티팩트에 서명할 수 있다.

# npm 패키지 서명 (Cosign + Sigstore)
cosign sign-blob --bundle package.tgz.bundle package.tgz

# 서명 검증
cosign verify-blob --bundle package.tgz.bundle \
  --certificate-identity "ci@bitwarden.com" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  package.tgz

npm은 2023년부터 일부 패키지에 Sigstore 서명을 지원하기 시작했다. 패키지 서명이 의무화됐다면 악성 행위자가 합법적인 서명 없이 패키지를 배포하는 것은 불가능했을 것이다.

빌드 출처를 검증하는 SLSA

SLSA는 소프트웨어 아티팩트의 빌드 출처(provenance)를 검증하는 프레임워크다. SLSA Level 3는 신뢰할 수 있는 환경에서 빌드가 수행됐고, 소스와 의존성이 검증됐음을 보장한다.

SLSA 레벨	요구사항	의미
Level 1	출처 문서 존재	빌드 프로세스 문서화
Level 2	서비스 기반 빌드 + 서명된 출처	CI 시스템에서의 빌드 증명
Level 3	격리된 빌드 환경 + 검증된 출처	빌드 환경 신뢰 보장
Level 4	두 당사자 리뷰 + 패키지 고정	최고 수준 무결성

의존성 설치와 GitHub Actions에 적용할 통제

package-lock.json 또는 npm-shrinkwrap.json에는 정확한 버전과 무결성 해시를 기록할 수 있다. npm ci는 lockfile을 기준으로 설치하므로, ^와 ~ 같은 버전 범위로 인한 예기치 않은 업그레이드를 차단한다.

{
  "dependencies": {
    "@bitwarden/cli": {
      "version": "2026.3.0",
      "resolved": "https://registry.npmjs.org/@bitwarden/cli/-/cli-2026.3.0.tgz",
      "integrity": "sha512-abc123..."
    }
  }
}

Artifactory, Nexus, GitHub Packages 같은 프라이빗 레지스트리를 중간에 두고 허용된 패키지만 통과시키는 구조도 사용할 수 있다.

GitHub Actions는 변경 가능한 태그 대신 커밋 SHA로 고정해야 한다.

# 취약한 방식 — 변경 가능한 태그 사용
- uses: actions/checkout@v4

# 안전한 방식 — 커밋 SHA 고정
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

워크플로우 권한 역시 최소 권한 원칙에 따라 설정한다.

permissions:
  contents: read
  packages: write
  id-token: write  # OIDC 서명에만 필요한 경우

SCA(Software Composition Analysis) 도구는 알려진 CVE뿐 아니라 악성 패키지 패턴도 탐지한다.

도구	악성 패키지 탐지	의존성 혼동 탐지	SBOM 생성	비고
Snyk	O	O	O	상용, 광범위한 DB
Socket	O	O	-	npm 특화, 행동 분석
Trivy	O	-	O	오픈소스, 컨테이너 특화
Grype	-	-	O (SBOM 소비)	SBOM 기반 CVE 매칭
Checkmarx SCA	O	O	O	엔터프라이즈

침해 징후가 발견됐을 때의 대응 범위

Bitwarden 사건과 같은 침해가 발생하면 악성 버전 설치 여부부터 확인하고, 영향받은 시스템을 네트워크에서 분리해야 한다. 이후 GitHub 토큰, npm 토큰, SSH 키, 클라우드 IAM 자격증명을 전수 교체하고 CI/CD 환경의 모든 환경변수 목록을 검토한다. 악성 패키지 설치 이후의 네트워크 아웃바운드 트래픽도 분석 대상이다.

영향 범위 파악: npm view @bitwarden/cli@2026.4.0 --json으로 악성 버전 설치 여부 확인
격리: 영향받은 시스템을 네트워크에서 분리
자격증명 교체: GitHub 토큰, npm 토큰, SSH 키, 클라우드 IAM 자격증명 전수 교체
시크릿 감사: CI/CD 환경의 모든 환경변수 목록 검토
로그 분석: 악성 패키지 설치 이후의 네트워크 아웃바운드 트래픽 검토

예방 구조에서는 프라이빗 레지스트리 정책 검증, SCA 스캔, 무결성 해시 검증을 거친 패키지를 CI/CD에 공급한다. 이후 npm ci 기반 설치, SBOM 생성, CVE 스캔, Sigstore 서명, 배포 전 서명 검증까지 연결한다.

개발자 로컬 환경
    ↓ npm install
프라이빗 레지스트리 (Artifactory/Nexus)
    ↓ 정책 검증 (허용 목록, 버전 고정)
    ↓ SCA 스캔 (Socket, Snyk)
    ↓ 무결성 해시 검증
캐시된 허용 패키지
    ↓
CI/CD 파이프라인 (npm ci — lockfile 기반)
    ↓ SBOM 생성 (Syft)
    ↓ CVE 스캔 (Grype)
    ↓ Sigstore 서명 (Cosign)
    ↓
아티팩트 레지스트리 (서명된 컨테이너/패키지)
    ↓ 배포 전 서명 검증
프로덕션 환경

npm lifecycle 스크립트인 preinstall, install, postinstall은 설치 중 임의 코드를 실행할 수 있어 공급망 공격의 핵심 벡터가 된다. 설치 스크립트는 비활성화하거나 허용 목록을 기준으로 제한할 수 있다.

# .npmrc 에서 설치 스크립트 비활성화
ignore-scripts=true

# 또는 npm 설치 시 플래그로 제어
npm install --ignore-scripts

일부 패키지는 정상 동작에 설치 스크립트가 필요하므로, 허용 목록 기반으로 선별 허용하는 방식이 현실적이다.

Bitwarden CLI 하이재킹은 짧은 노출 시간에도 개발자 자격증명 대량 유출 가능성이 생길 수 있음을 보여줬다. SBOM으로 가시성을 확보하고, Sigstore로 무결성을 보장하며, SLSA로 빌드 출처를 검증하는 계층형 방어가 필요하다. preinstall 훅 제한, GitHub Actions 커밋 SHA 고정, SCA 도구의 파이프라인 통합은 신뢰 사슬을 좁히는 실무적 통제다.