AI Model Dosyalarında Backdoor Riski

Model Dosyası Veri Değil, Çalıştırılabilir Risk Yüzeyidir

Makine öğrenimi ekipleri model dosyalarını çoğu zaman görsel, PDF veya CSV gibi pasif veri dosyalarıyla aynı kategoride düşünür. Bu yaklaşım tehlikelidir. .pkl, .pth, .h5, .onnx, .safetensors ve .gguf gibi formatlar yalnızca ağırlık saklamaz; loader davranışı, custom layer mantığı, serialization kuralı ve runtime bağımlılığı taşır.

Bir model dosyasındaki backdoor iki farklı biçimde ortaya çıkabilir. İlk biçim doğrudan çalıştırma riskidir: dosya yüklenirken zararlı kod tetiklenir. İkinci biçim ise davranışsal arka kapıdır: model normal testlerde doğru görünür ama belirli trigger gördüğünde saldırganın istediği çıktıyı üretir.

Format Bazlı Tehdit Haritası

Pickle ve PyTorch

Python pickle tabanlı formatlar deserialization sırasında nesne yeniden kurar. Bu mekanizma güvenilmeyen dosya için doğal bir RCE yüzeyi oluşturur. torch.load() gibi rahat kullanılan fonksiyonlar, model intake pipeline içinde sandbox olmadan çalıştırıldığında saldırgan için en kısa yoldur.

Keras ve Custom Layer

Keras modelleri özel katman ve lambda davranışlarıyla esneklik sağlar. Ancak bu esneklik, model yükleme aşamasını kod yürütme sınırına yaklaştırır. Güvenilmeyen bir modelin "sadece inference için" yüklendiğini düşünmek yanıltıcıdır.

ONNX ve Custom Operator

ONNX taşınabilirlik sağlar ama custom operator, kontrol akışı ve runtime bağımlılıkları nedeniyle saldırı yüzeyi büyür. Modeli okuyan servis native extension veya özel op kayıtlarını kontrolsüz kabul ediyorsa format bir konteyner imajı kadar riskli hale gelir.

GGUF ve Native Parser Riski

GGUF gibi performans odaklı formatlarda parser genellikle C/C++ dünyasına yaklaşır. Header, metadata ve tensor boyutu gibi alanlardaki doğrulama hataları bellek güvenliği risklerine dönüşebilir.

Model Intake Pipeline Nasıl Olmalı?

Güvenli model kabul süreci şu adımları içermelidir:

Model dosyası doğrudan production ortamına alınmamalı.
İlk analiz izole sandbox içinde yapılmalı.
Format, hash, boyut, metadata ve beklenen tensor yapısı doğrulanmalı.
Pickle tabanlı yükleme varsayılan olarak yasaklanmalı.
Custom op ve custom layer kullanımı manuel onaya bağlanmalı.
Model davranışı trigger testleriyle ölçülmeli.
Onaylı model registry dışında inference çalıştırılmamalı.

Eresus Yaklaşımı

Eresus Security, AI model dosyalarını klasik zararlı dosya taraması gibi değil, tedarik zinciri ve runtime güvenliği problemi olarak ele alır. Model intake pipeline, registry güvenliği, loader davranışı ve inference izolasyonu birlikte test edilmeden kurumsal AI ortamı güvenli kabul edilmemelidir.

Sık Sorulan Sorular

Bu konuda ilk adım ne olmalı?

Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.

Profesyonel destek ne zaman gerekir?

Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.

Uygulama Notları

AI güvenliği incelenirken ilk soru modelin ne cevap verdiği değil, sistemin hangi yetkiyle ne yapabildiğidir. Aynı prompt güvenli görünebilir; fakat arka tarafta CRM, dosya deposu, ticket sistemi veya SQL aracı bağlıysa risk seviyesi tamamen değişir.

Pratik değerlendirme için ekip şu dört katmanı ayrı ayrı yazmalıdır:

Kullanıcıdan gelen giriş ve sistem prompt sınırları.
Retrieval kaynağı, index yetkisi ve hassas veri filtresi.
Tool çağrıları, API token kapsamı ve onay mekanizması.
Log, izleme, alert ve olay müdahale akışı.

Karar Çerçevesi

AI uygulaması yalnızca metin önerisi veriyorsa risk daha çok veri sızıntısı ve yanlış yönlendirme üzerinden okunur. Uygulama tool çağırıyor, dosya yazıyor, ticket açıyor, ödeme başlatıyor veya müşteri kaydı güncelliyorsa değerlendirme agent runtime güvenliğine döner.

Bu ayrım önemlidir çünkü prompt filtreleri runtime yetki hatasını çözmez. Filtre modeli ikna etmeye çalışır; güvenli runtime ise agent yanlış ikna edilse bile neye erişemeyeceğini belirler.

Profesyonel Destek Eşiği

Aşağıdaki durumlardan biri varsa konu artık yalnızca iç kontrol maddesi değildir:

Production verisi veya müşteri hesabı etkilenebilir.
Yetki sınırı birden fazla rol ya da tenant üzerinden çalışır.
Bulgu zincirlenince veri sızıntısı, kalıcı erişim veya operasyon kesintisi doğurabilir.
Ekipte test kanıtını yeniden üretecek ve remediation önceliği çıkaracak zaman yoktur.

Eresus Security bu noktada bulguyu sadece raporlamakla kalmaz; istismar kanıtı, etki analizi, remediation sırası ve retest kriteriyle birlikte ele alır. Böylece ekip “ne açık?” sorusundan “neyi, hangi sırayla kapatmalıyız?” kararına geçer.

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?