오픈소스 패키지를 자동으로 배포하는 과정에는 늘 하나의 불편한 비밀이 있었습니다. CI 서버 어딘가에 npm 공개 권한이 있는 장기 토큰을 저장해야 했다는 점입니다. 토큰이 새면 공격자가 정상 유지관리자인 것처럼 악성 버전을 올릴 수 있습니다. GitHub는 2026년 9월 3일 npm 패키지 하나에 여러 Trusted Publishing 구성을 둘 수 있게 했습니다.
이제 안정판, 사전 공개판, 스테이징용 워크플로를 각각 OIDC 신원으로 연결할 수 있습니다. 장기 토큰을 줄이는 길이 넓어졌지만, 여러 경로 가운데 하나라도 너무 넓은 권한을 가지면 전체 통제가 약해집니다.
저장된 토큰 대신 짧은 신원 증명
Trusted Publishing은 GitHub Actions나 다른 CI가 실행 순간에 OIDC 토큰을 발급받아 npm에 자신을 증명하는 방식입니다. 저장소, 워크플로 파일, 환경 같은 조건이 등록 내용과 맞아야 합니다. 오래 보관되는 공개 토큰이 없으므로 비밀 저장소 유출 위험을 한 가지 줄일 수 있습니다.
이번 업데이트로 패키지마다 최대 10개의 신뢰 게시자를 둘 수 있습니다. 여러 CI 제공자나 stable·prerelease 워크플로를 분리하기 쉬워졌습니다. 기존에 단일 구성 한계를 피하려고 남겨둔 장기 토큰도 정리할 수 있습니다.
여러 설정은 서로를 제한하지 않습니다
주의할 점은 설정이 가산식이라는 사실입니다. 들어온 OIDC 토큰이 어느 한 구성과 맞으면 그 구성의 stage 또는 publish 권한을 얻습니다. 더 엄격한 다른 구성이 느슨한 경로를 덮어쓰지 않습니다. 평가 순서도 보장되지 않습니다.
따라서 설정 수가 늘수록 이름만 보고 안심할 수 없습니다. 저장소 소유자, 워크플로 파일, 환경, 허용 동작, 생성 시점과 담당자를 한 표가 아닌 실제 설정 목록으로 감사해야 합니다. 사용하지 않는 경로는 제거 날짜까지 정해 두는 편이 좋습니다.
검사 뒤 승인하는 스테이징
새 Trusted Publisher는 기본적으로 패키지를 stage할 수 있고, 직접 publish는 구성별로 따로 켜야 합니다. 스테이징은 후보 버전을 먼저 올린 뒤 사람이 승인하는 단계입니다. npm의 악성코드 검사가 끝나기 전에는 승인 버튼도 활성화되지 않습니다.
검사 통과가 코드의 의도까지 보장하지는 않습니다. 악성 서명을 찾지 못했다는 결과와, 변경 내용이 프로젝트가 원한 기능이라는 판단은 다릅니다. 중요한 패키지는 소스 리비전, 빌드 산출물, 승인자와 최종 공개 버전을 연결해 남겨야 합니다.
기존 설정의 기본값부터 확인
npm 문서는 생성 시점에 따라 기존 구성의 기본 동작이 다르다고 설명합니다. 2026년 5월 20일 이전 구성은 직접 공개만 허용하도록 유지되고, 9월 3일 이전 구성은 허용 동작을 명시적으로 골라야 합니다. 새 기본값이 과거 설정을 자동으로 안전하게 바꿨다고 가정하면 안 됩니다.
이번 기능은 자동 배포를 막지 않고도 장기 토큰을 없앨 현실적인 길을 넓혔습니다. 다음 행동은 새 구성을 추가하는 것보다 모든 공개 경로를 먼저 세는 일입니다. 가장 약한 경로 하나가 패키지 전체의 공급망 경계가 됩니다.