가짜 사고 보고서가 찌른 오픈소스 공급망 보안의 진짜 아픈 곳

사고는 피싱 하나로 시작해서 생태계 전체를 탔다

• 이 글은 진짜 사고 보고서 형식을 빌린 풍자지만, 찌르는 지점은 꽤 현실적임

  • 상태는 '해결됨, 우연히'이고 심각도는 'Critical → Catastrophic → Somehow Fine'
  • 영향 시스템은 그냥 'Yes'라고 적어놓음. 이 정도면 보안팀의 영혼이 나간 문서 양식임

• 첫 발단은 자바스크립트 패키지 관리자 계정 탈취임

  • left-justify라는 패키지 관리자가 교통카드, 오래된 노트북, 그리고 '쿠버네티스가 토해낸 것처럼 생긴 뭔가 중요한 것'을 도난당함
  • 하드웨어 2단계 인증 키를 잃어버린 뒤, 검색 결과 상단 AI 요약이 안내한 가짜 YubiKey 사이트에 계정을 입력함
  • 공격자는 이 계정으로 패키지에 postinstall 스크립트를 넣고 .npmrc, .pypirc, Cargo 자격 증명, RubyGems 자격 증명을 빼감

• 그다음 공격은 Rust 생태계로 넘어감

  • 탈취된 자격 증명 중에는 vulpine-lz4라는 Rust 압축 라이브러리 관리자의 권한도 있었음
  • 이 라이브러리는 GitHub 별이 12개뿐인데, cargo 자체의 전이 의존성이라는 설정임
  • 버전 0.4.1에는 build.rs가 추가되고, 호스트명이 build, ci, action, jenkins, travis 같은 문자열을 포함하면 셸 스크립트를 내려받아 실행함

Python 빌드 도구까지 번지면서 사고가 커진다

• 공격은 snekpack이라는 Python 빌드 도구로 이어짐

  • snekpack은 이름에 data가 들어간 PyPI 패키지의 60%가 쓴다는 설정임
  • 이 도구는 'Rust는 메모리 안전하니까'라는 이유로 vulpine-lz4를 벤더링하고 있었음
  • 결국 snekpack 3.7.0이 악성 코드를 포함한 채 배포되고, 전 세계 개발자 머신에 설치됨

• 악성 동작도 일부러 과장돼 있는데, 실제 사고에서 볼 법한 것들이 섞여 있음

  • ~/.ssh/authorized_keys에 SSH 키를 추가함
  • 화요일에만 켜지는 리버스 셸을 설치함
  • 사용자의 기본 셸을 fish로 바꾸는데, 이건 버그로 추정된다는 농담까지 붙음

• 탐지와 대응은 더 씁쓸한 쪽으로 흘러감

  • 보안 연구자가 이슈를 열었지만 관리자가 복권에 당첨돼 포르투갈에서 염소 농장을 알아보는 중이라 답이 없음
  • 한 주니어 개발자가 벤더링된 라이브러리를 되돌리는 PR을 열지만, 승인자 두 명이 자고 있어서 대기함
  • 사고 대응 Slack은 'compromised' 철자를 미국식으로 쓸지 말지 45개 메시지를 낭비함

제일 웃긴 해결책은 악성 웜이었다

• 사고를 끝낸 건 보안 프로세스가 아니라, 전혀 무관한 암호화폐 채굴 웜임

  • cryptobro-9000이라는 웜이 jsonify-extreme 취약점을 타고 퍼짐
  • 이 웜은 공격면을 넓히려고 감염된 머신에서 npm update와 pip install --upgrade를 실행함
  • 그 결과 snekpack이 우연히 3.7.1로 올라가고, 혼란스러운 공동 관리자가 이전 벤더링 버전으로 되돌린 덕에 악성 코드가 제거됨

• 피해 규모도 일부러 말도 안 되게 쓰였지만, 공급망 사고의 감각은 잘 살아 있음

  • 악성 코드는 약 420만 개발자에게 배포됐다고 설정됨
  • 암호화폐 웜이 구한 머신도 약 420만 대라고 추정됨
  • 최종 보안 태세 변화는 '불편함'으로 정리됨. 틀린 말은 아닌 듯함

진짜 메시지는 사후대응 문구가 아니라 책임 구조다

• 근본 원인은 '쿠버네티스라는 이름의 개가 YubiKey를 먹었다'로 끝나지만, 기여 요인은 훨씬 현실적임

  • 주간 다운로드 1천만 미만 패키지에는 여전히 비밀번호만으로 인증이 가능하다는 설정
  • 검색 AI가 존재하면 안 되는 URL을 자신 있게 추천함
  • npm식 작은 패키지 철학이 Rust 생태계로 옮겨가며 핵심 인프라 깊숙이 들어감
  • Python 빌드 도구가 성능 때문에 Rust 라이브러리를 가져와 놓고 업데이트를 안 함

• 개선책 목록은 일부러 서로 충돌하게 적혀 있음

  • 아티팩트 서명은 2022년 3분기 사고의 액션 아이템인데 아직 백로그에 있음
  • 의무 2FA는 이미 있었지만 도움이 안 됨
  • 의존성을 고정하면 보안 패치를 못 받고, 고정하지 않으면 공급망 공격을 받음
  • Rust로 다시 쓰자는 말에는 이미 Rust 라이브러리가 사고 경로였다는 몸짓만 남음

---

기술 맥락

• 이 글이 웃긴 이유는 의존성 그래프의 책임자가 없다는 현실을 정확히 찌르기 때문이에요. 앱 개발자는 직접 설치한 패키지만 봤다고 생각하지만, 실제 빌드에는 npm, Cargo, PyPI, 벤더링된 코드, CI 스크립트가 한꺼번에 끼어들거든요.

• postinstall 스크립트나 build.rs가 무서운 이유는 설치와 빌드가 곧 실행이 되기 때문이에요. CI 환경에는 배포 토큰, 레지스트리 권한, SSH 키 같은 민감한 값이 많아서, 패키지 하나가 오염되면 단순 라이브러리 버그가 아니라 계정 탈취로 번질 수 있어요.

• 버전 핀ning도 답이 하나로 떨어지지 않아요. 버전을 고정하면 갑작스러운 악성 업데이트는 피할 수 있지만, 보안 패치도 늦게 들어와요. 반대로 자동 업데이트를 열어두면 패치는 빨리 받지만, 오염된 릴리스도 빨리 받는 구조가 돼요.

• 그래서 현실적인 방어는 한 방짜리 해결책보다 여러 층을 쌓는 쪽이에요. 패키지 서명, 배포 권한 최소화, CI 비밀값 격리, 의존성 감사, 의심스러운 설치 스크립트 차단이 같이 가야 의미가 있어요.