오픈소스 공급망 공격, 우리 팀도 예외가 아니다

"나는 코드를 안 짰는데 왜 내 서비스가 뚫렸지?" — 공급망 공격의 전형적인 질문입니다. 문제는 내가 작성한 코드가 아니라, 내가 설치한 남의 코드에 있었던 겁니다.

공급망 공격이란

우리 프로젝트는 보통 수십~수백 개의 오픈소스 패키지(npm, PyPI, RubyGems 등)에 의존합니다. 공격자가 그 패키지 중 단 하나만 감염시키면, 그걸 설치하는 모든 프로젝트가 자동으로 감염됩니다. 내 코드를 직접 공격하는 것보다 훨씬 효율적이라, 최근 몇 년간 이 방식이 크게 늘었습니다.

실제로 이렇게 일어난다

1. 타이포스쿼팅(typosquatting): 인기 패키지 이름과 비슷한 가짜 패키지(예: lodash → iodash)를 올려두고, 실수로 설치하길 기다림
2. 유지보수자 계정 탈취: 오래된 패키지의 관리자 계정을 탈취해, 기존 정상 패키지에 악성 코드를 슬쩍 추가한 새 버전을 배포
3. 디펜던시 컨퓨전(dependency confusion): 회사 내부용 패키지 이름과 같은 이름을 공개 레지스트리에 올려, 빌드 시스템이 내부 대신 공개(악성) 버전을 받아가게 유도

세 경우 모두 개발자가 평소처럼 `npm install`을 실행하는 것만으로 감염됩니다. 뭔가 수상한 행동을 한 게 아닙니다.

왜 작은 팀이 더 취약한가

큰 회사는 사내 레지스트리 미러링, 패키지 승인 프로세스를 갖추고 있는 경우가 많습니다. 반면 1인 개발자나 소규모 팀은 대개 의존성을 설치한 뒤 다시 들여다보지 않습니다. 게다가 AI 코드 생성 도구는 필요한 기능이 있으면 별 검증 없이 새 패키지를 제안하는 경우가 많아, 노출 표면이 더 넓어집니다.

방어 3단계

1. lockfile을 커밋하고 고정 버전으로 설치 — package-lock.json/pnpm-lock.yaml이 없으면 같은 코드가 매번 다른 버전을 설치할 수 있습니다.
2. 의존성 취약점 자동 스캔 — 알려진 취약점(CVE)이 있는 버전을 쓰고 있는지 주기적으로, 이상적으로는 매 배포마다 확인하세요.
3. 버전을 올릴 땐 변경 내용을 한 번 훑기 — 특히 최근 관리자가 바뀌었거나, 다운로드 수 대비 히스토리가 짧은 패키지는 업데이트 전에 diff를 한 번 확인하는 습관이 큰 사고를 막습니다.

공급망 공격은 "내가 뭘 잘못해서" 생기는 게 아니라, 신뢰한 남의 코드가 배신하는 사고입니다. 그래서 방어도 "내 코드"가 아니라 "내가 쓰는 남의 코드 전체" 를 대상으로 해야 합니다.

WhiteHat Code는 저장소의 의존성을 스캔해 알려진 취약점이 있는 패키지를 찾아내고, 업그레이드 경로를 알려드립니다. 자동 스캔은 무료입니다.