npm solucanı AI kodlama asistanınızı nasıl zehirliyor?

Ne oldu? Kendi kendine yayılan bir solucan

Klasik bir tedarik zinciri saldırısında saldırgan tek bir paketi zehirler ve bekler. Miasma bir solucan gibi davrandı: ele geçirdiği her geliştiricinin yayımlayabildiği tüm paketleri otomatik olarak zehirledi, o paketlerin bağımlı olduğu makinelerden yeni kimlik bilgileri topladı ve bu döngüyü npm, RubyGems ve GitHub üzerinde tekrarladı. İnsan müdahalesi olmadan büyüyen bir yayılma.

Ölçek küçük değildi. 1 Haziran'da @redhat-cloud-services alanı altındaki 32'den fazla paket (haftalık ~80.000 indirme) ele geçirildi. 3 Haziran'daki ana dalgada ise iki saatten kısa sürede 57 paket ve 286'dan fazla sürüm zehirlendi; ilk hedeflerden @vapi-ai/server-sdk tek başına aylık 400.000'i aşan indirmeye sahipti. Yani milyonlarca kurulumun potansiyel menzilinde bir olaydan söz ediyoruz.

# yayılma
1 Haz  @redhat-cloud-services   32+ paket   (~80k haftalık indirme)
3 Haz  @vapi-ai/server-sdk      ilk hedef   (400k+ aylık indirme)
       2 saatte 57 paket · 286+ sürüm

# çalınan token'la enjekte edilen "AI asistan" dosyaları
.claude/setup.mjs        Claude Code oturum hook'u
.cursor/rules/setup.mdc  Cursor özel kuralları
.gemini/settings.json   Gemini ayarları
.vscode/tasks.json      klasör açılınca çalışır

sonuç  sonraki her AI üretimi saldırganın talimatından etkilenebilir

İmzalı paket neden artık tek başına güvence değil?

Saldırının en rahatsız edici yanı, güvendiğimiz doğrulama katmanlarını tek tek aşmış olması. Üç teknik ayrıntı bunu özetliyor:

Birincisi, kod incelemesi hiç devreye girmedi. Saldırgan, ele geçirdiği hesabın yetkisiyle "orphan commit" denen, fork ağının paylaşımlı deposu üzerinden meşru bir depo URL'si altında beliren commit'ler kullandı — normal pull request ve inceleme akışını tamamen atladı. İkincisi, yayımlama için GitHub Actions iş akışlarını tetikleyip OIDC token'ları çekti ve paketleri doğrudan npm'e itti. Üçüncüsü ve en çarpıcısı: bu paketler geçerli SLSA provenance imzalarıyla geldi. Sigstore altyapısı kullanılarak sahtelenen bu provenance, "bu paket güvenilir bir hattan çıktı" güvencesi vermek için tasarlanmış mekanizmanın kendisini saldırganın lehine çevirdi. Belgelenen ilk vakalardan biri, meşru derleme kanıtı taşıyan zararlı paketler.

Buradaki ders keskin: bir imza, bir paketin güvenli olduğunu değil, iddia edildiği yerden geldiğini söyler. O "yer" ele geçirildiğinde imza sizi rahatlatan ama korumayan bir mühre dönüşür. Provenance ve imzalama çıtayı yükseltir; ama tek başına "güvenli" anlamına gelmez.

Bir ayrıntı daha kurulum aşamasındaki savunmayı atlattı. Kötü kod, izlenen preinstall/postinstall script'lerine değil, binding.gyp dosyasındaki bir sources hilesine gömülmüştü; bu sayede package.json'a hiç dokunmadan, npm install sırasında çalıştı ve alışılmış tarayıcıların çoğunu görünmez biçimde geçti.

Asıl yenilik: kodu değil, kodu üreten aracı zehirlemek

Solucanın kimlik bilgisi çalması ve kendini yayması kötü; ama gerçekten yeni olan davranışı, bulaştığı projelere AI asistan yapılandırmalarını enjekte etmesiydi. Çalınan GitHub token'larıyla depolara .claude/setup.mjs, .cursor/rules/setup.mdc, .gemini/settings.json ve .vscode/tasks.json gibi dosyalar eklendi. Bunların bir kısmı proje açılır açılmaz ya da asistan oturumu başladığında çalışır; bir kısmı ise asistanın davranışını yönlendiren "kural" dosyalarıdır.

Farkı görmek önemli. Zehirlenen bir kütüphaneyi fark edip kaldırabilirsiniz. Ama zehirlenen bir asistan config'i, o projede bundan sonra üretilecek kodu etkiler. Geliştirici asistandan bir fonksiyon ister, asistan görünürde makul bir kod üretir — ama saldırganın gizli talimatı, o koda ince bir arka kapı ya da bir zafiyet yerleştirmiş olabilir. Kod, incelemede "geliştiricinin yazdığı" gibi görünür. Saldırı yüzeyi artık teslim edilen paket değil, üretim anının kendisidir.

