Shai-Hulud 2.0 npm Saldırısı: IDE Artık Yeni Perimetre

Geliştirici Ekosistemindeki Kırılma Noktası

Shai-Hulud 2.0, klasik bir zararlı paket olayından çok daha fazlasını temsil ediyor. Kasım 2025 dalgasında npm ekosistemindeki çok sayıda paket ve yüksek indirme hacmine sahip bağımlılık etkilendi; saldırı geliştirici ekosisteminin güven varsayımlarını doğrudan hedef aldı.

Bu saldırının kritik farkı şuydu: paket sadece bir makinede çalışıp veri çalmıyordu. Paket yöneticisi, geliştirici kimlikleri ve yayın yetkileri üzerinden kendini başka paketlere taşıyan bir yayılım mekanizmasına dönüştü. Yani saldırganın hedefi tek bir uygulama değildi; yazılım üretim hattının kendisiydi.

Güvenlik ekipleri uzun süre üretim ortamını gerçek sınır kabul etti. Firewall, EDR, SIEM ve cloud kontrolleri bu varsayım üzerine kuruldu. Shai-Hulud 2.0 ise rahatsız edici bir şeyi netleştirdi: modern şirketlerde en güçlü yetkilerden bazıları geliştirici laptoplarında, IDE eklentilerinde, package manager hook'larında ve CI/CD token'larında yaşıyor.

IDE Neden Yeni Perimetre Oldu?

Geliştirici ortamı artık sadece kod yazılan yer değil. Aynı anda:

• GitHub ve GitLab token'larına erişiyor.
• npm, PyPI veya container registry yayın yetkisi taşıyor.
• AWS, GCP, Azure ve SaaS secret'larını lokal dosyalarda veya shell geçmişinde tutabiliyor.
• AI coding assistant'lara proje bağlamı, terminal çıktısı ve bazen gizli dosyalar açılıyor.
• CI/CD pipeline'larıyla doğrudan ilişki kuruyor.

Bu yüzden saldırgan açısından bir geliştirici makinesi, üretim sunucusundan daha cazip olabilir. Üretim sunucusunda segmentasyon ve monitoring vardır. Geliştirici makinesinde ise çoğu zaman hız, güvenlikten önce gelir.

Shai-Hulud tarzı saldırılar bu kültürel boşluğu kullanır. npm install gibi günlük bir işlem, güvenilir bir bakımcı hesabından geldiği için sorgulanmaz. Preinstall script'leri, build hook'ları ve paket yöneticisi davranışları çoğu ekipte ayrı bir risk yüzeyi olarak modellenmez.

Teknik Risk: Preinstall Aşaması

Saldırıların en tehlikeli kısmı, kodun uygulama çalışmadan önce tetiklenebilmesidir. Bir paket yüklenirken preinstall, install veya postinstall script'leri devreye girebilir. Bu aşamada zararlı kod:

1. Lokal credential ve token dosyalarını arar.
2. GitHub, npm, cloud ve CI/CD yetkilerini toplar.
3. Paket sahibinin yayınlayabildiği projeleri listeler.
4. Zararlı payload'ı başka paketlere ekler.
5. Kalıcılık için self-hosted runner, cron veya shell profile gibi yüzeylere tutunur.

Bu zincirde asıl problem tek bir exploit değildir. Problem, yazılım ekosisteminin otomasyona duyduğu kör güvendir. Paket yöneticileri kod çalıştırabilir; CI sistemleri otomatik test eder; registry'ler imzalanmamış veya zayıf doğrulanmış artifact'ları kabul eder; geliştiriciler hız için uyarıları geçer.

AI Coding Assistant Riski Nerede Başlıyor?

Shai-Hulud doğrudan bir AI saldırısı olmak zorunda değil. Ama AI coding assistant çağında etkisi büyür. Çünkü Cursor, Copilot, Claude Code veya benzeri araçlar:

• Paket güncelleme önerilerini hızlandırır.
• Hata düzeltirken dependency ekleyebilir.
• Terminal komutlarını çalıştırma akışına yaklaşır.
• Kod tabanının geniş bağlamına erişir.

Bir saldırgan zararlı paketi sadece insan geliştiriciye değil, AI destekli geliştirme döngüsüne de sokabilir. AI aracı "build kırılıyor, şu paketi ekleyelim" dediğinde ve geliştirici bunu onayladığında, saldırının sosyal mühendislik maliyeti düşer.

Bu nedenle AI coding security, sadece prompt leakage meselesi değildir. IDE, dependency graph, package hooks ve agent izinleri aynı threat model içinde ele alınmalıdır.

