npm tek pakete 10 OIDC yayıncısı açtı; doğrudan yayın varsayılan değil

npm, 3 Eylül 2026’da bir paket için birden fazla trusted publishing yapılandırmasını genel erişime açtı. GitHub’ın 3 Eylül duyurusuna göre farklı depo, iş akışı ve ortam ölçütlerine sahip OIDC bağlantıları artık aynı paketi yetkilendirebiliyor; her bağlantı bağımsız ve toplamsal çalışıyor.

Değişiklik paket başına en fazla 10 bağlantıya izin veriyor. 3 Eylül 2026’dan sonra oluşturulan bağlantılar staging yetkisiyle başlıyor, doğrudan npm publish hakkı ise bağlantı bazında ayrıca seçiliyor; AiCybr’ın bağımsız incelemesi de genel erişim durumunu, 10 bağlantı sınırını ve bu varsayılanı doğruluyor.

Her eşleşme ayrı bir yayın yolu açıyor

Çoklu yapılandırmalar birbiri üzerine eklenen kısıtlar değil, bağımsız yetki yolları oluşturuyor. Gelen OIDC kimliğinin kayıtlardan herhangi birindeki depo, workflow ve varsa ortam ölçütlerini karşılaması, o kaydın izin verdiği staging veya doğrudan yayın işlemi için yeterli. Kayıtların değerlendirme sırası garanti edilmiyor.

Bu nedenle dar kapsamlı yeni bir kayıt, daha geniş eski bir kaydı sınırlandırmıyor. Örneğin üretim ortamını zorunlu tutan bir kararlı sürüm bağlantısı eklemek, ortam koşulu bulunmayan başka bir workflow’un mevcut yetkisini kendiliğinden kaldırmaz. İki kayıt da kendi başına eşleşebilir.

Güvenlik açısından doğru model bir “VE” zinciri değil, bir “VEYA” kümesidir. Pakete bağlı her depo, workflow, ortam ve CI sağlayıcısı ayrı bir giriş noktası sayılmalı; bir bağlantıda doğrudan yayın kapalı olsa bile başka bir eşleşen bağlantı aynı işlemi yetkilendirebilir.

Kararlı, ön sürüm ve geçiş yolları nasıl ayrılabilir?

Aşağıdaki yetki matrisi npm’in zorunlu tuttuğu bir şablon değil, toplamsal modeli dar yetkilerle kullanmak için temsili bir kurulumdur. Her satırın ayrı bağlantı olması, hangi kimliğin hangi sürüm kanalına ulaşabildiğini görünür kılar.

• Kararlı sürüm: Korunan üretim ortamına bağlı ayrı bir release workflow’u kullanılır. Tamamen gözetimsiz yayın zorunluysa yalnızca bu bağlantıda doğrudan npm publish açılır; değilse sürüm staging onayına bırakılır.
• Ön sürüm: Beta ve sürüm adayı etiketleri için ayrı workflow ve mümkünse ayrı ortam ölçütü tanımlanır. Bağlantı yalnızca npm stage publish çalıştırır; sürüm kayıt defterinde görünür olmadan önce insan onayı gerekir.
• Staging veya CI geçişi: Yeni sağlayıcıyı, depo taşınmasını ya da yenilenmiş workflow’u doğrulayan bağlantı stage-only tutulur. Geçiş tamamlandığında eski bağlantı bağımsız olarak kaldırılır.

Bu matriste üç yol aynı pakete ulaşır, ancak yalnızca kararlı sürüm hattı gerekçelendirilmişse doğrudan yayın yapabilir. Ön sürüm bağlantısını staging ile sınırlamak, kararlı sürüm bağlantısının hakkını azaltmaz; güvenlik ayrımı her kaydın kendi kimlik ölçütleri ve izinleri üzerinden sağlanır.

10 bağlantı sınırı yeni ve eski kayıtları aynı biçimde dönüştürmüyor

Güncel npm trusted publishing belgesi, aynı anda paket başına en fazla 10 bağlantıyı; GitHub-hosted GitHub Actions, GitLab.com shared runner ve CircleCI cloud desteğini; self-hosted runner’ların henüz desteklenmediğini ve OIDC için en az npm CLI 11.5.1 ile Node.js 22.14.0 gerektiğini belirtiyor.

3 Eylül 2026’dan sonra oluşturulan kayıtlar otomatik olarak npm stage publish izni alıyor; aynı kaydın doğrudan yayın yapması için npm publish ayrıca etkinleştiriliyor. Dolayısıyla başlıktaki varsayılan, yeni bağlantıları anlatıyor: mevcut bütün kayıtlar topluca stage-only duruma çevrilmiş değil.

20 Mayıs 2026’dan önce oluşturulan bağlantılar yalnızca doğrudan yayına izin veren önceki davranışını koruyor. 3 Eylül’den önce oluşturulmuş diğer bağlantılarda da mevcut workflow’u kendiliğinden değiştiren bir dönüşüm yapılmıyor; yeni izin modelinde en az bir eylemin açıkça seçilmesi gerekiyor. Mevcut bağlantıların sağlayıcısı ve zorunlu kimlik alanları yerinde değiştirilemiyor; farklı değerler için kayıt silinip yeniden oluşturuluyor.

Geçiş denetimi tek kayda değil bütün pakete bakmalı

Güvenli geçişin temel sorusu “yeni bağlantı doğru mu?” değil, “bu paketi hangi yollar yayımlayabiliyor?” olmalı. Envanter kararlı, ön sürüm, staging, acil sürüm ve sağlayıcı geçişi workflow’larının yanında kullanılmaya devam eden yazma token’larını da kapsamalı.

1. Pakete bağlı bütün trusted publisher kayıtlarını ve yayın yetkili otomasyon token’larını listeleyin.
2. Her kaydı hizmet ettiği sürüm kanalıyla eşleştirin; depo, workflow ve ortam değerlerini ayrı ayrı doğrulayın.
3. Yeni bağlantıları stage-only olarak kurup gerçek bir staging işlemiyle OIDC eşleşmesini sınayın.
4. Gözetimsiz yayın zorunlu değilse doğrudan yayın seçeneğini kapalı bırakın.
5. Yeni yol doğrulandıktan sonra eski workflow bağlantılarını ve gereksiz yazma token’larını kaldırın.
6. Daha geniş bir eski kaydın, dar kapsamlı yeni kayıtların amaçladığı ayrımı boşa çıkarmadığını yeniden kontrol edin.

Staged sürümlerde onay, zararlı yazılım taraması tamamlanana kadar kullanılamıyor; sürüm geçmişi de paket sahibine bir sürümün staging aşamasında kaldığını, onaylandığını veya reddedildiğini gösteriyor. Mevcut durumda çoklu OIDC desteğinin güvenlik sonucu bağlantı sayısından değil, bağımsız ve toplamsal çalışan her yayın yoluna verilen yetkinin birlikte denetlenmesinden doğuyor.

Ayrıca okuyun:

• Disctopia’dan Apple Podcasts’a tek panelde video ve ücretli bölüm yayını
• PaperCut’ta üçüncü acil yama: İlk iki sürüm artık yeterli değil
• CrowdStrike zararlı paketi indirmede durduracak: npm ve PyPI kapsamda