Tedarik Zinciri Saldırısı: 'Bizim Başımıza Gelmez' Diyebilecek Misiniz?

Kısaca: 24 Mart 2026'da yaygın bir açık kaynak yapay zekâ kütüphanesi olan LiteLLM'in PyPI'daki iki sürümü (1.82.7 ve 1.82.8) kimlik bilgisi çalan kodla yayımlandı. Ağustosta ortaya çıkan veri setleri, bu kampanyada toplanan yaklaşık 434.000 dosyanın 2.500'e yakın kuruluşla ilişkilendirilebildiğini gösterdi. Bu yazıda olayın doğrulanmış kısmını, yaygın "bize olmaz" varsayımlarını ve işletmenizde bu hafta uygulayabileceğiniz somut bir tedarik zinciri kontrol listesini paylaşıyoruz.

Ne oldu? Doğrulanmış özet

LiteLLM, uygulamaların onlarca farklı yapay zekâ sağlayıcısına tek bir arayüzden bağlanmasını sağlayan bir Python kütüphanesi ve proxy'si. Projenin resmî güvenlik bildirimine göre ele geçirilmiş 1.82.7 ve 1.82.8 sürümleri 24 Mart 2026'da 10:39 UTC'den itibaren yaklaşık 40 dakika PyPI'da kaldı, ardından PyPI tarafından karantinaya alındı. Zararlı kod; ortam değişkenlerini, SSH anahtarlarını, bulut sağlayıcı kimlik bilgilerini, Kubernetes belirteçlerini ve veritabanı şifrelerini toplayıp saldırganın sunucusuna gönderiyordu.

Zincirin ilk halkası LiteLLM değildi. LiteLLM ekibi, sızmanın CI/CD hattındaki güvenlik taramasında kullanılan Trivy bağımlılığından başladığını düşünüyor. Trivy'nin GitHub güvenlik bildirimi, 19 Mart'ta saldırganın ele geçirilmiş kimlik bilgileriyle zararlı bir Trivy sürümü yayımladığını ve trivy-action deposundaki 77 sürüm etiketinin 76'sını kimlik bilgisi çalan koda yönlendirdiğini anlatıyor. Yani bir güvenlik tarayıcısı, başka bir projenin yayın anahtarlarını çalmanın aracına dönüştü.

Ağustosta tablo büyüdü. Help Net Security'nin aktardığına göre Hudson Rock, 153 GB'lık bir arşivde 433.909 dosya ve 118.829 CI çalıştırıcı (runner) dökümü buldu ve bunları 2.488 kurumsal alan adıyla ilişkilendirdi. CloudSEK de yaklaşık 434.000 dosyalık veri setinin 2.500'e yakın kuruluşu potansiyel olarak etkilediğini söyledi; ancak bu rakamların doğrulanmış ihlal değil, maruziyet olduğunu özellikle vurguladı. Yani "434.000 CI/CD hattı ele geçirildi" demek doğru değil; doğru ifade, yaklaşık 434.000 çalınmış dosya.

Bir paketin verebileceği zarar indirilme sayısıyla değil, nerede çalıştığı ve neye erişebildiğiyle ölçülür.

"Bizim başımıza gelmez" varsayımları neden tutmuyor?

"Resmî kaynaktan indiriyoruz, güvendeyiz"

Zararlı sürümler sahte bir siteden değil, LiteLLM'in PyPI'daki resmî paketinden dağıtıldı. Kaynak kodu GitHub'da temizdi; sorun dağıtılan pakette ve yayın kimlik bilgisindeydi. Sürüm sabitlemeyen (pip install litellm ya da litellm>=... kullanan) her kurulum o 40 dakika içinde zararlı sürümü alabiliyordu.

"Biz LiteLLM kullanmıyoruz"

Doğrudan kullanmıyor olabilirsiniz. LiteLLM'in bildirimi, zararlı sürümün dolaylı (transitive) bir bağımlılık veya Docker derlemesi üzerinden de gelebileceğini açıkça yazıyor. Trivy örneği daha da öğretici: güvenliği artırmak için kurulan bir araç, saldırının giriş kapısı oldu.

"Şifreleri değiştirdik, konu kapandı"

Trivy'nin bildirimine göre Mart başındaki ilk ifşadan sonra kimlik bilgileri yenilendi, ama bu işlem atomik değildi: tüm kimlik bilgileri aynı anda iptal edilmedi ve birkaç gün süren bu pencere saldırganın erişimini korumasına yetmiş olabilir. 19 Mart saldırısı bu boşluktan geldi. Bağımsız araştırmacı Kevin Beaumont da ağustostaki sızıntıda "her şeyi yeniledik" diyen büyük bir ABD teknoloji şirketinin kimlik bilgilerini, şirketin sorumlu ifşa politikası çerçevesinde denediğini ve neredeyse hepsinin hâlâ çalıştığını yazdı.

"Sorun yapay zekâda"

Beaumont'un özeti net: bu, kötü yapay zekâ güvenliğinden doğan büyük bir tedarik zinciri ihlali; ama yapay zekâ tehdidin kendisi değil. Asıl sorun, yapay zekâyı aceleyle devreye alan ve DevOps güvenliği zayıf kalan kuruluşlar. Ele geçirilen her şey klasik geliştirme altyapısıydı: paket yayın belirteçleri, CI sırları ve bulut anahtarları.

