npm 배포 토큰을 지워도 된다…OIDC 전환은 검증 후 폐기가 순서다
기술 및 혁신
npm 토큰을 훔쳐도 바로 배포 못 한다…단, 쓰기 권한은 남는다
npm이 2026년 9월 18일 세분화 액세스 토큰에 Read and write (stage only) 권한을 출시했다. GitHub의 공식 출시 공지 에 따르면 이 토큰은 자동화가 올린 새 버전을 즉시 공개하지 않고 유지관리자의 2단계 인증(2FA) 승인까지 대기시킨다. 다만 dist-tag 이동과 기존 버전 폐기 권한은 그대로여서 읽기 전용 토큰으로 볼 수 없다.
전환의 핵심은 CI/CD에 저장된 기존 배포 토큰을 새 stage-only 토큰으로 교체하고 npm publish를 npm stage publish로 바꾸는 것이다. npm 액세스 토큰 문서 는 일반 publish 요청이 E_STAGE_REQUIRED 오류로 거부되고, 유지관리자가 대기 버전을 검토한 뒤 2FA로 승인해야 공개된다고 설명한다. 따라서 토큰이 유출돼도 새 버전의 즉시 배포는 막히지만 패키지 상태를 바꿀 수 있는 위험까지 사라지지는 않는다.
막힌 경로는 새 버전의 직접 공개다
stage-only는 쓰기 권한을 모두 제거하는 방식이 아니라 공개 절차를 자동화와 사람의 승인으로 나눈다. 자동화는 패키지 파일을 승인 대기 상태에 올릴 수 있지만, 그 상태의 버전은 일반 이용자가 설치할 수 있는 공개 버전이 아니다. Bypass 2FA가 설정돼 있더라도 stage-only 토큰으로 실행한 직접 publish는 허용되지 않는다.
유지관리자는 npm stage list로 대기 항목을 확인하고 npm stage view <stage-id> 또는 npm stage download <stage-id>로 메타데이터와 패키지 파일을 검토할 수 있다. 승인은 npm stage approve <stage-id> --otp <code>, 거부는 npm stage reject <stage-id>로 처리한다. 새 버전이 레지스트리에 공개되는 시점은 자동화 작업이 끝났을 때가 아니라 2FA를 사용하는 유지관리자가 승인을 마쳤을 때다.
이 경계는 토큰 탈취자가 악성 버전을 곧바로 공개하는 경로를 끊는다. 그러나 승인 요청 자체는 만들 수 있으므로 유지관리자는 패키지 이름, 버전, 내용물을 확인하지 않은 채 대기 항목을 승인해서는 안 된다. stage-only는 검토 단계를 강제하지만 그 검토의 정확성까지 보장하는 장치는 아니다.
dist-tag와 deprecate는 여전히 바꿀 수 있다
직접 배포 불가는 패키지에 대한 쓰기 불가와 같은 뜻이 아니다. stage-only 토큰은 검토용 버전을 올리는 것 외에도 이미 공개된 버전의 dist-tag를 이동하고, 특정 버전을 폐기 상태로 표시할 수 있다. npm도 이를 범용 보안 경계로 취급하지 말고 다른 쓰기 토큰과 같은 수준으로 보호하라고 명시한다.
dist-tag는 버전 번호 대신 사용하는 별칭이다. 예를 들어 이용자가 명시적인 버전을 지정하지 않고 패키지를 설치하면 latest 태그가 가리키는 버전이 선택될 수 있다. 탈취된 stage-only 토큰이 새 코드를 공개하지는 못하더라도 이 태그를 기존의 다른 버전으로 옮기면 기본 설치 결과에 영향을 줄 수 있다.
deprecate 역시 코드를 삭제하는 동작은 아니지만 무해하지 않다. 공격자가 정상 버전에 폐기 메시지를 붙이면 설치 과정에 경고가 표시되고, 유지관리자가 의도하지 않은 안내가 이용자에게 전달될 수 있다. 토큰 노출이 확인되면 승인 대기 버전뿐 아니라 dist-tag 변경과 deprecate 이력도 함께 점검해야 하는 이유다.
노출된 토큰은 즉시 폐기하고 CI/CD의 자격 증명을 교체해야 한다. 패키지와 scope를 필요한 범위로 제한하고 IP 범위와 만료 기간을 설정해 두면 토큰 하나가 영향을 줄 수 있는 영역을 줄일 수 있다. stage-only라는 이름만 보고 사고 대응의 우선순위를 낮추면 남아 있는 쓰기 권한을 놓치게 된다.
자동 배포를 옮기는 최소 조건과 절차
staged publishing은 이미 npm 레지스트리에 존재하는 패키지의 후속 버전에 적용된다. 토큰을 만드는 계정에는 해당 패키지의 publish 권한과 활성화된 2FA가 필요하다. 실행 환경은 npm CLI 11.15.0 이상과 Node.js 22.14.0 이상이어야 한다.
- npm 토큰 관리 화면에서 자동화에 필요한 패키지나 scope만 선택하고 권한을 Read and write (stage only)로 설정한 세분화 토큰을 만든다.
- CI/CD 비밀 저장소의 기존 배포 토큰을 새 토큰으로 교체한다. 사용하지 않게 된 기존 토큰은 별도로 폐기한다.
- 릴리스 명령을 npm publish에서 npm stage publish로 변경한다. 필요한 경우 기존 publish 흐름처럼 배포할 dist-tag도 명시한다.
- 자동화 성공과 공개 완료를 구분하도록 상태 확인과 알림을 조정한다. 유지관리자의 검토와 2FA 승인이 끝나야 공개가 완료된다.
빌드, 테스트, 패키징과 승인 대기 버전 제출까지는 자동화할 수 있지만 최종 공개에는 사람이 개입한다. 완전 무인 배포가 반드시 필요한 워크플로라면 이 승인 모델과 운영 요건이 맞지 않을 수 있다. 장기 토큰을 보관하지 않는 배포가 목적이라면 OIDC 기반 배포 경로 를 별도로 검토할 수 있다.
기존 토큰은 자동으로 바뀌지 않는다
이번 기능은 선택형 출시다. 새 stage-only 토큰을 만들고 워크플로의 자격 증명과 명령을 교체하기 전까지 기존 토큰의 직접 공개 능력은 현재 설정대로 유지된다. 기능 출시 자체가 저장소나 CI에 남은 장기 토큰의 위험을 즉시 줄여 주는 것은 아니다.
독립적인 소프트웨어 변경 추적 서비스인 megachangelog의 9월 18일 기록 도 stage-only 권한을 자동화가 전체 publish 권한 없이 검토용 버전을 올리게 하는 npm 기능으로 분류했다. 다만 구체적인 보안 경계와 명령 동작은 npm 공식 문서에 적힌 범위를 기준으로 판단해야 한다.
npm은 Bypass 2FA 토큰을 통한 새 버전 직접 공개를 2027년 1월에 제거하는 일정을 목표로 제시했다. 이는 현재 완료된 변경이 아니라 예정된 정책 전환이다. trusted publishing으로 곧바로 옮기기 어려운 토큰 기반 자동화에는 stage-only가 중간 전환 경로가 된다.
현재 확인된 상태는 stage-only 토큰이 실제로 제공되고, 새 버전의 직접 공개 차단과 유지관리자의 2FA 승인 흐름이 공식 문서에 반영됐다는 것이다. 반면 기존 토큰은 그대로이며 dist-tag 이동과 버전 폐기 권한도 stage-only 토큰에 남는다. 생태계 전반의 전환율이나 주요 릴리스 도구가 이 흐름을 기본 지원할 시점은 아직 공개되지 않았다.
함께 읽기:
관련 기사
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.
0