Bu risk sınıfı, daha önce incelediğimiz Axios npm tedarik zinciri saldırısı, AI coding assistant parola sızıntıları ve Vercel/Context.ai olayı ile aynı eksende düşünülmelidir: üretim ortamına giden yol çoğu zaman geliştirici aracından başlar.

Eresus Perspektifi: Ne Test Edilmeli?

Bu tür saldırılara karşı "npm audit çalıştırıyoruz" cevabı yeterli değildir. Audit çoğu zaman bilinen zafiyetleri yakalar; kompromize edilmiş yeni sürüm, obfuscated payload veya credential-harvesting davranışı farklı bir sınıftır.

Eresus yaklaşımında DevSecOps ve AI coding ortamları şu kontrollerle test edilmelidir:

1. Package Hook Görünürlüğü

preinstall, postinstall, prepare ve build script'leri ayrı bir saldırı yüzeyi olarak izlenmeli. CI pipeline'ında script çalıştırma davranışı loglanmalı ve yüksek riskli komutlar bloklanmalıdır.

2. Token Blast Radius Analizi

Geliştirici token'ları ve CI secret'ları hangi paketleri yayınlayabilir, hangi cloud kaynaklarını okuyabilir, hangi GitHub organization izinlerine sahiptir? Bu harita çıkarılmadan tedarik zinciri riski ölçülemez.

3. Ephemeral Build Ortamları

Kalıcı runner'lar saldırgan için altın madendir. Build ortamları mümkün olduğunca tek kullanımlık olmalı; job bittikten sonra dosya sistemi, credential cache ve network state temizlenmelidir.

4. AI Assistant Yetki Sınırları

AI coding assistant'ların terminal çalıştırma, dosya okuma, .env erişimi, package install ve outbound network davranışları policy ile sınırlandırılmalıdır. "Agent hızlandırıyor" diye agent'a sınırsız workspace vermek, junior bir geliştiriciye production admin vermekle aynı mantık hatasıdır.

5. Dependency Diff İncelemesi

Yeni eklenen paketler ve sürüm yükseltmeleri otomatik olarak incelenmeli. Sadece package name değil; maintainer değişimi, install script değişimi, obfuscation, yeni network call ve binary drop davranışı kontrol edilmelidir.

CISO İçin Pratik Kontrol Listesi

İlk 30 günde yapılacak işler:

• Kritik repolarda dependency install script'lerini envanterleyin.
• GitHub, npm ve cloud token'larında en geniş yetkili kullanıcıları bulun.
• CI runner'ları kalıcı mı, ephemeral mı doğrulayın.
• AI coding assistant kullanan ekiplerde .env, secret ve terminal erişim politikalarını yazılı hale getirin.
• Son 90 günde eklenen dependency'leri risk skoruna göre tekrar inceleyin.

90 gün içinde yapılacak işler:

• Package install davranışı için sandbox ve egress filtering kurun.
• Registry access'i organization seviyesinde policy'ye bağlayın.
• Developer workstation hardening'i sadece EDR ile sınırlamayın; package manager, IDE ve AI assistant davranışlarını kapsayın.
• DevSecOps red team senaryolarına "kompromize package ile token hırsızlığı" testini ekleyin.

Sonuç

Shai-Hulud 2.0'ın dersi basit: modern saldırgan üretim sunucusuna saldırmak zorunda değil. Geliştiriciye, IDE'ye, paket yöneticisine veya AI coding döngüsüne saldırarak aynı sonuca daha sessiz ulaşabilir.

Bu yüzden yazılım tedarik zinciri güvenliği artık sadece SCA raporu değildir. Gerçek soru şudur: Bir paket, bir AI assistant veya bir IDE eklentisi geliştirici ortamınıza girdiğinde neyi okuyabilir, neyi çalıştırabilir ve hangi sistemlere yayılabilir?

Bu soruya kanıtla cevap veremeyen ekipler, tedarik zinciri riskini yönetmiyor; sadece güveniyor.

Geliştirici ortamları şirketinizin görünmeyen üretim hattıdır; burada sızan bir token, production firewall'unuzdan çok daha hızlı yıkım yaratabilir. Eresus Security, DevSecOps audit ve AI coding assistant güvenlik testlerinde paket yöneticisi hook'larından CI/CD secret zincirine kadar bu hattı saldırgan gözüyle doğrular. Tedarik zinciri güvenliğini rapor seviyesinde değil, exploit kanıtı ve iyileştirme planıyla yönetmek istiyorsanız bu alanı şansa bırakmamalısınız.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?