npm 패키지에 OIDC 발행자 10개까지…직접 배포는 선택 사항

npm은 2026년 9월 3일 패키지 하나에 최대 10개의 OIDC trusted publisher 구성을 등록하는 기능을 일반 제공했다. GitHub 변경 공지 는 서로 다른 저장소와 워크플로가 하나의 패키지를 발행할 수 있으며, 새 구성에서는 스테이징이 기본으로 허용되고 직접 배포는 별도로 선택한다고 설명한다.

같은 날 일반 제공된 이번 변경의 핵심은 발행자를 여러 개 추가하는 데 그치지 않는다. 각 OIDC 구성을 독립된 발행 경로로 등록하고 스테이징과 직접 배포 권한을 따로 정할 수 있어, 여러 자동화가 같은 패키지를 다루더라도 모두에게 즉시 공개 권한을 줄 필요가 없어졌다.

저장소와 워크플로별 구성을 최대 10개 등록

관리자는 대상 패키지의 trusted publishing 설정에서 실제 배포 작업에 대응하는 구성을 하나씩 추가할 수 있다. 패키지당 등록 한도는 10개다. 릴리스 저장소와 워크플로가 나뉘어 있거나 안정판과 사전 출시판을 서로 다른 자동화가 발행하는 경우에도 패키지 이름을 분리하지 않고 각각의 신뢰 조건을 둘 수 있다.

npm의 공식 설정 문서 에 따르면 trusted publishing은 지원되는 CI/CD 시스템이 실행 시점에 발급한 OIDC 신원을 npm에 등록된 저장소·워크플로 조건과 대조하는 방식이다. GitHub Actions를 연결할 때는 패키지를 실제로 발행하는 저장소와 워크플로 파일을 지정해야 한다. 같은 조직에 속하거나 비슷한 이름을 쓴다는 사실만으로 다른 작업이 해당 신뢰 관계를 공유하지는 않는다.

발행 작업에서는 장기 npm 토큰을 비밀 변수로 전달하는 대신 OIDC 신원을 요청한다. npm은 들어온 신원이 등록 항목 가운데 어느 것과 일치하는지 확인한 뒤 그 구성에 허용된 배포 방식만 적용한다. 복수 구성은 하나의 공용 자격 증명을 여러 저장소에 복제하는 방식과 달리 발행 주체별 경계를 명시할 수 있게 한다.

열한 번째 발행 경로를 추가할 수는 없다. 한도를 넘는다면 중복되거나 사용하지 않는 구성을 정리하거나 릴리스 구조를 다시 묶어야 한다. 다만 여러 작업을 하나의 범용 워크플로로 합치면 그 워크플로가 맡는 역할과 권한이 넓어질 수 있으므로, 단순히 구성 수만 줄이는 것이 최소 권한을 보장하지는 않는다.

새 구성의 기본 경로는 스테이징

새 trusted publisher 구성에는 스테이징 배포가 기본으로 허용된다. 반면 스테이징을 거치지 않고 레지스트리에 곧바로 반영하는 직접 배포는 관리자가 해당 구성에서 명시적으로 선택해야 한다. 제목의 ‘선택 사항’은 직접 배포 기능이 사라졌다는 뜻이 아니라, 새 발행자에게 자동으로 열리지 않는 별도 권한이라는 의미다.

스테이징에 들어간 릴리스는 공개 전에 악성 코드 검사와 승인 절차를 거칠 수 있다. 검사 결과와 패키지에 설정된 승인 조건이 충족된 뒤 공개하도록 발행 흐름을 나눌 수 있으므로, 신뢰된 CI 작업이 실행됐다는 사실만으로 패키지가 즉시 교체되는 경로를 피할 수 있다. 직접 배포를 허용하면 이 사전 검토 경로를 거치지 않으므로 권한 차이가 실질적이다.

이 권한은 패키지 전체에 적용되는 단일 스위치가 아니라 trusted publisher 구성별로 다룬다. 한 패키지에서 일반 릴리스 작업에는 스테이징만 허용하고, 별도로 통제되는 작업에만 직접 배포를 열 수 있다. 여러 발행자를 등록해도 각 항목의 권한이 같아지는 것은 아니며, 한 구성의 직접 배포 허용이 다른 구성으로 확장되지도 않는다.

악성 코드 검사는 공급망 위험을 줄이는 추가 통제 지점이지만 코드의 안전성을 완전히 증명하지는 않는다. 등록된 워크플로 자체가 부적절하게 변경되거나 승인 권한이 탈취되면 신뢰된 경로도 악용될 수 있다. 따라서 OIDC 신원 조건, 저장소의 변경 보호, 승인 규칙과 직접 배포 예외는 서로 다른 방어선으로 봐야 한다.

stable·prerelease·긴급 경로를 분리하는 방법

