npm’de granular access token oluştururken artık Read and write (stage only) iznini seçebiliyorsunuz. Bu izinle üretilen token, otomasyon iş akışlarının paket sürümlerini inceleme için sahneye almasına (staging) izin veriyor, ama aynı token registry’ye doğrudan yeni sürüm yayınlayamıyor. CI/CD hattı sürümü hazırlıyor, yayın kararını ise iki faktörlü kimlik doğrulamayla (2FA) bir paket bakımcısı veriyor.
Stage-only token tam olarak neyi değiştiriyor?
Klasik yayın akışında otomasyona verdiğiniz token, npm publish komutuyla doğrudan registry’ye sürüm gönderebiliyordu. Token sızdığında ya da iş akışı ele geçirildiğinde saldırgan anında zararlı bir sürüm yayınlayabiliyordu.
Stage-only token bu zinciri ikiye bölüyor:
- İş akışınız sürümü
npm stage publishile gönderiyor. - Bir paket bakımcısı bu sürümü inceliyor ve yayınını 2FA ile onaylıyor.
- Aynı token ile denenen doğrudan
npm publishçağrılarını npm reddediyor.
Reddetme koşulsuz çalışıyor. Token’ı otomasyon için 2FA’yı atlayacak (bypass-2FA) şekilde yapılandırmış olsanız bile stage-only izniyle doğrudan yayın yapılamıyor. Güvenlik kontrolü böylece token yapılandırmasında açılıp kapanan bir tercih olmaktan çıkıyor, izin seviyesinin kendisine gömülü bir kısıt olarak duruyor.
“Stage-only” izninin sınırları
Bu yeni izin türünün adı yanıltıcı olabilir. npm’in açıkça belirttiği üzere stage-only token’lar diğer paket yazma izinlerini korumayı sürdürüyor. Bunların arasında şunlar sayılıyor:
- dist-tag taşıma işlemleri (örneğin
latestetiketinin gösterdiği sürümü değiştirmek), - sürüm deprecate etme.
Bir dist-tag’in işaret ettiği sürümü değiştirebilmek, tek başına kullanıcıların hangi sürümü çektiğini etkileyebilecek güçlü bir yetki. O yüzden stage-only token’ları “düşük riskli” saymak yanlış olur; npm de bu token’ları diğer yazma yetkili token’larla aynı özenle korumayı tavsiye ediyor. Sır yönetimi, kapsam daraltma ve erişim kayıtlarını izleme alışkanlıklarınız bu token’lar için de geçerli.
Opt-in geliyor, mevcut token’lar etkilenmiyor
Duyuruya göre değişiklik isteğe bağlı (opt-in) sunuluyor, mevcut token’larınız ve bunların doğrudan yayın yetenekleri olduğu gibi kalıyor. Bugün çalışan bir yayın hattınız varsa, siz bilinçli olarak yeni izin tipine geçmedikçe bir şey bozulmuyor.
Buna karşılık npm, daha önce duyurduğu gibi bypass-2FA token’lar üzerinden doğrudan yayınlamayı kaldırmayı Ocak 2027 olarak hedefliyor. Tarih bir hedef olarak ifade ediliyor ama otomasyonunu token temelli yürüten ekipler için yön belli. npm’in önerdiği istikamet trusted publishing; oraya henüz geçemeyen ekipler için stage-only token’lar bir geçiş yolu olarak konumlandırılıyor.
Geçiş için izlenecek adımlar
Duyuruda tarif edilen başlangıç akışı üç adımdan oluşuyor:
- İş akışınızın ihtiyaç duyduğu paketler için Read and write (stage only) izinlerine sahip bir granular access token oluşturun.
- İş akışınızdaki mevcut yayın token’ını bu token ile değiştirin ve
npm publishyerinenpm stage publishkomutunu kullanın. - Sahneye alınan sürümleri bir bakımcının 2FA ile inceleyip onaylamasını sağlayın.
Bu üç adım, sürüm üretimini otomasyonda bırakırken yayın kararını insan onayına taşıyor. Akışın pratikte işe yaraması ise ekip içinde kimin onay verebileceğinin ve onay öncesi hangi kontrollerin yapılacağının netleştirilmesine bağlı.
Ön koşullar
Staged publishing mevcut npm paketleriyle çalışıyor. Kullanabilmek için duyuruda belirtilen gereksinimler şunlar:
- İlgili pakette publish erişiminiz olması,
- npm hesabınızda 2FA’nın etkin olması,
- npm CLI 11.15.0 veya daha yeni bir sürüm,
- Node.js 22.14.0 veya daha yeni bir sürüm.
CI çalıştırıcılarınızda sabitlenmiş eski bir Node.js ya da npm sürümü varsa geçişin ilk engeli büyük olasılıkla burada çıkar. Token izinlerine dokunmadan önce çalıştırıcı imajlarındaki sürümleri doğrulamak gereksiz hata ayıklama turlarını önler.
Kimler için anlamlı?
Stage-only token’lar, yayın otomasyonunu tamamen elden bırakamayan ama doğrudan yayın yetkisini bir robot kimliğinde tutmak istemeyen ekipler için tasarlanmış görünüyor. Yayın hattı paylaşımlı bir sırla çalışan, çok sayıda katkıcının dokunduğu depolarda yayının 2FA’lı bir insan onayına bağlanması saldırı yüzeyini daraltıyor.
npm’in uzun vadeli tercihi ise trusted publishing yönünde. Altyapınız buna uygunsa, geçiş yolu olarak tanımlanan stage-only token’lar yerine doğrudan trusted publishing’i değerlendirmek daha kalıcı bir çözüm olur. Sorularınızı ve geçişte karşılaştığınız engelleri npm topluluk tartışma kategorisinde paylaşmak da mümkün.
Kaynaklar ve İleri Okuma
- Stage-only npm tokens for safer automation — GitHub Changelog
- npm Docs: Staged publishing
- npm Docs: Trusted publishers
- npm community discussion — geçiş soruları ve engeller
- npm’de İmzayı Sıkılaştıran Yeni Dönem: Stage Queue ve Allow Flag’ler
- Disrupting supply chain attacks on npm and GitHub Actions
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Stage-only token olayı gerçekten mantıklı, CI pipeline’a full publish yetkisi vermek hep içimi rahatsız ediyordu. Supply chain saldırıları bu kadar artmışken staging + manuel onay akışı şart oldu resmen. Bu arada şu yazınız da işime yaradı geçen hafta: https://www.askinkilic.com.tr/dsc-v330-yeni-windows-kaynaklari-ve-what-if-destegi/ özellikle –what-if kısmı çok faydalıydı.
CI/CD pipeline’ında token sızma riski hep içimde bir kurtçuktu, stage-only token bu derdi baya çözüyor gibi. Yayın öncesi manuel onay adımı eklemek supply chain saldırılarına karşı da güzel bir önlem olmuş. Acaba mevcut granular token’ları stage-only’ye çevirmek mümkün mü, yoksa sıfırdan mı oluşturmak gerekiyor?
CI pipeline’da publish token’ının sızma riski hep içimi kemiriyordu, stage-only yaklaşımı tam bu derde deva gibi. Onay adımını insana bırakmak supply chain saldırılarına karşı da mantıklı bir önlem. Bu arada şu yazınız da işime yaradı: Ubuntu 26.04 Runner GA: ubuntu-latest Geçişine Hazırlık — https://www.askinkilic.com.tr/ub
Supply chain saldırıları bu kadar arttıktan sonra stage-only token cidden mantıklı bir adım, CI’da tam yetkili token tutmak hep içimi ürpertiyordu. Onay adımını da 2FA’ya bağlamak güzel olmuş. Bu arada şu yazınız da işime yaradı: Copilot CLI Skill, MCP ve Ajan Kullanımını Ölçün — https://www.askinkilic.com.tr/copilot-cli-skill-mcp-ve-ajan-kullanimini-olcun/
Stage-only token yaklaşımı, CI/CD otomasyonunda güvenliği artırırken son yayın kararını 2FA ile insanda bırakması açısından oldukça yerinde. Özellikle token’ın npm publish ile doğrudan yeni sürüm yayımlayamaması, ele geçirilme riskini ciddi ölçüde sınırlar.
Yorumunuz denetim bekliyor.Merhaba Felix, değerli yorumun için teşekkürler. Tam da vurguladığın gibi, stage-only token ile otomasyonun hızından vazgeçmeden son yayın yetkisini 2FA’lı bir insanda tutmak, tedarik zinciri saldırılarına karşı güçlü bir savunma hattı oluşturuyor. Token sızsa bile saldırganın doğrudan yeni sürüm yayımlayamaması, olası hasarı ciddi şekilde sınırlıyor. Ekip olarak buna ek olarak provenance imzalamayı da devreye almanızı öneririm.