개발자의 도구가 공격 통로가 되는 시대
작년부터 올해까지 자바스크립트 생태계는 유례없는 공급망 공격에 시달렸어요. 공급망 공격이 뭐냐면, 여러분의 코드를 직접 해킹하는 게 아니라 여러분이 매일 쓰는 부품, 그러니까 npm 패키지나 GitHub Actions 같은 도구를 오염시켜서 그걸 쓰는 모든 프로젝트를 한꺼번에 노리는 공격이에요. 집을 터는 대신 그 집에 들어가는 수도관에 손을 대는 격이죠. GitHub이 이런 공격에 어떻게 대응하고 있고 앞으로 뭘 바꿀 건지 정리한 글을 공개했는데요, npm을 쓰는 개발자라면(사실상 웹 개발자 전부겠죠) 알아둘 내용이 많아요.
무슨 일들이 있었냐면요
굵직한 사건만 짚어볼게요. 2025년 3월에는 tj-actions/changed-files라는 인기 GitHub Action이 탈취돼서, 이걸 쓰는 수만 개 저장소의 CI 로그에 비밀 키가 노출되는 사고가 있었어요. 같은 해 9월에는 chalk, debug 같은 주간 수억 다운로드급 npm 패키지들의 관리자 계정이 피싱으로 뚫려서 악성 코드가 배포됐고요. 그리고 결정판이 'Shai-Hulud'라고 불린 웜이었는데요, 이게 뭐냐면 감염된 패키지를 설치하면 개발자의 npm 토큰과 GitHub 자격 증명을 훔치고, 그 토큰으로 그 개발자가 관리하는 다른 패키지에까지 악성 코드를 심어 배포하는, 스스로 번식하는 악성코드였어요. 패키지 하나의 감염이 수백 개로 번지는 걸 업계가 실시간으로 지켜봤죠.
이 사건들의 공통 뿌리는 '오래 살아 있는 자격 증명'이에요. 개발자 컴퓨터나 CI 서버에 저장된 장기 토큰이 한 번 유출되면, 공격자가 그 사람 행세를 하며 뭐든 배포할 수 있었던 거예요.
GitHub이 꺼낸 대책들
그래서 대응의 핵심도 토큰을 없애거나 수명을 줄이는 방향이에요. 대표적인 게 'trusted publishing(신뢰 게시)'인데요. 이게 뭐냐면, 배포용 장기 토큰을 아예 만들지 않는 방식이에요. CI(예: GitHub Actions)가 배포를 시도하면, OIDC라는 표준을 통해 '나는 이 저장소의 이 워크플로우에서 실행 중인 빌드야'라는 걸 npm 레지스트리에 암호학적으로 증명하고, 그 자리에서만 유효한 일회성 자격을 받아요. 훔쳐갈 토큰 자체가 존재하지 않으니 유출 걱정이 사라지는 거죠. 파이썬의 PyPI가 먼저 도입해서 효과를 본 방식이기도 해요.
이와 함께 클래식 토큰(권한 범위가 넓고 만료가 없는 옛날 방식 토큰)을 단계적으로 퇴출하고, 새로 만드는 토큰의 수명을 짧게 강제하고, 배포 시 이중 인증(2FA)을 요구하는 등 계정 탈취의 파급력을 줄이는 조치들이 이어지고 있어요. GitHub Actions 쪽에서는 액션을 변경 불가능(immutable)하게 게시하는 방안도 추진 중인데요, 이미 배포된 버전 태그를 나중에 몰래 바꿔치기해서 악성 버전을 끼워 넣는 수법을 원천 차단하려는 거예요.
우리가 당장 할 수 있는 것들
플랫폼의 대책과 별개로, 개발자가 스스로 챙길 수 있는 것들이 있어요.
- 락파일을 꼭 커밋하고, CI에서는 npm ci를 쓰세요. 설치 시점에 따라 다른 버전이 들어오는 걸 막아줘요.
- GitHub Actions는 버전 태그 대신 커밋 SHA로 고정하세요. 태그는 나중에 바꿔치기가 가능하지만 커밋 해시는 불가능하거든요.
- 직접 배포하는 패키지가 있다면 trusted publishing으로 전환하세요. npm 공식 문서를 따라 하면 생각보다 금방 끝나요.
- 의존성 업데이트를 무턱대고 최신으로 따라가지 마세요. 새 버전이 나오고 며칠은 지켜보는 것만으로도 상당수 사고를 피할 수 있어요.
정리하면
공급망 보안의 흐름은 '토큰을 잘 숨기자'에서 '훔칠 토큰 자체를 없애자'로 넘어가고 있어요. 생태계 차원의 변화는 시작됐고, 남은 건 우리 각자의 프로젝트에 적용하는 일이죠. 여러분 팀은 의존성 보안을 어떻게 관리하고 계세요? 락파일 커밋이나 SHA 고정 같은 원칙들, 실제로 지켜지고 있나요?
🔗 출처: Hacker News