Bu, prompt injection yazımızda konuştuğumuz mantığın tedarik zincirine taşınmış hâli: güvenilmeyen içerik, modelin/aracın talimatı sanacağı bir yere sızıyor. Orada içerik ajanın okuduğu bir e-postaydı; burada projenizin içine yerleşmiş bir config dosyası. İkisinin de ortak noktası, "veri" ile "talimat" arasındaki sınırın istismar edilmesi.

Peki ne yapmalı? Pratik bir çerçeve

Bu saldırının kapattığı boşluklar egzotik değil; hepsi bilinen tedarik zinciri hijyeninin biraz daha disiplinli uygulanmasıyla kapanıyor. Sade bir çerçeve:

• AI asistan dosyalarını sürüm kontrolünde izleyin — .claude, .cursor, .gemini, .vscode altındaki her değişikliği kod incelemesine tabi tutun. Beklenmedik bir setup.mjs veya kural dosyası, tıpkı şüpheli bir script gibi ele alınmalı.
• Kurulum script'lerini kapatın — mümkün olan yerde npm install --ignore-scripts ya da .npmrc'de ignore-scripts=true kullanın. Kurulum anında keyfi kod çalışmasını engellemek, bu tür saldırıların en sık kullandığı kapıyı kapatır.
• Bağımlılıkları sabitleyin ve bekletin — lockfile'da bütünlük (integrity) hash'iyle sabitleyin; yeni yayımlanan sürümlere hemen güvenmeyin, 24-72 saatlik bir bekleme penceresi koyun. Solucanların en hızlı yayıldığı ilk saatler, çoğunlukla bu pencerede yakalanır.
• İmzayı kanıt değil, ipucu sayın — SLSA provenance ve imza değerlidir ama "güvenli" demek değildir. Doğrulamayı tek katman olarak görmeyin; kaynağın kendisinin ele geçirilebileceğini varsayın.
• Pipeline'da en az yetki uygulayın — CI/CD hattınızın yayımlama ve OIDC token yetkilerini daraltın; bir hesabın ele geçirilmesi tüm paketleri yayımlayabilme hakkına dönüşmesin. Yayımlama için ayrı, kısıtlı kimlikler kullanın.
• Etkilendiyseniz, kimlikleri döndürün — bir bulaşma şüphesinde npm, GitHub ve bulut (AWS, GCP, Azure, Vault) kimlik bilgilerini yenileyin, enjekte edilen config dosyalarını temizleyin ve son commit'leri denetleyin. Gözlemlenebilirlik olmadan neyin sızdığını bilemezsiniz.

Bu yaklaşım, klasik web uygulama güvenliğinin "hiçbir girdiye peşinen güvenme, savunmayı katmanla" ilkesinin tedarik zincirine ve AI iş akışına taşınmış hâli. Değişen tek şey, güvenilmeyen "girdinin" artık bir form alanı değil, kurduğunuz bir paket ve asistanınızın okuduğu bir config dosyası olması.

Peki geriye ne kalıyor?

Miasma, tedarik zinciri saldırılarının nereye evrildiğinin habercisi. Bir yandan bildiğimiz oyun: ele geçirilen hesap, zehirlenen paket. Öte yandan yeni bir katman: saldırgan artık yalnızca sizin çalıştıracağınız kodu değil, sizin adınıza kod üreten aracı hedef alıyor. AI asistanları geliştirme akışının merkezine yerleştikçe, onların yapılandırması da birinci sınıf bir güvenlik varlığı hâline geliyor.

Yani asıl soru "bu paketi imzalı mı indirdim?" değil. Doğru soru şu: bir bağımlılık ya da bir asistan config'i sessizce ele geçirilse, benim üretim hattım bunu ne kadar hızlı fark eder ve verdiği zararı baştan ne kadar sınırladım? Bu soruyu dürüstçe yanıtlayan bir ekip, imzaya değil katmanlı savunmaya ve görünürlüğe yaslandığı için, bir sonraki solucanı manşetten değil kendi denetiminden öğrenir.

Konunun farklı yönlerine bakmak isterseniz geliştirici araçları üzerinden tedarik zinciri saldırıları ve prompt injection ve AI ajanları yazılarımıza; temel referans için Bilgi Merkezi · CI/CD & Pipeline ve Web Uygulama Güvenliği rehberlerine göz atabilirsiniz. Saldırının teknik ayrıntıları için StepSecurity'nin analizine bakabilirsiniz.