Bir npm paketini hem kararlı sürüm, hem ön sürüm, hem de kontrollü bir hazırlama hattından yayımlıyorsanız bugüne kadar tatsız bir seçimle karşılaşmış olabilirsiniz: tek OIDC yapılandırmasına sığmaya çalışmak ya da bazı işler için uzun ömürlü erişim belirteci saklamak. GitHub’ın 3 Eylül 2026’da genel kullanıma açtığı değişiklik, aynı paket için birden fazla trusted publishing yapılandırmasına izin vererek bu sıkışmayı azaltıyor.

Değişiklik yalnız “bir ayar daha geldi” diye okunmamalı. Doğru kurulduğunda yayın anahtarlarını CI kasalarında yıllarca tutma ihtiyacını azaltabilir; yanlış kurulduğunda ise gereksiz sayıda hattın paketi yayımlamasına yol açabilir. Bu rehber, duyurudaki doğrulanmış sınırları ve küçük bir Türkiye ekibinin uygulayabileceği geçiş testini ayrı ayrı ele alıyor.

Ne değişti?

GitHub’ın 3 Eylül 2026 tarihli duyurusuna göre bir npm paketi artık birden fazla trusted publishing, yani OIDC yapılandırmasına sahip olabiliyor. Her yapılandırmanın kendi depo, iş akışı ve ortam ölçütleri bulunuyor. Gelen OIDC belirteci bunlardan herhangi biriyle eşleşirse yayımlama veya hazırlama işlemi yetkilendirilebiliyor.

Bu, örneğin release.yml ile kararlı sürüm, prerelease.yml ile beta sürüm ve ayrı bir ortamla hazırlama süreci çalıştıran ekiplerin her hattı bağımsız tanımlayabilmesi anlamına geliyor. Önceden tek yapılandırma sınırı nedeniyle iş akışı hileleri veya OIDC’nin kapsamadığı yol için uzun ömürlü belirteç gerekebiliyordu.

İki ayrıntı özellikle önemli

Yapılandırmalar birbirini kısıtlamıyor; bağımsız ve eklemeli çalışıyor. GitHub ayrıca değerlendirme sırasının garanti edilmediğini söylüyor. Dolayısıyla “önce dar kural, sonra geniş kural çalışır” gibi bir mantık kurmak güvenli değil. Her yapılandırma tek başına kabul edilebilir ölçüde dar olmalı.

İkinci ayrıntı, her yapılandırmanın varsayılan olarak paketi hazırlayabilmesi; doğrudan yayımlamanın ise yapılandırma bazında açılması. GitHub, yapılandırmaları yalnız hazırlama modunda tutmayı öneriyor. Hazırlama, sürüm kayıt defterinde görünür olmadan önce insan onayı ekliyor. Duyuruya göre zararlı yazılım taraması bitmeden onay düğmesi de kullanılamıyor.

OIDC neden uzun ömürlü belirteçten farklı?

Uzun ömürlü npm belirteci bir sırdır: sızarsa süresi dolana veya iptal edilene kadar kullanılabilir. OIDC tabanlı trusted publishing ise iş akışının kimliğini kısa ömürlü bir kanıtla doğrulamayı hedefler. Paket yöneticisi; depo, iş akışı ve ortam gibi bağlamları denetler. Bu nedenle CI değişkenlerinde kalıcı yayın anahtarı taşımadan çalışmak mümkün olur.

Buradan “OIDC kullanınca tedarik zinciri riski biter” sonucu çıkmaz. İş akışı dosyasını değiştirebilen hesap, korumasız bir ortam veya aşırı geniş GitHub yetkileri hâlâ kritik risklerdir. Bu bölüm bir çıkarımdır: yeni özellik sır yönetimini kolaylaştırır, fakat depo yönetişiminin yerini almaz.

Üç hatlı güvenli kurulum modeli

1. Kararlı sürümü ayrı tutun

Kararlı sürüm hattını yalnız korunan etiketten ve onaylı GitHub ortamından çalıştırın. Doğrudan yayımlama gerçekten gerekmiyorsa kapalı bırakın; paketi önce hazırlayıp sürüm sahibinin onaylamasını isteyin. Küçük ekiplerde bile “kodu yazan kişi” ile “paketi yayımlayan kişi” ayrımı pahalı bir süreç değildir.

2. Ön sürümü ayrı iş akışına bağlayın

Beta veya aday sürümler için farklı bir iş akışı ve farklı ortam kullanın. Etiket desenini, dal korumasını ve npm dağıtım etiketini iş akışında açıkça tanımlayın. Yapılandırmaların birbirini daraltmadığını unutmayın: ön sürüm hattının kararlı sürümü yanlışlıkla çıkaramaması yalnız npm ayarına değil, iş akışı mantığına da bağlıdır.

3. Hazırlamayı varsayılan yol yapın

GitHub’ın önerisiyle uyumlu olarak yeni yapılandırmaları önce yalnız hazırlama yetkisiyle açın. Birkaç gerçek sürüm boyunca geçmiş kaydını inceleyin. Duyuru, paket sürümleri sekmesinde sürümün onaylandığı, reddedildiği veya hâlâ beklediği bilgisinin bakımcılara gösterildiğini belirtiyor.

15 dakikalık geçiş testi

  1. npm paket ayarlarında mevcut trusted publishing yapılandırmalarını listeleyin.
  2. Her satır için depo, iş akışı dosyası, ortam ve doğrudan yayın yetkisini yazın.
  3. Kullanılmayan eski iş akışlarını kaldırmadan önce son çalışma tarihini kontrol edin.
  4. Yeni ön sürüm yapılandırmasını yalnız staging ile ekleyin.
  5. Zararlı yazılım taraması sürerken onay verilemediğini test ortamında doğrulayın.
  6. Kararlı ve ön sürüm iş akışlarının birbirinin etiketini kabul etmediğini deneyin.
  7. CI kasasındaki eski npm belirtecini ancak OIDC ile gerçek yayın başarıyla tamamlandıktan sonra iptal edin.

Eski belirteci silmeden önce hangi dosyanın ve sürümün kullanıldığını doğrulamak için SHA-256 dosya doğrulama rehberindeki yaklaşımı yayın çıktınıza da uygulayabilirsiniz. Amaç, yalnız “iş akışı yeşil” demek değil; beklenen paketin beklenen kaynak kodundan üretildiğini kanıtlamaktır.

Türkiye’deki küçük ekip için pratik karar

Tek paketi tek iş akışıyla yayımlayan ekip hemen üç yapılandırma açmak zorunda değil. Asıl fırsat, uzun ömürlü npm belirtecini kaldırmak ve yayın yolunu daraltmak. Kararlı, beta ve staging hatları gerçekten ayrılıyorsa çoklu yapılandırma anlamlıdır; yalnız isimleri farklı aynı iş yapan hatlar için ek karmaşıklık yaratır.

Son kontrol sorusu basit: Her yapılandırma tek başına ele geçirildiğinde saldırgan doğrudan canlı sürüm yayımlayabiliyor mu? Yanıt evetse, staging ve insan onayı katmanını güçlendirin. Yeni özellik daha fazla esneklik sunuyor; güvenlik kazancı ise bu esnekliği ne kadar ölçülü kullandığınıza bağlı.