Red Hat NPM 침해 사고: 공급망 보안의 교훈

최근 Red Hat 클라우드 서비스와 관련된 여러 NPM 패키지가 침해된 사건은 개발자 커뮤니티에 큰 파장을 일으켰습니다. 이번 사건은 확립된 엔터프라이즈급 조직조차 공급망 공격으로부터 자유롭지 않다는 사실을 극명하게 보여주는 사례입니다. 신뢰할 수 있는 게시자의 파이프라인이 침해되면, 수천 개의 종속성을 자동으로 가져오는 현대 소프트웨어 개발의 신뢰 모델이 근본적으로 도전을 받게 됩니다.

사건 개요: 신뢰의 붕괴

SafeDep의 상세 분석을 포함한 보고서에 따르면, 동일한 게시 파이프라인을 공유하는 약 32개의 패키지가 영향을 받았습니다. 이번 침해로 인해 공격자는 개발자와 조직이 Red Hat 서비스를 위해 의존하는 패키지에 악성 코드를 주입할 수 있었습니다.

정확한 침해 경로는 여전히 조사 중이지만, 커뮤니티의 추측에 따르면 IDE 확장 프로그램(예: NX VS Code extension)을 통한 개발자의 노트북 침해부터 CI/CD 파이프라인 보안 실패에 이르기까지 여러 가능성이 제기되고 있습니다. 침입 경로가 무엇이든 결과는 동일했습니다. 악성 코드가 신뢰할 수 있는 공식 채널을 통해 배포되었습니다.

NPM의 구조적 취약점

이번 사건을 둘러싼 논의의 상당 부분은 JavaScript 생태계의 내재적 위험에 집중되었습니다. 주요 쟁점 중 하나는 postinstall 스크립트의 사용입니다. 이러한 스크립트는 패키지가 설치되는 즉시 임의의 코드를 실행할 수 있게 하여, 악성 코드를 전달하는 완벽한 메커니즘을 제공합니다.

"제가 이해하지 못하는 한 가지는 왜 NPM이 패키지 설치 직후에 코드를 실행하도록 허용하는가 하는 점입니다. 그것이 어떤 용도로 사용됩니까? 패키지는 단순히 런타임에 호출할 수 있는 코드여야 합니다."

이 "기능"은 사실상 모든 npm install 명령을 잠재적인 원격 코드 실행(RCE) 이벤트로 만듭니다. 제한적인 OS 권한 모델의 부재와 결합될 때, 이러한 스크립트는 홈 디렉토리를 스캔하고, 환경 변수를 훔치고, 토큰을 유출할 수 있으며, 종종 명령을 실행하는 사용자의 모든 권한을 갖게 됩니다.

실질적인 완화 전략

구조적 위험에도 불구하고, 개발자와 보안 팀은 환경을 보호하기 위해 여러 단계의 방어 계층을 구현할 수 있습니다.

1. 종속성 쿨다운(Dependency Cooldowns)

논의된 가장 효과적이고 마찰이 적은 전략 중 하나는 "쿨다운"을 구현하는 것입니다. 이는 새로운 패키지 버전이 프로덕션 환경에 도입되기 전, 일정 기간(통상 1-3일) 동안 설치를 지연시키는 것을 의미합니다. 대부분의 악성 버전은 몇 시간 내에 레지스트리에서 감지되어 삭제되므로, 짧은 지연만으로도 가장 치명적인 영향을 방지할 수 있습니다.

  • pnpm: 이제 기본적으로 1일의 쿨다운을 포함합니다.
  • Yarn 4: 최근 출시된 패키지의 설치를 방지하는 옵션을 제공합니다.
  • Third-party tools: depsguard 및 cooldowns.dev와 같은 도구들은 다양한 패키지 매니저에서 이러한 지연을 강제할 수 있는 CLI 래퍼를 제공합니다.

2. 샌드박싱 및 격리

침해의 "폭발 반경(blast radius)"을 제한하기 위해, 개발자는 호스트 OS에서 설치 명령을 실행하는 것을 피해야 합니다.

  • Dev Containers: VS Code Dev Containers 또는 유사한 샌드박스 환경을 사용하면 패키지가 침해되었을 경우 공격자의 접근 권한이 사용자의 전체 홈 디렉토리가 아닌 컨테이너로 제한됩니다.
  • CI에서의 권한 분리: GitHub Actions에서 빌드/테스트 단계(which runs npm install)와 게시/서명 단계를 분리하십시오. 이를 통해 설치 중에 실행되는 코드가 게시용으로 사용되는 비밀 정보를 쉽게 접근할 수 없도록 보장합니다.

3. 게시 파이프라인 강화

패키지 유지 관리자에게 초는 소비가 아닌 배포로 옮겨갑니다. 커뮤니티는 더 강력한 게시 보호 조치를 채택할 것을 촉구하고 있습니다:

  • MFA for Publishing: 모든 릴리스에 대해 다요소 인증을 요구합니다.
  • Trusted Publishers: 정적인, 수명이 긴 자격 증명을 사용할 필요가 없는 OIDC 기반 게시(예: GitHub Actions)를 사용합니다.
  • Staged Publishing: 유지 관리자가 CI에서 푸시된 후에, 하지만 레지스트리에 라이브 상태가 되기 전에 MFA를 통해 릴리스를 승인할 수 있는 새로운 기능입니다.

결론

Red Hat 사건은 더 크고 더 취약한 시스템의 증상입니다. Project Lightwell(공급망 취약점을 감지하기 위해 Red Hat과 IBM이 발표한 프로젝트)과 같은 도구들이 진전을 의미하지만, 근본적인 문제는 우리가 제3자 코드에 부여하는 신뢰입니다. 쿨다운, 샌드박싱, 그리고 엄격한 게시 요구 사항을 결합함으로써, 우리는 더 탄력력 있는 소프트웨어 공급망을 향해 나아갈 수 있습니다.

Sources