Axios npm Saldırısı: Azure Pipelines’ta Ne Yapmalı?
31 Mart 2026 sabahı kahvemi yudumlarken Slack’te bir mesaj düştü: “Axios’un npm paketine zararlı kod enjekte edilmiş.” İlk tepkim mi? “Yine mi supply chain saldırısı…” Evet, yine. Hedef de öyle sıradan biri değil; JavaScript tarafında eli ayağı her yere değen, neredeyse her Node.js projesinde karşınıza çıkan o Axios, yanı haftalık 50 milyonun üstünde indirilen kütüphane.
📋 İçindekiler
-
# YANLIŞ — her build'de farklı versiyon gelebilir npm install # DOĞRU — lock dosyasındaki versiyonlara sadık kalır npm ci # DAHA DA İYİ — integrity check ile birlikte npm ci --ignore-scripts # postinstall script'lerini devre dışı bırakır npm audit # bilinen güvenlik açıklarını tararBir şey dikkatimi çekti: Ha bu arada,
--ignore-scriptsflag’i baya işe yarıyor. Çünkü bu saldırıda zararlı kod tam dapostinstallüzerinden dönüyordu; yanı paket inerken değil, sonrasında patlıyordu. Bu seçeneği açarsanız paket yine gelir ama o istenmeyen kod çalışmaz. Tabi burada küçük bir. Var: bazı projeler native modül derleme gibi sebeplerle postinstall’a gerçekten ihtiyaç duyuyor, o yüzden her yerde tak diye uygulanmıyor. Yine de denemeye değer.Şimdi gelelim işin can alıcı noktasına. Daha fazla bilgi için
Bak şimdi, enterprise tarafta iş biraz değişiyor. Banka, telekom ya da büyük holding gibi yapılarda private npm registry kullanmanız gerekiyor; Azure Artifacts, Artifactory veya Nexus olur, fark etmez,. Upstream source’ları kontrol etmeden bu iş yürümüyor. Paket onay süreci de lazım. Evet, maliyet çıkıyor ve uğraştırıyor. Ama bir supply chain saldırısından sonra incident response tarafında harcayacağınız zaman ve para bambaşka seviyeye gidiyor; geçen sene bir finans kuruluşunda sadece “hangi secret’lar sızdı” sorusunun cevabını bulmak üç hafta sürdü.
💡 Bilgi: Azure Artifacts’i private npm registry olarak kullanabilirsiniz. Upstream source olarak npmjs.org’u ekleyip, belirli paketleri “onaylanmış” olarak işaretleyebilirsiniz. Bu, supply chain saldırılarına karşı ek bir savunma katmanı oluşturur. Üstelik Azure DevOps kullanıyorsanız zaten lisansınıza dahil — ek maliyet yok.Uzun Vadeli Savunma Stratejisi
Bu olay beni yine aynı yere getirdi: reactive kalınca iş büyüyor, proactive olunca nefes alıyorsunuz. Saldırı olduktan sonra “acaba biz de etkilendik mi?” diye ortalıkta koşturmak yerine, daha baştan hazırlıklı olmak lazım (yanlış duymadınız). Kulağa biraz klişe geliyor, evet, ama sahada bunu gerçekten yapan ekip sayısı düşündüğümden az.
İşte tam da bu noktada devreye giriyor.
Şimdi somut tarafa geçelim. Azure DevOps Server Nisan Yaması: Ne Geldi, Ne Yapmalı? yazımda da değindiğim gibi, Azure DevOps tarafındaki güvenlik güncellemelerini kaçırmamak gerekiyor. Daha açık söyleyeyim, ama dur bir saniye — bu tek başına yetmiyor; kendi pipeline’larınızın güvenlik düzeni de sizin elinizde, yanı işi sadece Microsoft’a bırakınca tablo pek öyle olmuyor.
Zero-Trust Pipeline Yaklaşımı
Dürüst olmak gerekirse, Pipeline’lara zero-trust gözüyle bakın. Her job yalnızca gerçekten ihtiyaç duyduğu minimum credential’a erişsin, başka bir şey değil. Bir npm build job’ünün Azure subscription Contributor rolüne ihtiyacı yok mesela; hatta çoğu zaman fazlası direkt risk oluyor (yanlış duymadınız). Service connection’ları scope’layın, secret’ları job seviyesinde ayırın; AZ-500’e hazırlanırken öğrendiğim en net derslerden biri buydu ve açık konuşayım, pipeline dünyasında da birebir çalışıyor.
Ve işler burada ilginçleşiyor.
Bilmem anlatabiliyor muyum, Bir de şu kısmı atlamayın:
npm installsırasında network çıkışlarını izlemek hiç fena fikir değil. Zararlı paketler çoğu zaman bilinen npm registry dışına uzanmaya çalışıyor, bazen garip DNS sorguları atıyorlar, bazen de alakasız HTTP istekleri yapıyorlar (şey, ilk bakışta masum görünüyorlar ama değil). Build agent’larda egress firewall kuralları varsa ki olmalı, beklenmeyen trafiği loglamak baya iş görüyor.Az önce “her şeyi izleyin” dedim ama aslında Türkiye’deki birçok şirkette build agent trafiği hâlâ görünmez durumda. Hani insan şaşırıyor biraz. Bunu düzeltmek teknik olarak zor değil; asıl mesele birinin bunu öncelik yapması (inanın bana). Peki neden yapılmıyor? İşte orası ayrı konu.
Sıkça Sorulan Sorular
Hangi Axios versiyonları zararlıydı?
Aslında sadece 1.14.1 ve 0.30.4 versiyonları etkilendi. Diğerleri güvenli.
package-lock.jsondosyanıza bir bakın, bu versiyonlardan biri var mı diye (kendi tecrübem).1.14.0veya0.30.3kullanıyorsanız sorun yok, rahat olun.Microsoft-hosted agent kullanıyorsam hiç sorun yok mu?
Platform tarafı için endişelenmenize gerek yok, hani her job zaten temiz bir VM’de çalışıp sonra siliniyor (ciddiyim). Ama şöyle bir şey var — pipeline’ınızda
npm installçalışıyorsa ve o zararlı versiyon çekildiyse, o job sırasındaki secret’larınız sızmış olabilir. Yanı agent güvenli, bence asıl kontrol edilmesi gereken kendi kodunuz ve secret’larınız.Self-hosted agent’ımı sadece npm cache temizleyerek kurtarabilir mıyım?
Açıkçası hayır, önerilmez. Saldırganın payload’u dosya sisteminin tam olarak neresine ne yazdığını bilemezsiniz. Tecrübeme göre en güvenli yol agent’ı tamamen reimage etmek ya da sıfırdan kurmak. Cache temizliği yetmez, mesela payload çok farklı dizinlere de yazılmış olabilir.
Pipeline’larımda Axios kullanıp kullanmadığımı nasıl anlarım?
Doğrudan kullanmasanız bile dikkat edin — yanı transitif bağımlılık olarak projelerinizde sinsi sinsi oturuyor olabilir.
npm ls axiosçalıştırın, bağımlılık ağacınızda var — ki bu tartışılır — mı göreceksiniz (ki bu çoğu kişinin gözünden kaçıyor). Ayrıcanpm auditde bu saldırıyı raporluyor, güzel bir kontrol noktası.Bu tür saldırılardan kalıcı olarak korunmak mümkün mü?
Yanı, Yüzde yüz koruma diye bir şey yok, açık konuşalım (evet, doğru duydunuz). Ama bence şunları yaparsanız riski ciddi ciddi azaltırsınız: private npm registry kullanmak, lock dosyalarını commit etmek,
npm cikullanmak, postinstall script’lerini devre dışı bırakmak ve SCA araçlarıyla sürekli tarama yapmak. Katmanlı güvenlik yaklaşımı şart, başka yolu yok.Kaynaklar ve İleri Okuma
Neyse, bilmem anlatabiliyor muyum, Mitigating the Axios npm Supply Chain Compromise – Microsoft Security Blog
Hani, Azure Pipelines Agents – Microsoft Learn
Axios npm Supply Chain Compromise – Guidance for Azure Pipelines Customers (Orijinal Makale)
Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
.NET Day Agentic Modernization: Eski Uygulamalara Yeni Hayat16 Haz 2026ASP.NET Core "ApiVersion Could Not Be Resolved" Hatası28 Nis 2026Kubernetes v1.36: Workload-Aware Scheduling Yeni Boyutta14 May 2026Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek26 Mar 2026
İlginizi Çekebilir
Hakan G.
Tam da bu sabah pipeline’larımı kontrol ettim, çok yerinde bir uyarı oldu. Peki zararlı kod tam olarak ne yapıyor, credential çalıyor mu yoksa başka bir şey mi? Bunu da bir yazıda ele alırsanız iyi olur.
Ebru G.
Tam da bu sabah bir pipeline logunda garip bir şey gördüm, şimdi aklıma takıldı. Axios kullanan projelerde versiyon pinleme yapmak ne kadar kritikmiş, bunu hep erteleyip duruyoruz. Acaba etkilenen agent’ları temizlemek için self-hosted ile Microsoft-hosted arasında ciddi bir fark var mı?
Yorumlar kapalı.
2 comments