npm’den Yüksek Etkili Hesaplara 72 Saatlik Salt-Okunur Kalkan
Açık konuşayım: npm tarafında son iki yılda yaşanan supply chain saldırılarını izleyenler için bu duyuru pek sürpriz değil. Sürpriz olan, GitHub’ın bu adımı biraz geç atmasıydı. Neyse, sonunda geldi.
npm artık yüksek işe yarayan hesaplar için — yanı registry’deki en çok indirilen paketleri yöneten maintainer’lar için — hassas bir hesap değişikliği algıladığında otomatik bir koruma katmanı devreye sokuyor. Mantık basit gibi dürüyor. Işin içinde baya can alıcı bir nokta var: e-posta değişikliği ya da 2FA recovery code kullanımı tespit edilince hesap 72 saatliğine salt-okunur moda alınıyor, eski e-posta adresine de uyarı gidiyor.
Kendi deneyimimden konuşuyorum, Kulağa küçük bir değişiklik gibi geliyor değil mi? Aslında değil. Bunun arkasında ciddi bir saldırı yolu kapanıyor. Aşağıda neden bu kadar önemli olduğunu, Türkiye’deki kurumsal ekipler için ne ifade ettiğini. Sizin bugünden itibaren ne yapmanız gerektiğini anlatacağım.
Önce şu “high-impact account” ne demek, ona bakalım
Şunu fark ettim: npm tarafının resmî tanımına göre, “yüksek etkili hesap” registry’nın en yaygın kullanılan paketlerinden sorumlu olan hesap demek. Yanı milyonlarca haftalık indirme alan paketlerin sahipleri. chalk, debug, lodash, express çevreindeki maintainer’lar… Bunlar.
Yanı, Sayı olarak ne kadar var? GitHub net rakam vermiyor ama büyük ihtimalle birkaç bin maintainer’dan bahsediyoruz. Şimdilik böyle. Sonra kapsam genişler mi? Bence genişleyebilir, çünkü “yüksek etkili” tanımı zaten biraz esnek bir şey.
Hani, Burada kilit bir noktayı atlamayalım: sız “high-impact” değilseniz bu özellik şu anda sizin hesabınızı etkilemiyor. Ama bu, paketlerinizi indirdiğiniz upstream maintainer’lar etkileniyor demek. Yanı dolaylı olarak hepimizi ilgilendiriyor.
Saldırı senaryosu neden bu kadar can sıkıyordu?
Son dönemde npm üstünde patlayan tedarik zinciri saldırılarının klasik akışı kabaca şöyleydi:
- Saldırgan, maintainer’ın hesabını ele geçiriyor (phishing, credential stuffing, session token çalma — neyse işte).
- Hesabın e-posta adresini hızlıca değiştiriyor. Bu kilit adım — çünkü bundan sonra maintainer şifre sıfırlama bile yapamıyor.
- Yeni bir publish token üretiyor. — bunu es geçmeyin
- Popüler paketin yeni bir versiyonunu malicious payload ile yayınlıyor.
- Saatler içinde milyonlarca
npm installkomutu bu zehirli versiyonu çekiyor.
Adımlar arasındaki süre bazen 30 dakikayı bile bulmuyordu. Maintainer Slack’ten haberi olana kadar paket çoktan yayılmış oluyordu. Hatırlarsanız geçen sene benzer birkaç olayda topluluk “neden e-posta değiştirildikten hemen sonra publish edebiliyor?” diye sormuştu. İşte o sorunun cevabı geldi: 72 saatlik dondurma.
Bu kabiliyetin kötü adamı büyük ölçüde durdurmaktan çok, onun işini geciktirmek için tasarlanmış. 72 saat çoğu saldırı için yeterince uzun bir pencere kapatıyor. Çünkü o sürede gerçek hesap sahibi genelde durumun farkına varıyor.
72 saatte tam olarak ne yapabilirsiniz, ne yapamazsınız?
Bu kısım önemli çünkü “salt-okunur” deyince insanlar hemen geriliyor. Aslında günlük iş akışınız neredeyse hiç bozulmuyor. Aşağıdaki tabloya bakın:
Hmm, bunu nasıl anlatsamdı…
| İşlem | 72 saat içinde |
|---|---|
| Paket indirme / install | ✅ Çalışıyor |
| Organizasyon ve takım görüntüleme | ✅ Çalışıyor |
| Hesap ve paket ayarlarını okuma | ✅ Çalışıyor |
Paket yayınlama (npm publish) |
❌ Durduruldu |
| Token oluşturma / silme | ❌ Durduruldu |
| Paket görünürlüğünü değiştirme | ❌ Durduruldu |
| Org/team üyelik değişiklikleri | ❌ Durduruldu |
Bir şey dikkatimi çekti: Bir de şu iyi: 72 saat dolduğunda hesap otomatik olarak normale dönüyor. “Tekrar doğrula”, “kimlik gönder”, “ID kart fotoğrafla” gibi ekstra sürtüşme yok. Bu kararı doğru buluyorum çünkü güvenlik özelliklerini insanlar genelde sürtüşme yüzünden kapatmaya çalışıyor. Burada öyle bir motivasyon kalmıyor.
Peki pratikte sizi nasıl etkiler?
Eğer maintainer iseniz
Bakın, Diyelim ki gerçekten e-posta adresinizi değiştirmek istediniz — şirket değiştirdiniz, eski Gmail hesabınız bozuldu, her neyse. Bu durumda da 72 saat publish yapamayacaksınız. O yüzden plan yapmak şart. Hotfix gibi acil bir senaryo varsa, mümkünse e-posta değişikliğini release döngüsünün başında yapın.
Bir öneri daha: e-posta değiştirmeden önce takım arkadaşlarınızı haberdar edin. Mesela CI/CD pipeline’larda otomatik publish kuruyorsanız — bu durum token üretemeyeceğiniz için sizi yarı yolda bırakabilir. Acı tecrübeyle öğrenmektense önceden hazırlık yapmak daha mantıklı.
Eğer kurumsal ekibinizde npm bağımlılığı varsa
Sizin için doğrudan bir aksiyon yok ama dolaylı kazanım var: artık upstream bağımlılıklarınızdan biri gece yarısı 03:00’te zehirli versiyon yayınlama riskini biraz daha zor taşıyor. “Biraz daha” diyorum — sıfır değil tabiî. Hâlâ npm audit, Dependabot, lock file pinleme gibi savunma katmanlarına ihtiyacınız var.
Türkiye perspektifinden bakınca işler nasıl görünüyor?
Kurumsal müşterilerimde gördüğüm kadarıyla, Türkiye’deki ekiplerin npm supply chain riskine yaklaşımı ikiye ayrılıyor. Bir tarafta finans. Telekom gibi regüle sektörler var — bunlar zaten kendi private registry’lerini (Nexus, Artifactory, Azure Artifacts) çalıştırıyor ve dışarıdan gelen paketleri mirror’lıyor. Onlar için npm’in bu yeni özelliği “güzel ama bizi pek etkilemez” tarafında kalıyor (bizzat test ettim)
Diğer tarafta — açıkçası çoğunluk burada — startup’lar, agency’ler, kurum içi geliştirme ekipleri var. Bunlar doğrudan public npm registry’den çekiyor. Hatta CI runner’larında bile public registry kullanılıyor bazen; insan şaşırıyor açıkçası ama oluyor işte. Bu ekipler için 72 saatlik koruma değerli, çünkü zehirlenmiş bir paketin yayılma süresini daraltıyor.
Evet, doğru duydunuz.
Bence Türk ekiplerinin önümüzdeki 6 ayda yapması gereken üç şey var:
- Private mirror kurun: Azure Artifacts veya Nexus üzerinden upstream proxy yapın. Maliyeti TL bazında düşününce, küçük ekipler için Azure Artifacts’in ücretsiz tier’ı çoğu zaman yetiyor.
- Lock file disiplinini sıkılaştırın:
package-lock.json‘u commit’leyin, build’i de mümkünsenpm ciile alın. Bunu hâlâ yapmayan ekipler var; garip ama gerçek. (bence en önemlisi) - Provenance kontrolü ekleyin: npm artık paket provenance’ı destekliyor. CI pipeline’ınızda hayatı paketler için bunu doğrulayın.
Bunu daha önce
Ekşi tarafları da var mı? Var tabiî.
Bi saniye — Neyse şimdi biraz fren yapalım ve eleştirel bakalım. Bu özelliğin hâlâ eksik yanları var:
Küçük bir detay: Sadece e-posta. 2FA recovery code mu? Bence — en azından ben öyle düşünüyorum — şifre değişikliği, yeni cihazdan login ya da şüpheli IP’den oturum açma gibi durumlarda da benzer bir koruma olmalıydı (bu konuda ikircikliyim). Şu an saldırgan e-postayı değiştirmeden token üretmeyi başarırsa bu koruma devreye girmiyor.
Bakın, “High-impact” tanımı şeffaf değil.. Hangi kriterle belirleniyor? Haftalık indirme sayısı mı, downstream dependency sayısı mı, ikisi birlikte mi? GitHub bu konuda biraz daha açık olmalı bence; yoksa “ben de high-impact mıyım?” diye Support’a ticket açan çok kişi çıkar.
Eğer eski e-posta zaten ele geçirilmişse?. Saldırgan o mailbox’a da giriyorsa uyarı havada kalıyor doğal olarak (şaşırtıcı ama gerçek). SMS ya da authenticator app’e push uyarısı gibi ek seçenekler fena olmazdı.
Peki org admin’leri?. Bir organizasyonun owner’ı kendisi maintainer olmasa bile organizasyon altındaki paketleri etkileyebiliyor. Onlar için de benzer bir koruma katmanı düşünülmeli diye bakıyorum ben buna.
Lafı uzatmadan pratik aksiyon listesi verelim:
- Npm hesabınızda kayıtlı e-posta adresinin gerçekten erişiminizde olduğunu doğrulayın.. Eski şirket maili mi, kapalı Gmail mi — bir kez giriş yapıp test edin işte.
- MFA recovery code’ları güvenli yerde saklayın..1Password, Bitwarden, Azure Key Vault — her neyse artık; post-it’e yazıp monitöre yapıştırmak çözüm değil. (bence en önemlisi)
- CICD token’larınızı kısa ömürlü yapın.. Hâlâ “never expires” token kullanıyorsanız durup düşünün derim ben.
- Anahtar türlerini ayırın:. Publish için kullandığınız token sadece publish yapsın; başka işe burnunu sokmasın.
- Paket provenance attestation’ını açın:. CI’da
npm publish --provenance‘u kullanın.
Küçük bir kod örneği vereyim; GitHub Actions ile provenance açarak publish etmek şöyle görünüyor:
name: Publish to npm
on:
release:
types: [created]
permissions:
contents: read
id-token: write # Provenance için sart
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
registry-url: 'https://registry.npmjs.org'
- run: npm ci
- run: npm publish --provenance --access public
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
`–provenance` flag’i paketin gerçekten sizin CI pipeline’ınızdan çıktığını kriptografik olarak kanıtlıyor diyebiliriz kısaca.? Kötü adam sizin token’ınızı çalıp kendi makinesinden publish ederse,
provenance imzası eşleşmediği için downstream tüketiciler bunu görebilir.
Çok konuştum, örnekle göstereyim.
Daha geniş manzara nerede dürüyor?
Bunu tek başına duran bir özellik gibi okumamak lazım; aslında daha geniş trendin küçük bir parçası.? Son iki yıldır supply chain güvenliği etrafında dönenlere topluca bakarsak:
GitHub Advanced Security paket koruması katmanlarını artırdı
Kubernetes tarafındaki benzer trendleri
Kubernetes CVE Kayıt Düzeltmesi: Tarayıcılarınız Şaşıracak
yazısında ele almıştım.? Orada da gördüğümüz şey şu öldü:? ekosistemler artık “biz güveniyoruz” yerine “kanıtla” demeye başladı.? Bence bu sağlıklı bir dönüşüm.
Bir de FinOps tarafından bakalım:? Bu tip kontrolleri devreye almak operasyonel maliyet ekliyoryor mu? Açıkçası evet,
kısa vadede ekliyoryor.? CI süreleri uzuyor,
ek imzalama altyapısı kuruluyor,
takım eğitiminde zaman harcanıyor.? Ama tek bir supply chain saldırısının kurumsal maliyetiyle kıyaslayınca — incident response,
müşteri bildirimi,
regülatör sorgusu,
marka itibarı kaybı… O zaman bu ek operasyonel yük baya ucuz kalıyor.
Sıkça Sorulan Sorular
Hesabım “high-impact” kapsamında mı, nasıl anlayabilirim?
İtiraf edeyim, Aslında npm şu an için hangi hesapların bu kapsama girdiğini kamuoyuyla paylaşmıyor. Yönettiğiniz paketlerden biri bir düşüneyim… haftalık milyonlarca indirme alıyorsa ya da popüler paketlerin dependency’si konumundaysa, büyük ihtimalle kapsamdasınız. Bence en garantisi npm Support’a ticket açıp direkt sormak — tahmin yürütmekten iyidir.
72 saatlik salt-okunur sürede acil bir güvenlik açığı için patch yayınlamam gerekirse ne yapacağım?
Bu durumda npm Support’la iletişime geçmeniz gerekiyor. Otomatik bir bypass mekanizması yok maalesef, ama destek ekibi manuel inceleme yapıp süreyi kısaltabiliyor. Açıkçası tecrübeme göre en akıllıca yol, e-posta değişikliği gibi hassas işlemleri kritik release dönemlerinden uzakta planlamak — sonradan uğraşmak istemezsiniz.
Salt-okunur dönemde CI/CD pipeline’ım çalışmaya devam eder mi?
Mevcut token’larınız geçerliyse install ve build adımları sorunsuz çalışıyor. Yanı hani read-only ve consume eden işler etkilenmiyor. Ama yeni token üretemiyorsunuz ve npm publish komutu reddediliyor — publish eden her şey o süreçte dürüyor.
Kısa bir not düşeyim buraya.
Bu özellik organizasyon hesaplarını da kapsıyor mu?
Daha açık söyleyeyim, küçük bir detay: Şu anki duyuru bireysel maintainer hesaplarına odaklanıyor. Organizasyon seviyesinde benzer korumalar zamanla gelecektir diye düşünüyorum, ama henüz resmî bir açıklama yok. Şunu da belirtmek lazım: organizasyon owner’larının kişisel hesapları. Bu kapsama girebilir, mesela tam da sız farkında olmadan.
Eski e-postama uyarı geldi ama ben hiçbir değişiklik yapmadım, ne yapayım?
Bu ciddi bir sinyal — hesabınız ele geçirilmiş olabilir. Hemen npm Support’a yazın. Aynı zamanda mevcut token’larınızı revoke edin, kullandığınız tüm CI/CD pipeline’larındaki secret’ları rotate edin ve bağımlı oldukları downstream ekipleri durumdan haberdar edin. Neden önemli bu? Açıkçası bu adımları sırayla, hızlıca halletmek önemli.
Kaynaklar ve İleri Okuma
GitHub Changelog: npm adds preventive account protection for high-impact accounts
npm Docs: About two-factor authentication
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.
2 comments