Yapay Zeka Tedarik Zinciri Saldırıları: Açık Kaynaktaki Truva Atları

Devlet destekli siber aktörler ve organize tehdit grupları, günümüzde hedeflerini hacklemek için doğrudan kurumun kapısını çalmak yerine, kurumun kullandığı üçüncü parti kütüphaneleri hedef alıyor. Buna "Tedarik Zinciri Saldırısı" (Supply Chain Attack) denir. Geleneksel yazılımlardaki SolarWinds veya Log4j krizlerinden sonra sahnede artık çok daha korkunç bir açık var: Yapay Zeka Tedarik Zinciri Saldırıları.

Bugün yeni bir LLM projesi geliştiren veri bilimcilerinin %90'ı, modeli sıfırdan eğitmek yerine şirket dışından, özellikle Hugging Face gibi açık kaynak platformlardan "Önceden Eğitilmiş" (Pre-trained) bir model indiriyor. Ancak indirdiğiniz bu devasa dosyalar sadece istatistiksel sayılardan ibaret değil; içlerinde sisteminize tam erişim (RCE) hakkı verebilecek uyuyan kodlar barındırıyor olabilirler.

1. Zehirli Model Dosyaları Sisteme Nasıl Sızar?

Siber suçlular, veri bilimcilerinin popüler modelleri sorgusuz sualsiz indirme eğiliminden (Overreliance) faydalanır. Bir saldırgan, Llama-3-8B veya Stable Diffusion gibi dünyaca ünlü modellerin isimlerine çok benzeyen (Typosquatting) sahte hesaplar ve repolar açar.

A. Tehlikeli Pickle (PT/PKL) Mimarisi

Şirketlerin açık kaynaklardan indirdiği makine öğrenimi modellerinin büyük bir kısmı PyTorch kaynaklı .pkl, .bin veya .pt uzantılı Python "Pickle" formatında tasarlanmıştır. Çoğu geliştiricinin bilmediği bir gerçek vardır: Pickle formatı sadece veriyi değil, Python kodunu da (Arbitrary Code Execution) çalıştırabilir.

Bir bilgisayar korsanı, popüler bir makine öğrenimi modeline zararlı bir yazılım satırı gömer (Pickle Injection). Şirketinizdeki geliştirici bu modeli bilgisayarına indirip, performansını test etmek için model.load() yazdığı saniye, arkada gizlenen virüs çalışır. Dosya bir yazılım uygulaması (EXE) değil, sözde bir "veri" olduğu için standart Antivirüs (EDR) ajanları bu sisteme sızma hareketini kör bir şekilde izler. Geliştiricinin tüm şifreleri anında çalınır.

B. Hugging Face ve Güven İllüzyonu

Hugging Face, AI devrimi için bir Github'tır, muazzam bir nimet sunar. Ancak platformdaki herkes anonim olarak model paylaşabilir. Hugging Face zararlı kod (Malware) taramaları yapsa da, siber korsanlar gelişmiş obfuscation (kod gizleme) mekanizmalarını kullanarak ve zararlıyı doğrudan model ağırlıklarının içine (Tensors) gömerek bu filtreleri aşarlar.

Saldırganlar bazen "açık kaynak bir faydalı model" yayınlar ve bunu Reddit/Twitter üzerinde harika bir araçmış gibi pazarlarlar. Virüs aylar boyunca modeli indiren şirketlerin sunucularına arka kapı (Backdoor) açar.

2. GGUF ve ONNX: Güvenli Liman Mı?

Sektörde Pickle tabanlı saldırılara karşı uyanış başladıkça, şirketler .safetensors ve GGUF (veya ONNX) formatlarına geçiş yapmaya başladılar. Safetensors yapısı gereği rastgele kod çalıştırmaz; sadece model matematiğini saklar.

Ancak Eresus Security araştırmacıları, Zafiyetin sadece dosya uzantısında olmadığını ispatlamıştır. Dosyanın formatı güvenli olsa bile;

İçsel Model Zehirlenmesi (Model Backdooring): Saldırgan modelin matematikal ağırlıklarını öyle bir ayarlar ki, model normalde harika çalışır. Ancak sisteme spesifik bir tetikleyici kelime girilince (örneğin prompt içine "ZULU123" komutu yazıldığında), sistem asıl amacından kopup şirketin kaynak kodlarını dışarı basmaya koda programlanmıştır.
Kütüphane (Lib) Zehirlenmesi: GGUF dosyasını açmak veya okumak için kullanılan llama.cpp gibi üçüncü parti AI kütüphanelerinde oluşan bir "Hafıza Taşırması" (Buffer Overflow) açığı, güvenli görünen bir modelin sisteme RCE yedirmesine olanak tanır.

3. Kurum İçi DevSecOps Mimarisi Nasıl Korunmalı?

Geliştiricilerinize model indirirken veya MLOps süreçlerini tasarlarken körü körüne güven aşılamayın.

Model Hash Kontrolleri: Açık kaynaktan model indirirken, orijinal yaratıcının kriptografik imzalarıyla uyuşup uyuşmadığını doğrulayan (Provenance) otomatik CI/CD bariyerleri kurun.
Asla Üretime (Prod) Doğrudan Çıkmayın: İndirilen modelleri ilk aşamada kesinlikle şirket ağına bağlı olmayan, Strict Sandbox (Katı Karantina) ortamlarında yükleyip test edin. Modelin arkada olağandışı "dış IP'lere" HTTP istekleri yollayıp yollamadığını ağ izleme araçlarıyla gözlemleyin.
Zero Trust MLOps: Eğitimi ve modeli çalıştıran Kubernetes Pod'larınız ve Docker Container'larınız dış dünyaya tamamen kapalı olacak şekilde izole edilmelidir. Model patlasa bile saldırgan yan sunuculara yayılamamalıdır (Lateral movement block).

Sonuç: Geleceğin siber savaşları artık şirketinizin güvenlik duvarında değil, doğrudan Hugging Face üzerinden indirdiğiniz AI ağırlıklarının içinde yaşanıyor. AI ürünlerinizi canlıya almadan önce uzman bir Red Team ekibine taratmak bir tercih değil zorunluluktur.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

Model veya agent hangi ortamda çalışıyor?
Hangi kullanıcı veya servis hesabı kullanılıyor?
Hassas veri kaynakları ayrı etiketlenmiş mi?
Model dosyası veya artefact kaynağı doğrulanmış mı?
Yükleme anında kod çalıştırma riski var mı?
Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
Tool çağrıları ayrı loglanıyor mu?
Kritik aksiyonlarda onay mekanizması var mı?
Test ortamı production verisinden ayrılmış mı?
Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

Güvenilmeyen model dosyaları izole ortamda açılmalı.
Model registry erişimi minimum yetkiyle çalışmalı.
Hash, imza veya provenance bilgisi tutulmalı.
Agent tool izinleri görev bazlı ayrılmalı.
Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
Prompt testleri runtime aksiyon testleriyle desteklenmeli.
Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Operasyonel İnceleme Checklisti

Model veya agent kaynağı doğrulandı mı?
Tool izinleri minimum yetkiyle mi tanımlandı?
Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
Memory kalıcı talimat riskine karşı incelendi mi?
Model artefact hash veya imza ile takip ediliyor mu?
Yükleme işlemi sandbox içinde test edildi mi?
Prompt testi runtime aksiyon testiyle desteklendi mi?
MCP veya plugin server listesi çıkarıldı mı?
Agent production API çağırıyorsa onay var mı?
Veri sızıntısı senaryosu kontrollü denendi mi?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

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?

AI Tedarik Zinciri Saldırıları ve Zehirli Modeller