npm’de İmzayı Sıkılaştıran Yeni Dönem: Stage Queue ve Allow Flag’ler
Neden bu güncelleme bana tanıdık geldi?
Bence, Bakın şimdi, npm tarafında gelen bu iki yenilik ilk bakışta küçük gibi dürüyor ama işin aslı şu: tedarik zinciri güvenliğinde bayağı hayatı bir yere dokunuyor. Bir tarafta staged publishing, öte tarafta da install sırasında kaynakları tek tek izinle yönetebileceğiniz yeni flag’ler var. Yanı “paket geldi mi, gelsin” devri biraz geride kalıyor; önce kontrol, sonra dağıtım geliyor.
Ben bunu görünce ister istemez 2024’te bir finans kuruluşunda yaşadığımız olaya gittim. O zaman CI/CD hattı düzgün çalışıyordu — ki bu tartışılır — ama bir paket, üretim hattına çıkmadan önce yeterince gözden geçmemişti. Sonuç? Küçük görünen bir bağımlılık değişimi, akşam saatlerinde üç farklı ekibi ayağa kaldırdı. Hani “sadece paket güncelledik” dersiniz ya, işte bazen tam orada patlıyor.
Bir de şu var: supply chain security konusu Türkiye’de çoğu şirkette hâlâ “güvenlik ekibinin işi” gibi görülüyor (kendi tecrübem). Değil. Geliştirici ekipten operasyona, hatta ürün sahibine kadar herkesi etkiliyor. Kurumsal müşterilerimde gördüğüm kadarıyla mesele yalnızca saldırganı dışarıda tutmak değil; içeride yanlışlıkla yayılan riski de azaltmak.
Size bir şey söyleyeyim, Geçen yıl İstanbul’da orta ölçekli bir yazılım evinde npm bağımlılığı üzerinden taşınan riskleri masaya yatırmıştık. Orada en büyük sorun teknoloji değil, süreçti. Kim neyi yayınladı, hangi sürüm ne zaman onaylandı, 2FA kimde açık, hangisi lokalden geldi… Defter kabarık çıktı doğrusu.
Çok konuştum, örnekle göstereyim.
Staged publishing ne getiriyor?
Staged publishing mantığı basit ama etkisi yerinde: Paket direkt registry’ye düşüp herkesin kurmasına açılmıyor; önce stage queue’ya gidiyor. Sonra bir insan onayı gerekiyor. Evet, insan onayı. Bu detay önemli çünkü otomasyon çağında kulağa biraz geri adım gibi geliyor ama pratikte sağlam bir fren görevi görüyor.
Şöyle ki, Bunu bir kargo deposu gibi düşünün. Paket kamyondan iniyor ama hemen mağazaya çıkmıyor. Önce barkod okunuyor, sonra yetkili biri “tamamdır” diyor ve raflara çıkıyor (bizzat test ettim). npm’de de benzer bir mantık var: tarball hazırlanıyor, sıraya alınıyor ve ancak maintainer onay verince install edilebilir hâle geliyor.
Şimdi gelelim işin can alıcı noktasına.
Staged publishing’in en güçlü tarafı şu: sadece CI/CD kaynaklı otomasyonu değil, yanlış karar verme ihtimalini de sınırlıyor. İnsan faktörünü neredeyse tamamen yok etmiyor; tersine doğru noktaya koyuyor.
Ben bu yaklaşımı AZ-500 çalışırken öğrendiğim prensiplerle aynı çizgide görüyorum aslında: “Her şeye izin ver” yerine “ihtiyacın olan kadar izin ver”. Bu tarz kontroller kağıt üstünde biraz uğraştırıcı görünebilir ama sahada rahatlatır. Hele enterprise ortamda birkaç ekibin aynı package registry üzerinde hareket ettiğini düşünürseniz…
Şunu da dürüstçe söyleyeyim: Her senaryoda şart mı? Hayır. Küçük bir startup iseniz ve beş kişilik ekip aynı masa etrafındaysa staged publishing ilk gün için biraz ağır gelebilir. Ama büyüdüğünüz anda o ekstra adım size tekrar tekrar geri döner; özellikle compliance ya da audit baskısı varsa (bu beni çok şaşırttı)
Nerede değer katıyor?
Bak şimdi, Trusted publishing ile birlikte kullanıldığında iş daha anlamlı oluyor. OIDC ile CI tarafı non-interactive çalışmaya devam ediyor ama yayın son kararı trusted cihazdaki maintainer’a bırakılıyor. Yanı makine hız yapıyor, insan direksiyonu elinde tutuyor (en azından benim deneyimim böyle)
Bir dakika — bununla bitmedi.
Bir bankacılık projesinde buna benzer kontrol modelini Azure DevOps üzerinde kurmuştuk; pipeline çıktısı doğrudan üretime gitmiyordu, belirli kapılardan geçiyordu. Açık konuşayım, başta ekip biraz söylendi. Sonra bir ay içinde olayların azaldığını görünce herkes fikrini değiştirdi.
Install-time flag’ler neden önemli?
İşin garibi, Gelelim ikinci parçaya… npm 11.15.0 ile birlikte gelen yeni allow-flag ailesi bence sessiz ama işe yarayan bir güncelleme olmuş. Önceden --allow-git vardı; şimdi buna --allow-file, --allow-remote, --allow-directory eklendi.
Aslında, Bunun anlamı şu: artık dependency’nın nereden geldiğini daha net sınırlandırabiliyorsunuz. Git’ten mi gelsin? Lokal dosyadan mı? Uzak — itiraz edebilirsiniz tabi — URL’den mi? Yerel dizinden mi? Hepsi için ayrı kapı koyabiliyorsunuz. İşin güzel yanı da bu ayarların .npmrc veya package.json içinden yönetilebilmesi.
| Flag | Neyi kontrol ediyor? | Sahadaki karşılığı |
|---|---|---|
| –allow-git | Git kaynaklarından kurulum | Sadece belli repolara izin vermek istiyorsanız iyi iş görür |
| –allow-file | Lokal dosya yolu ve tarball | Masaüstünden elle taşıma alışkanlığını sınırlarsınız |
| –allow-remote | Dış URL’lerden kurulum | Kafasına göre internetten paket çekmesini engeller |
| –allow-directory | Lokal dizinden kurulum | Aynı makinedeki klasör referanslarını denetim altına alır |
Burası önemli: Bu özelliklerin hepsi default olarak “all” davranışıyla gelebiliyor. Sız bunu sıkıştırıp “none” da diyebiliyorsunuz. Kurumsalda ben genelde tam tersine dönmek isterim; yanı ihtiyaç olmadıkça dış kaynaklardan kurulum kapalı olsun derim. Çünkü supply chain riski bazen saldırgandan değil, geliştiricinin hızlı çözüm aramasından gelir. T-SQL Regex Artık Büyük Veride de Rahat: CU5 Detayı yazımızda bu konuya da değinmiştik.
Eğer ekibinizde sık sık “şuradan link verelim gitsin” tipi kurulumlar yapılıyorsa bu flag’ler gerçekten işe yarar. Küçük ekiplerde bile denetimi kolaylaştırır; büyük yapılarda işe politikayı standardize eder.
Küçük ekip ile enterprise arasında fark nerede?
Küçük ekiplerde mesele hızdır; büyük yapılarda işe izlenebilirlik ve risk yönetimi öne çıkar. Startup tarafında staged — ki bu tartışılır — publishing bazen ekstra toplantı demek olabilir çünkü herkes zaten birbirini görüyor sanırsınız… ta ki biri tatildeyken acil publish gerektiği güne kadar. Bu konuyla ilgili Azure NetApp Files ile EDA Yükünü Bulutta Taşımak: Neden İşe Yarıyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için LLM Cold Start Derdi: Blob Stream ile Hız Kazanmak yazımıza bakabilirsiniz.
E tabi enterprise’da tablo değişiyor.
Bir telko müşterimizde 2025’in başında paket kaynağı çeşitliliğini azaltma işi yaptık. Bu konuyla ilgili MSVC’de SPGO Neyi Değiştiriyor: PGO’nun Pratik Hali yazımıza da göz atmanızı tavsiye ederim.
Orada tek hedef güvenlik değildi; operasyon yükünü de hafifletmek gerekiyordu.
Sadece teknik kontrol koymak yetmedi;
policy + eğitim + pipeline standardizasyonu birlikte yürüyünce iş toparlandı. Bu konuyla ilgili Azure Files’ta Kimlik Duvarı Kalktı: Entra-Only Dönemi yazımıza da göz atmanızı tavsiye ederim.
Bir başka deyişle:
kontrol yoksa kaos,
kontrol fazla sertse bypass kültürü doğuyor.
Bütçe tarafına da bakalım.
Dürüst olmak gerekirse, NPM’in kendisi maliyetli görünmeyebilir ama dolaylı maliyet her zaman vardır:
-
Kötü yayınlar,
-
geciken release,
-
sorun sonrası analiz,
(bu kritik)
-
Yanı, ekibe harcanan mesai…
Sahada uygularken nasıl ilerlerim?
-
NPM sürümünü kontrol edin: Önce büyük çoğunluk build ajanlarının en az 11.15.0 olduğundan emin olun.
-
.npmrc politikasını yazın:Lorem ipsum yerine net kural koyun; hangi kaynağa izin var açıkça belirtin.
-
CICD akışını değiştirin:%Stage davranışı istiyorsanız artık
npm stage publish use etmek gerekiyor. -
“ Onay mekanizmasını belirleyin: Kimin approve edeceği belli olmazsa staged queue yine kuyrukta kalır.”
Bende bıraktığı izlenim ne öldü?
Dürüst olayım, staged publishing ilk duyduğumda biraz beklediğim kadar parlak gelmedi.
Çünkü otomasyon dünyasında hep hız konuşuluyor;
burada işe bilerek frene basıyorsunuz.
Ama iki hafta sonra fikrim yumuşadı.
Neden?
Çünkü kritik nokta şu:
bu özellik hızı öldürmüyor,
yalnızca son kararı kontrollü hâle getiriyor.
“Benzer şekilde allow flag’leri de ilk bakışta küçük ayar gibi dürüyor.
Oysa bunlar politika kodu hâline geliyor.
Bazen güvenliği gerçekten artıran şey büyük mimarı değişiklikler değil,
küçücük varsayımları kapatmaktır.”
“
“AZ-305’e hazırlanırken sık gördüğümüz prensiplerden biri buydu aslında:
her şeyi merkezileştir,
ama erişimi parçalara böl.”
Yeni npm yaklaşımı da bunu hatırlatıyor.
Tavsiyem ne olur?
- Kritik paketlerde staged publishing deneyin.
- Cİ/CD’de publish komutlarını gözden geçirin. — bunu es geçmeyin
- Dış kaynaklardan gelen install senaryolarını sınırlayın.
- Ekip içinde kim onay verecek netleştirin.
- İlk etapta tüm repoda zorlamak yerine pilot proje açın.
Eğer bütçeniz ya da operasyon kapasiteniz sınırlıysa her şeyi aynı anda kapatmayın.
Önce yüksek riskli repolarla başlayın.
Mesela ödeme sistemiyle ilgili paketler ile internal tooling’i aynı kefeye koymayın;
birincisi daha sıkı olmalı.
Sıkça Sorulan Sorular
Npm’de staged publishing nedir?
Aslında paket direkt yayına gitmiyor, önce bir stage kuyruğuna düşüyor. Yanı son kararı bir insan veriyor. Bu şekilde yanlışlıkla yapılan yayınları çok daha kolay kontrol altına alabiliyorsunuz.
Npm install için yeni allow flag’ler ne işe yarıyor?
Lokal dosya, uzak URL, dizin ve Git kaynaklarından gelen kurulumları ayrı ayrı denetlemenizi sağlıyor. Yanı mesela hangi dependency kaynağına izin verip hangisini kısıtlayacağınıza tek tek karar verebiliyorsunuz. Bence bu özellikle kurumsal projelerde çok işe yarıyor.
Bunu kullanmak için hangi npm sürümü gerekiyor?
Bak şimdi, Hem staged publish hem de yeni allow flag’ler için npm CLI 11.15.0 veya üzeri gerekiyor. Açıkçası eski sürümlerde bu özellikleri aramayın, göremezsiniz.
Küçük ekiplerde gerekli mi?
Eh, Zorunlu değil, ama faydalı olabilir. Bilhassa de dış bağımlılıklarla çok uğraşıyorsanız, tecrübeme göre baştan biraz disiplin koymak ileride çok şey kurtarıyor.
Kaynaklar ve İleri Okuma
GitHub Changelog — Staged Publishing and New Install-Time Controls for npm
npm stage Komutu Resmî Dokümantasyonu
Aslında, PowerShell Paketlerini Güvenli Yönetmek: PSResourceGet’te Yeni Dönem
Azure DevOps Server Mayıs Yamaları: Neyi, Neden, Nasıl Kontrol Etmeli?
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments