깃허브가 이번 주 자사 npm(Node Package Manager) 레지스트리의 보안 체계를 대폭 강화하는 마지막 단계를 적용했다. Node.js 생태계에서 가장 널리 사용되는 npm 레지스트리를 대상으로, 증가하는 소프트웨어 공급망 공격 위협에 보다 강하게 대응하겠다는 취지다.

앞서 두 달 전 예고한 대로, 12월 9일을 기점으로 npm은 만료 기한 없이 사용되던 ‘클래식(classic) 토큰’ 또는 ‘장기 토큰(long-lived tokens)’을 전면 폐기했다. 이 토큰은 그동안 개발자가 패키지를 인증할 때 별도의 만료일 없이 사용할 수 있었지만, 앞으로는 더 이상 허용되지 않는다.

이에 따라 개발자는 두 가지 방식 중 하나로 전환해야 한다. 하나는 수명이 짧고 권한 범위가 제한된 ‘세분화 접근 토큰(GAT, Granular Access Tokens)’을 사용하는 방식이며, 다른 하나는 OpenID Connect(OIDC)와 OAuth 2.0을 기반으로 한 완전히 새로운 자동화 CI/CD 퍼블리싱 파이프라인으로 업그레이드하는 방식이다.

이번 조치는 최근 급증한 공급망 공격에 대한 직접적인 대응이다. 특히 9월 발생한 ‘Shai-Hulud 웜’ 사건에서는 공격자가 개발자 계정과 토큰을 탈취한 뒤 수백 개의 패키지에 백도어를 심는 데 성공해 업계에 큰 충격을 줬다.

깃허브의 보안 연구 디렉터인 자비에 르네-코라이유는 당시 “이러한 침해 사고는 오픈소스 생태계에 대한 신뢰를 약화시키고, 전체 소프트웨어 공급망의 무결성과 보안에 직접적인 위협이 된다”라며 “인증과 안전한 퍼블리싱 관행의 기준을 높이는 것이 npm 생태계를 미래의 공격으로부터 보호하는 데 필수적”이라고 설명했다.

개발자 부담과 실질적 영향

이번 변경으로 개발자가 체감하는 영향은 적지 않다. 이번 주부터 클래식 토큰으로 인증된 패키지에 대해 npm publish나 npm install을 실행하면 ‘401 Unauthorized’ 오류가 발생한다. 만료 기한이 없는 새로운 클래식 토큰은 더 이상 생성할 수 없다.

다만, 만료일이 설정된 세분화 토큰은 2026년 2월 3일까지 계속 사용할 수 있다. 이후에는 토큰의 최대 수명이 90일로 제한되며, 주기적으로 토큰 로테이션을 수행해야 한다.

추가 업무의 규모는 조직의 크기와 관리 중인 패키지 수에 따라 달라진다. 대규모 조직의 경우, 이미 대비가 되어 있지 않다면 여러 팀에 걸쳐 수백 개 패키지를 점검해야 할 수 있다. 이 과정에서 기존 클래식 토큰을 모두 폐기하고, 세분화 토큰을 주기적으로 교체하는 절차를 새로 마련해야 한다.

“아직 충분하지 않다”는 지적도

그러나 이번 개편이 보안 측면에서 충분한 조치인지에 대해서는 회의적인 시각도 있다. 지난달, 오픈JS 재단(OpenJS Foundation)은 깃허브가 장기적으로 도입하려는 토큰리스(tokenless) OIDC 보안 모델의 성숙도가 아직 부족하다고 지적했다.

재단은 공격자가 패키지를 침해하는 과정에서 개발자 계정 탈취가 빈번하게 발생하는 만큼, 계정 자체에 대한 다중요소인증(MFA) 강화에 더 큰 비중을 둬야 한다고 언급했다. 현재 npm은 소규모 개발자 계정에 MFA를 의무화하지 않고 있으며, OIDC 역시 패키지 퍼블리싱 과정에서 추가적인 MFA 단계를 요구하지 않는다. 특히 자동화 워크플로 환경에서는 MFA를 적용할 방법 자체가 없는 상황이다.

여기에 더해, 일부 MFA 방식은 중간자 공격(man-in-the-middle)에 취약할 수 있다는 점도 문제로 지적된다. 이 때문에 인증 수단은 이러한 공격 기법에 저항할 수 있어야 한다는 요구가 나온다.

공급망 보안 기업 소나타입(Sonatype)의 지역 부사장인 미툰 자베리는 “공격자는 자원이 부족하지만 널리 사용되는 프로젝트의 유지관리자를 노리는 뚜렷한 패턴을 보이고 있다”고 분석했다. 그는 “최근 Chalk, Debug 같은 npm 패키지 침해 사례는 XZ Utilities 백도어 사건과 유사하다”며 “공격자는 오랜 시간 신뢰를 쌓은 뒤 통제권을 확보했고, 이는 사회공학이 이제 공급망 공격의 핵심 단계가 됐다는 점을 보여준다”고 설명했다.

자베리는 npm과 같은 오픈소스 패키지 관리 레지스트리를 중요 인프라로 인식하고 그에 걸맞은 자원 투자가 필요하다고 지적했다. 아울러 조직은 침해 가능성을 전제로, 정확한 소프트웨어 자재 명세서(SBOM)를 유지하고, 의심스러운 의존성 변경을 모니터링하며, 빌드 환경을 샌드박싱하는 방식으로 대응해야 한다고 제언했다.
dl-ciokorea@foundryco.com