"Bir kere oldu, bitti"

Olmadı. 21 Ekim 2026'da LiteLLM ikinci kez hedef alındı: v1.107.0 sürümü PyPI'da yaklaşık bir saat 45 dakika, Docker imajlarında yaklaşık iki buçuk saat yayında kaldı. Bu kez saldırgan, üç mühendisin çalınmış GitHub CLI OAuth belirteçlerini kullandı. Aynı projede yedi ay içinde iki olay, tedarik zinciri riskinin tek seferlik bir talihsizlik değil, kalıcı bir işletme riski olduğunu gösteriyor.

İşletmeler için tedarik zinciri kontrol listesi

Aşağıdaki adımların hiçbiri büyük bir güvenlik bütçesi gerektirmiyor. Özel yazılım ve SaaS projelerinde başlangıçtan kurulduğunda maliyeti en düşük olan güvenlik önlemleri de bunlar.

1. Sürümleri sabitleyin, kilit dosyası kullanın. requirements.txt içinde == ile tam sürüm, Poetry/uv için poetry.lock veya uv.lock, Node tarafında package-lock.json depoya girmeli. Kilit dosyası ve tam sürüm kullanan bir proje, o 40 dakika içinde derlense bile yeni yayımlanan zararlı sürümü kendiliğinden almaz.
2. Hash doğrulaması açın. pip install --require-hashes ile her paketin SHA-256 özeti kontrol edilir; yayımcı tarafı ele geçirilse bile kilit dosyasındaki özetle uyuşmayan paket kurulmaz. LiteLLM de olay sonrası güvenli sürümlerin özetlerini yayımladı.
3. GitHub Actions'ı commit SHA'sına sabitleyin. @v1 veya @0.34.0 gibi etiketler değiştirilebilir; Trivy saldırısı tam olarak bunu kullandı. Trivy'nin bildirimi de tam SHA ile sabitlemeyi öneriyor.
4. SBOM çıkarın. CycloneDX veya SPDX formatında bir yazılım malzeme listesi, "1.82.7 bizde var mı?" sorusuna dakikalar içinde cevap vermenizi sağlar. Olay günü bunu bilmeyen ekip saatlerini envanter çıkarmaya harcar.
5. CI belirteçlerine en az yetki verin. Derleme işi yayın anahtarını, test işi bulut yönetici anahtarını görmemeli. GitHub'da permissions: alanını varsayılan olarak salt okunur yapın; sırları yalnızca ihtiyaç duyan işe ve ortama (environment) bağlayın.
6. Uzun ömürlü yayın belirteçlerini kaldırın. PyPI'ın Trusted Publishing özelliği, kalıcı API belirteci yerine CI'dan alınan kısa ömürlü OIDC kimliğiyle yayın yapmanızı sağlar. Çalınacak kalıcı bir anahtar yoksa, LiteLLM'de görülen "çalınan belirteçle doğrudan yükleme" senaryosu büyük ölçüde kapanır. Sigstore imzaları ve PyPI attestations ile de paketin nereden derlendiği doğrulanabilir.
7. Sır yenilemeyi tatbikat hâline getirin. Hangi sırrın nerede kullanıldığını listeleyin; yenileme ile iptali aynı anda yapın ve eski anahtarın gerçekten çalışmadığını test edin. Trivy örneği, yarım kalan yenilemenin yenilememekten farkı olmayabileceğini gösterdi.
8. Bağımlılıklarınızı puanlayın. OpenSSF Scorecard, bir açık kaynak projenin dal koruması, imzalı sürüm, bağımlılık sabitleme gibi pratiklerini otomatik puanlar. Kritik bir bağımlılık eklemeden önce bakmaya değer.
9. Güncellemeyi otomatikleştirin ama kontrolsüz bırakmayın. Dependabot veya Renovate güncellemeleri ayrı PR olarak açar; testten geçmeden ana dala girmez. Renovate'in minimumReleaseAge ayarıyla yeni sürümü birkaç gün bekletmek, 40 dakikalık bir zararlı sürüm penceresini sizin için tamamen etkisiz kılabilir.

Peki bugün ne yapmalısınız?

Ekibinizde Python ile yapay zekâ entegrasyonu yapılıyorsa önce 24 Mart ve 21 Ekim tarihli derleme kayıtlarına bakın: LiteLLM 1.82.7, 1.82.8 veya 1.107.0 kurulmuş mu? Kurulmuşsa o ortamın erişebildiği tüm sırları sızmış kabul edip yenileyin ve eskilerini iptal edin. Ardından yukarıdaki listenin ilk üç maddesini uygulayın; en büyük kazanç orada.

Yapay zekâ entegrasyonunu güvenli bir mimariyle kurmak istiyorsanız yapay zeka entegrasyonu projelerinde sağlayıcı anahtarlarını derleme hattından ayrı tutan, en az yetkiyle çalışan bir yapı kurgulayabiliriz. Konunun veri koruma tarafı için sorumlu yapay zekâ ve KVKK uyumu yazımıza, sitenizin genel uyumu için KVKK kontrol listemize göz atabilirsiniz. Yapay zekâya yeni başlıyorsanız adım adım entegrasyon rehberimiz iyi bir başlangıç.