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.
Araya gireyim: Kısa bir süre için npm registry’ye yüklenen 1.14.1 ve 0.30.4 sürümleri, gizli bir zararlı bağımlılık taşıyordu. İlginç, değil mi? Kurulum anında çalışıyor, sonra saldırganların yönettiği C2 (command-and-control) altyapısına bağlanıyor ve ikinci aşama bir payload indiriyordu; işin can sıkıcı tarafı da burada, çünkü CI/CD pipeline’larınız otomatik olarak npm install çalıştırıyorsa — ki çoğu yerde durum bu — build agent’larınız fark etmeden bu kodu çekmiş olabilir.
Çok konuştum, örnekle göstereyim.
Bakın, bunu sadece “şu öldü, bunu yapın” diye geçmeyeceğim. Türkiye’deki kurumsal müşterilerimde bu tip olaylar ortaya çıktığında nelerin konuşulduğunu, hangi adımların çoğu zaman atlandığını ve pratikte nelere dikkat etmek gerektiğini biraz daha sahici bir dille anlatacağım.
Saldırının Anatomisi: Tam Olarak Ne Öldü?
Araya gireyim: Supply chain saldırıları artık yeni değil, tamam. Ama her seferinde ufak bir numara değişiyor, insanı da oradan yakalıyor; bu olayda saldırganlar Axios’un npm hesabına sızıp (ya da bir maintainer token’ını aradan çekip — açıkçası kesin yöntem hâlâ netleşmedi) iki sürüm yayınladı: 1.14.1. 0.30.4. Dışarıdan bakınca gayet sıradan minor/patch güncellemesi gibi dürüyor, işte asıl bela da burada. Sız hiç denediniz mi? Kimse ^1.14.0 kullanan birinin 1.14.1’i otomatik çekince şüphelenmesini beklemezdi.
Kendi deneyimimden konuşuyorum, Zararlı paket kurulunca postinstall script’i devreye giriyordu. Kısaca, paket sadece kötü kod bırakmıyor, aynı zamanda arkada bir C2 sunucusuna bağlanıp ikinci aşama payload’u indiriyordu; yanı sessizce oturmuyor, dışarıyla konuşuyordu da. Build agent’ınızın environment variable’ları, secret’ları, token’ları… hepsi risk altına girebiliyor, hani bir anda ortalık karışabiliyor (ciddiyim)
Neden Axios Bu Kadar Kritik?
Axios’u anlatmaya pek gerek yok aslında, ama yine de söyleyeyim: Türkiye’deki kurumsal projelerin baya büyük kısmında — finans olsun, telekom olsun, e-ticaret olsun fark etmiyor — frontend ya da backend tarafında bir yerde Axios çıkıyor karşınıza (evet, doğru duydunuz). Bazen sız doğrudan kullanmıyorsunuz bile; bağımlılık ağacının içinde sessiz sedasız dürüyor (ve sonra günün birinde başınıza iş açıyor). Geçen ay bir sigorta şirketinin projesini audit ederken package-lock.json‘da 847 paket saydım, bunun en az 12’si dolaylı olarak Axios’a bağlıydı; ekip de bunu bilmiyordu, açık konuşayım biraz şaşırdılar.
Supply chain saldırılarının asıl sıkıntısı şu: Sız doğrudan hedef olmayabilirsiniz ama yine de darbe yiyebilirsiniz. Sız hiç Axios kullanmıyor olabilirsiniz ama kullandığınız başka bir kütüphane kullanıyor olabilir.
Azure Pipelines Etkilendi mi? — Kısa Cevap: Hayır, Ama…
Size bir şey söyleyeyim, Microsoft’un resmî açıklaması gayet açık: Azure Pipelines platformunun kendisi ele geçirilmedi. Eğer Microsoft-hosted agent’lar kullanıyorsanız ve sadece Microsoft’un built-in task’larını çalıştırıyorsanız, platform tarafında panik yapacak bir durum yok. Her pipeline job’u yeni bir VM’de koşuyor, iş bitince de o VM siliniyor. Bir job’dan ötekine bulaşma gibi bir şey beklemiyorsunuz.
Ama — işte can alıcı yer burası — CI/CD pipeline’larınız sizin yazdığınız workflow’ları çalıştırıyor. npm install, yarn install, custom script’ler… Bunların hepsi sizin kontrolünüzde ve açık konuşayım, bazen insan orayı fazla rahat bırakıyor (en azından benim deneyimim böyle). Eğer 31 Mart civarında pipeline’ınız çalıştıysa ve o zararlı versiyonlardan birini çektiyse, o job sırasında erişilebilir olan her secret sızmış olabilir; biraz sert geliyor ama tablo bu.
Bunu Türkiye tarafında düşününce iş daha da netleşiyor, hani kurumsal ortamlarda sık gördüğüm bir alışkanlık var: pipeline’da kullanılan service principal scope’u gereğinden geniş tutuluyor. Yanı bir Node.js build job’unda kullanılan credential, aslında neredeyse tüm subscription’a Contributor erişimi olan bir service principal’a bağlı oluyor (evet, kulağa absürt geliyor ama oluyor). Bu durumda saldırgan sadece npm paketinizdeki bir secret’ı değil, Azure kaynaklarınızın tamamına yakınını zorlayabilir. Düşünsenize…
Kimler Risk Altında? Detaylı Kontrol Listesi
Şimdi işin pratik tarafına gelelim. Aşağıdaki tabloya bakıp, kendi ortamınızı kabaca tartabilirsiniz; hani bazen bir bakışta neyin ne olduğu çıkar ya, burada da öyle bir durum var:
| Senaryo | Risk Seviyesi | Aksiyon |
|---|---|---|
| Microsoft-hosted agent + sadece built-in task | Düşük | Axios kullanımını yine de audit edin |
| Microsoft-hosted agent + custom npm script | Orta | package-lock.json kontrolü + secret rotasyonu |
| Self-hosted agent + npm bağımlılıklar | Yüksek | Agent’ı reimage + tam audit + credential rotasyonu |
| Container tabanlı build + npm cache | Yüksek | Container image’ını yeniden build + cache temizliği |
| Self-hosted agent + 3. parti Marketplace extension | Çok Yüksek | Yukarıdakilerin hepsi + extension audit |
Evet, tablo kaba resmî veriyor. Ama dur bir saniye — asıl hayatı nokta, sizin pipeline’ın nerede koştuğu ve orada ne kadar kalıntı bıraktığı.
Self-Hosted Agent Kullananlar İçin Acil Adımlar
Tuhaf ama, Self-hosted agent kullanıyorsanız iş biraz daha ciddileşiyor. Çünkü Microsoft-hosted tarafta ortam gidip geliyor, ama self-hosted agent kalıyor; cache kalıyor, npm modülleri kalıyor, environment state kalıyor, yanı temizlik yapılmadıysa eski izler orada dürüyor. 2023’te bir e-ticaret müşterimizde buna benzer bir şey yaşamıştık — paket adı farklıydı ama mantık aynıydı — ve agent üzerindeki npm cache içinde zararlı paket haftalarca sessizce beklemişti; kimse fark etmeyince her yeni build önü tekrar servis etmişti.
Neyse, uzatmadan listeye geçeyim:
- Agent’ı reimage edin veya sıfırdan kurun. “Ama canım sadece npm cache’i temizlesem yetmez mi?” diye soran çok oluyor; açık konuşayım, çoğu durumda yetmez. Saldırganın ikinci aşama payload’ünü nereye yazdığını bilemezsiniz.
- 31 Mart civarındaki agent loglarını inceleyin.
npm installçıktılarındaaxios@1.14.1ya daaxios@0.30.4görünüyor mu bakın; görünmüyor diye rahatlamayın, bazen iz başka yerde çıkıyor. - O agent’ın eriştiği TÜM credential’ları rotate edin. Service principal’lar, PAT token’lar, API key’ler, container registry credential’ları… Hepsi. Bir tanesini atlamak sonra baş ağrıtıyor.
- Agent pool’daki diğer agent’ları da kontrol edin. Aynı pool içinde paylaşılan kaynak varsa iş büyüyebilir; yanı mesele tek makineyle sınırlı kalmayabiliyor. (bence en önemlisi)
- Kullanılan extension’ları gözden geçirin. Hele bir de 3. parti Marketplace extension varsa, “kurulu dursun” demek pek iyi fikir değil; bazen en masum görünen parça en çok iz bırakıyor. — bunu es geçmeyin
Peki neden bu kadar sert davranıyoruz? Çünkü bu tip olaylarda belirsizlik pahalıya patlıyor. Bir şeyi eksik temizlerseniz, sonra tekrar dönüp aynı işi yapmak zorunda kalıyorsunuz; açıkçası bu da kimsenin sevdiği bir senaryo değil.
Tam da öyle.
Pipeline’larınızı Nasıl Kontrol Edeceksiniz?
Tamam, acil müdahale bitti diyelim. Peki sonra ne olacak? Uzun vadede pipeline’ların bu tip saldırılara karşı daha az açık kalması için ne yapacaksınız? Bir dakika, önce şunu net söyleyeyim — mesele sadece Axios değil. Yarın başka bir popüler pakette de aynı tabloyu görebilirsiniz, hatta hiç beklemediğiniz bir bağımlılıkta çıkabilir bu iş; asıl konu pipeline güvenlik hijyeniniz,. Işin günlük düzeni.
Lock Dosyalarını Ciddiye Alın
package-lock.json veya yarn.lock dosyalarını versiyon kontrolüne koyuyor musunuz? Eğer koymuyorsanız, her build’de farklı bir sürüm çekilebilir, sonra da “ama biz dokunmadık” dersiniz. İşin can sıkan kısmı tam burada; supply chain saldırıları zaten bu belirsizliği seviyor. O yüzden pipeline’da npm install yerine npm ci kullanın — lock dosyasına sadık kalıyor ve araya sürpriz versiyon sokmuyor. Bu konuyla ilgili Ingress-NGINX Göçü: 5 Şaşırtıcı Davranış ve Çözümü yazımıza da göz atmanızı tavsiye ederim. Ubuntu 26.04’te .NET 10: Kurulum ve Konteyner Rehberi yazımızda bu konuya da değinmiştik.
# 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-scripts flag’i baya işe yarıyor. Çünkü bu saldırıda zararlı kod tam da postinstall ü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 Azure MCP Server Artık Tek Dosyayla Kuruluyor yazımıza bakabilirsiniz.
Evet.
Marketplace Extension’larını Audit Edin
Vallahi, Bak şimdi, Azure DevOps Marketplace’ten kurduğunuz extension’ların çoğu arkada npm bağımlılıklarıyla geliyor. Kim güncelledi, hangi sürüm Axios taşıyor, hangi (söylemesi ayıp) paket nereye bağlanıyor — çoğu zaman kimsenin net fikri olmuyor. Geçen yıl bir bankacılık projesinde güvenlik audit’i yaparken Marketplace’ten yüklenmiş 14 extension bulduk; bunların 6’sının son güncellemesi 2 yıldan eskiydi — valla güzel iş çıkarmışlar —. Açık konuşayım, içlerinde ne döndüğü pek belli değildi.
Daha önce Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor yazımda buna değinmiştim. Şimdi dönüp bakınca o tavsiyeler daha da kritik görünüyor (özellikle Marketplace tarafını ellemeden bırakıyorsanız), çünkü zincirin en zayıf halkası bazen doğrudan oradan çıkıyor.
Neyse uzatmayalım; gördüğünüz gibi mesele sadece tek bir paketi yamamak değil, pipeline’ın tamamını biraz daha sıkı tutmak.
Türkiye’deki Kurumsal Gerçeklik: Ne Görüyorum?
Şunu söyleyeyim, Açık konuşayım, Türkiye’deki şirketlerin çoğunda supply chain güvenliği hâlâ kenarda dürüyor. KVKK var, ISO 27001 var, SOC — itiraz edebilirsiniz tabi — 2 çalışmaları da yapılıyor; ama iş “npm paketlerinin bütünlüğünü nasıl doğruluyorsunuz?” sorusuna gelince, ortam bir anda sessizleşiyor. Bu yılın başında bir telekomda DevSecOps workshop’u verirken tam bunu sordum: “Pipeline’larınızda SCA (Software Composition Analysis) aracı kullanıyor musunuz?” Odadaki 25 kişiden sadece 3’ü el kaldırdı. Şaşırdım açıkçası.
Küçük bir ekipseniz ve bütçe de dar işe, en azından birkaç temel adım atabilirsiniz. Çok uçuk şeyler değil bunlar. Neden önemli bu? Mesela npm audit‘i her build’de çalıştırın, GitHub’ın Dependabot’ünü ya da Azure DevOps’un dependency scanning özelliğini açın, lock dosyalarını mutlaka commit edin (bunu atlayan çok ekip gördüm), bir de versiyon range’lerini daraltın; ^1.14.0 yerine 1.14.0 gibi exact version kullanmayı düşünün. Cosmos DB’de AI Maliyet Optimizasyonu: 7 Pratik İpucu yazımızda bu konuya da değinmiştik.
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ü.
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. SELinux Volume Label Değişikliği: v1.37 Öncesi Hazırlık yazımızda bu konuya da değinmiştik.
İş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 install sı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.json dosyanıza bir bakın, bu versiyonlardan biri var mı diye (kendi tecrübem). 1.14.0 veya 0.30.3 kullanı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ıca npm audit de 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 ci kullanmak, 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)
İçeriği paylaş:
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.
Yorum gönder