Red Hat 공식 NPM 패키지가 해킹당했다 - 공급망 공격의 또 다른 사례

무슨 일이 일어났을까요?

오픈소스 생태계를 또 한 번 흔드는 사건이 터졌어요. Red Hat이 공식적으로 배포하던 NPM 패키지들이 침해(compromise) 당했다는 소식이 GitHub 이슈를 통해 공개됐거든요. 정확히 말하면 @redhat-cloud-services 네임스페이스 아래에 있던 여러 자바스크립트 클라이언트 패키지들이 영향을 받았어요. 이게 왜 큰일이냐면, Red Hat은 리눅스 진영에서 가장 신뢰받는 엔터프라이즈 벤더 중 하나거든요. 그런 회사의 공식 패키지가 뚫렸다는 건, "믿을 만한 곳에서 받은 코드"라는 개념 자체를 다시 생각하게 만드는 사건이에요.

공급망 공격(supply chain attack)이라는 말이 요즘 정말 자주 들리는데요, 이게 뭐냐면 내가 직접 만든 코드는 안전해도 내가 npm install로 가져온 라이브러리가 악성코드를 품고 있으면 결국 내 서비스도 감염된다는 거예요. 마치 식당에서 아무리 위생적으로 요리해도 식자재 자체가 오염되어 있으면 손님이 탈이 나는 것과 같은 원리죠.

어떤 식으로 당했을까요?

공격자들이 패키지 메인테이너의 NPM 계정을 탈취한 것으로 보여요. 보통 이런 공격은 두 가지 경로로 진행돼요. 첫 번째는 메인테이너의 NPM 토큰이 GitHub Actions 워크플로우 로그나 잘못 커밋된 .env 파일에 노출된 경우고, 두 번째는 피싱 이메일로 자격증명을 빼앗는 방식이에요. 이번 건은 Red Hat 측에서 공식 조사 중이지만, 일단 영향받은 패키지 버전들이 NPM에서 deprecate(사용 중단) 처리되거나 unpublish(배포 취소)되고 있는 상황이에요.

악성 버전이 실제로 어떤 동작을 했는지가 가장 중요한데요, 일반적으로 이런 종류의 공격은 패키지가 설치될 때 실행되는 postinstall 스크립트에 코드를 심어두거나, 정상 코드 사이에 환경 변수(API 키, DB 비밀번호 같은 것들)를 외부 서버로 전송하는 로직을 끼워 넣어요. CI/CD 파이프라인에서 빌드가 도는 순간 회사의 비밀들이 공격자 서버로 줄줄 흘러 나가는 거죠.

비슷한 사건들과 비교해보면

이번 사건이 처음은 아니에요. 작년에는 xz-utils라는 리눅스 압축 라이브러리에 백도어가 심어진 채로 배포되어 전 세계 보안팀이 발칵 뒤집힌 적이 있었고요, 그 전에는 event-stream, colors.js, node-ipc 같은 인기 NPM 패키지들이 비슷한 방식으로 오염됐었어요. 특히 node-ipc 사건은 메인테이너 본인이 정치적 이유로 러시아·벨라루스 IP를 대상으로 파일을 파괴하는 코드를 심어둔 거라 더 충격이었죠.

Google, Microsoft, GitHub 같은 빅테크들이 SLSA(Supply-chain Levels for Software Artifacts)라는 보안 프레임워크를 밀고 있고, NPM도 최근 "provenance" 기능을 도입해서 패키지가 어떤 GitHub 워크플로우에서 빌드됐는지 검증할 수 있게 만들었어요. 하지만 이번처럼 공식 메인테이너 계정 자체가 뚫리면 이런 검증 장치도 무력화될 수 있다는 게 뼈아픈 지점이에요.

한국 개발자가 지금 당장 해야 할 일

만약 여러분의 프로젝트에서 @redhat-cloud-services/* 패키지를 쓰고 있다면 일단 package-lock.json을 열어서 설치된 버전을 확인해보세요. 그리고 GitHub 이슈에 올라온 영향받은 버전 목록과 대조해본 뒤, 안전한 버전으로 핀(pin)하거나 패키지를 아예 제거하는 게 우선이에요. 이미 CI에서 빌드를 돌린 적이 있다면 해당 환경의 시크릿(AWS 키, DB 비밀번호, API 토큰 등)을 전부 로테이션하는 것도 고려해야 해요. 한 번 유출된 자격증명은 무조건 새로 발급받는 게 정석이거든요.

장기적으로는 npm ci --ignore-scripts 옵션으로 postinstall 스크립트 실행을 막거나, Socket.dev나 Snyk 같은 도구를 CI에 붙여서 새 패키지가 들어올 때마다 자동으로 악성코드 패턴을 스캔하게 만드는 게 좋아요. 사내 npm 미러를 두고 검증된 패키지만 통과시키는 회사들도 점점 늘고 있고요. 한국 스타트업들도 이제는 "npm install 한 줄로 끝"이라는 편의성 뒤에 숨은 위험을 진지하게 다뤄야 할 때예요.

마무리

결국 핵심은 이거예요. "신뢰받는 벤더"라는 라벨만으로는 더 이상 안전을 보장할 수 없다. Red Hat조차 뚫리는 시대에 우리는 의존성 하나하나를 검증하고, 자격증명을 최소 권한으로 관리하고, 사고가 났을 때 빠르게 대응할 수 있는 절차를 미리 만들어둬야 해요.

여러분의 팀은 NPM 패키지가 갑자기 악성으로 바뀌었을 때 몇 시간 안에 탐지하고 대응할 수 있는 체계가 갖춰져 있나요? 아니면 "설마 우리한테?"라고 생각하면서 그냥 npm install을 돌리고 있나요?