복수 구성의 효과는 릴리스 종류마다 필요한 권한을 달리할 때 분명해진다. 다음은 기능의 경계를 설명하기 위한 조건부 예시이며, npm이 특정 워크플로 이름이나 운영 정책을 요구한다는 뜻은 아니다.

• stable 워크플로: 보호된 릴리스 조건에서 실행되는 발행자를 별도로 등록하고 스테이징을 허용한다. 직접 배포는 열지 않아 검사와 승인을 통과한 결과만 안정판으로 공개한다.
• prerelease 워크플로: beta나 rc 같은 사전 출시판을 만드는 작업을 독립된 발행자로 등록한다. 이 경로에도 스테이징만 허용하면 사전 출시 자동화가 안정판의 즉시 공개 권한을 함께 갖지 않는다.
• 긴급 배포 워크플로: 스테이징을 기다릴 수 없는 운영 요건이 실제로 있을 때만 별도 구성에 직접 배포를 허용한다. 이 예외는 일반 릴리스 작업과 분리해야 직접 배포 권한을 가진 신뢰 경계를 좁힐 수 있다.

이 구성에서 중요한 것은 발행자 수가 아니라 각 작업이 가진 권한의 범위다. 사전 출시 작업이 손상되더라도 안정판 작업의 신원 조건이나 직접 배포 권한을 자동으로 얻지 않도록 나눌 수 있다. 같은 저장소 안의 워크플로라도 각각 등록하면 어느 자동화가 어떤 배포 경로를 사용할 수 있는지 구분할 수 있다.

반대로 안정판, 사전 출시판과 긴급 배포를 하나의 범용 워크플로에 맡기고 직접 배포까지 허용하면 하나의 신뢰 경로에 권한이 집중된다. 복수 trusted publisher는 이러한 집중을 줄일 수 있는 설정 수단이지만, 워크플로 파일을 바꿀 수 있는 사람과 패키지 설정을 관리할 수 있는 사람의 권한까지 자동으로 제한하지는 않는다.

장기 토큰을 없애도 기존 경로는 따로 점검해야

장기 토큰 방식은 CI의 비밀 저장소에 npm 자격 증명을 보관하고 만료, 교체와 회수를 관리해야 한다. 같은 토큰을 여러 워크플로에서 재사용하면 한 경로에서 유출된 자격 증명이 다른 발행 작업에도 영향을 줄 수 있다. 인증 판단도 실제 워크플로의 OIDC 신원보다는 제시된 토큰의 유효성과 권한에 의존한다.

OIDC trusted publishing은 실행 때 발급된 신원과 미리 등록한 조건을 맞추므로 npm 발행용 장기 비밀을 워크플로에 저장할 필요를 줄인다. 이번 복수 구성은 이 모델을 패키지당 하나의 자동화에 묶지 않고 최대 10개의 명시된 발행 경로로 확장한다. 구성별로 직접 배포 여부까지 나눌 수 있다는 점이 단순한 등록 한도 증가보다 중요한 변화다.

다만 전환 과정에서 기존 npm 토큰을 계속 사용할 수 있게 남겨 두면 실제 발행 권한은 OIDC 경로와 토큰 경로의 합으로 결정된다. trusted publisher를 스테이징 전용으로 좁혀도 오래된 토큰이 즉시 발행을 허용한다면 같은 통제 효과를 얻을 수 없다. 사용하지 않는 토큰의 회수 여부는 복수 OIDC 구성을 추가하는 작업과 별도로 확인해야 한다.

기존 trusted publisher의 권한이 새 구성의 기본값과 같다고 단정해서도 안 된다. 발표에서 명시한 스테이징 기본 허용과 직접 배포의 별도 선택은 새 구성에 관한 설명이므로, 이미 운영 중인 항목은 저장된 권한 상태를 개별적으로 확인해야 한다. 이 점검은 기존 자동화가 계속 작동하는지와 의도하지 않은 직접 배포 예외가 남았는지를 함께 확인하는 과정이다.

일반 제공 이후 남은 경계

현재 확정된 범위는 패키지당 최대 10개의 독립된 trusted publisher 구성, 새 구성의 스테이징 기본 허용, 구성별 직접 배포 선택이다. 실제 발행에는 지원되는 CI/CD 환경, 등록된 OIDC 신원 조건과 해당 구성에 허용된 배포 방식이 모두 맞아야 한다. 등록 가능한 숫자가 늘었다고 패키지의 발행 권한 자체가 자동으로 넓어지는 것은 아니다.

이번 변경으로 여러 저장소와 워크플로를 하나의 npm 패키지에 연결할 수 있게 됐지만, 10개를 넘는 구성이나 새로운 CI/CD 발행자 유형까지 발표된 것은 아니다. 이후 한도, 지원 대상 또는 승인 규칙이 확대되는지는 npm 공식 문서와 후속 변경 공지에서 확인해야 한다.

함께 읽기:

• CrowdStrike가 npm·PyPI 다운로드를 가로막는다…악성 코드 실행 전 차단