Modeller Arası (Transitive) Tehdit Kapsamında Şüpheli Model Bağımlılığı Algılandı

Genel Bakış

Geçişli veya Modeller Arası (Transitive) Tehditler, temelde güvenli olan bir yapay zeka ana modelinin çalışmak için şüpheli veya sızıntılı üçüncü taraf bağımlılıklara (dependency) otomatik olarak başvurmasıyla oluşur. Günümüz MLOps ortamında hiçbir mimari tek başına işlemez; kod kütüphanelerini, tokenleştirici modülleri veya asistan ağırlıklarını otomatik olarak yüklerler. Saldırganlar ana modeli bozmak yerine bu ikincil eklentileri zehirleyerek sisteminize dolaylı bir hat çekerler.

Sisteminizde bir model PAIT-TMT-300 zafiyeti tetikliyorsa bu durum, orijinal modeliniz basit statik analizleri geçse dahi çalıştırılması için zaruri olan yanal bağımlılıklardan (transitive dependency) birinin şüpheli mantıksal davranışlar sergilediği anlamına gelir.

Bu uyarıyı alan tespit edilmiş ihlaller:

Eresus Security algoritmik tarayıcıları ana modeli değil, modelin yüklemeye mecbur olduğu alt modülde standartları aşan kodlar saptamıştır.
Yanal ağ arayüzü, ağ trafiğinde anormallikler, beklenmeyen lokal dosya okuma komutları ya da dinamik kod çözme talepleri barındırır.
Tehdit aktörleri model ağırlıklarınızı doğrudan değiştirmeden, dolaylı yoldan iç sunucunuza gizli bir arka kapı (Backdoor) açarlar.

Saldırı Nasıl Gerçekleşiyor (How The Attack Works)

Saldırganlar, ilk bakışta siber güvenlik araçlarına tamamen masum ve temiz gözüken ancak iç kurgusunda zararlı bir alt-modeli (dependency) barındıran bir "Ana Model" inşa ederler. Kullanıcı bu ana modeli indirdiğinde, arka planda yatan güvenlik risklerinden bihaberdir. Model çalıştırıldığı anda zehirleyici yan modül devreye girer ve makinede dışarıya açık bir yetki tahribatı oluşur.

sequenceDiagram
    participant Saldirgan as Saldırgan
    participant Model_A as Model A (Zararlı)
    participant Model_B as Model B (Masum Görünümlü)
    participant Kurban_Makinesi as Kurban Makinesi
    participant Kurban as Kurban

    Saldirgan->>Model_A: Zararlı komutlara sahip 'Model A' yaratılır
    Saldirgan->>Model_B: Model A'yı bağımlılık (dependency) olarak kullanan Model B üretilir
    Saldirgan->>Kurban: Zehirlenmiş Model B dağıtılır / Publish edilir
    Kurban->>Kurban_Makinesi: Zehirli Model B indirilir ve çalıştırılır
    Kurban_Makinesi->>Model_B: Tahmin/Çıkarım (Runtime) süreci başlar
    Model_B->>Kurban_Makinesi: Model A bağımlılığı nedeniyle sistemde zararlı kod koşturulur
    Kurban_Makinesi->>Saldirgan: Karşı tarafa yetki ve kontrol devredilir (Sızıntı)

Önemli Noktalar

Tedarik Zinciri Zehirlenmesi (Supply Chain Poisoning): Popüler ve küçük bir AI veri dönüştürme kütüphanesine konulan şüpheli yapı, onu kullanan on binlerce şirketi eş zamanlı avlar.
Sessiz İhlal (Silent Intrusion): Ana model kodları temiz göründüğünden ötürü, klasik siber güvenlik çözümleri bu sinsi ikincil telemetri bağlarını göremez.
Sürekli Doğrulama: Sağlam bir LLMSecOps mimarisi sadece ana motorunuzu değil, motorun temas ettiği tüm uç cihazları (attack surface) denetlemelidir.

Etkisi

Dolaylı (Transitive) yapay zeka bağlantılarının güvenceye alınmaması, kurumsal verilerinizi ciddi risklere atar. Şüpheli bir model eklentisi gizlice API anahtarlarınızı, geliştirici ENV değişkenlerini ve eğitilmiş model datasını internete sızdırabilir. Zamanla arka kapı iyice sistemlerinize yerleşerek kurumsal ağınıza bağlı diğer sunucularınıza yatay yönden siber operasyonlar (lateral movement) düzenlemek için bir sıçrama tahtası görevi görür.

En İyi Çözüm Pratikleri

Yapay zeka iş akışlarınızı şüpheli ve dolaylı manipülasyonlara karşı güçlendirmek istiyorsanız:

Makine öğrenimi çalıştıran tüm sunucularda Sıfır Güven (Zero-Trust) ilkelerini hayata geçirin.
Modellerinizin kullandığı bağımlılıklar ve bileşenler (SBOM/Yazılım Malzeme Listesi) üzerinde tam şeffaflık sağlamak için aralıksız Eresus Sentinel otomasyonunuzu çalıştırın.
Container ve tahminsel analiz (inference) birimlerinden dışarıya çıkacak gereksiz tüm internet yetkinliklerini izole edin.

İyileştirme (Remediation)

İlgili modeli, geliştirme ve üretim sahalarından ivedilikle çekin. Hangi alt bağımlılığın PAIT-TMT-300 tehdidini tetiklediğini öğrenmek adına Eresus Security kayıt günlüklerinizi okuyun. Doğrudan problemli eklentiyi kendi şirketinizin yazdığı güvenilir alternatiflerle değiştirerek, modelin bağımlılık ağacını (dependency tree) yeniden şekillendirin. Alt dallar tümüyle temiz bir mantıkla çalışmadan önce, modeli kesinlikle canlı ortama taşımayın.

İleri Okumalar ve Kaynaklar (Further Reading)

Yapay zeka sistemlerindeki dolaylı tedarik zinciri (Supply Chain) saldırıları hakkında daha kapsamlı bilgi edinmek için aşağıdaki global siber güvenlik otorite rehberlerini inceleyebilirsiniz:

MITRE ATLAS - Supply Chain Compromise (AML.T0010): Model bağımlılıklarının istismar taktiklerini detaylandıran harita.
OWASP Top 10 for LLMs - Tedarik Zinciri Zafiyetleri: ML açıklarında en yaygın risk analiz raporları.
NIST - AI Risk Management Framework: Yapay zeka ekosistemlerine güven aşılama ilkeleri.

📥 Eresus Scanner Model Dosyalarındaki Tedarik Zinciri Tehditlerini Saptar Eresus Sentinel ürünümüzle, ML geliştiricileriniz modelleri projenize hiç indirmeden evvel modellerin ve alt bağımlılıklarının zafiyetlerini proaktif bir şekilde izleyebilirsiniz. Şirketinizin risk analiz prosedürlerine uyumlu otomatikleştirilmiş koruma kuralları ile açık kaynak tehlikelerinden bütünüyle kurtulun.

Daha Fazla Bilgi | Demo Randevusu Alın

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?