Model Tarama Araçları Karşılaştırması 2026
modelscan, picklescan, fickling ve Hub tarayıcıları yan yana

Model tarama aracı nedir?

Model tarama aracı, bir makine öğrenmesi modelinin ağırlık dosyasını (pickle, PyTorch .bin, TensorFlow SavedModel, Keras H5, GGUF, ONNX gibi) çalıştırmadan önce statik olarak inceleyerek, dosyanın yüklenmesi sırasında istenmeyen kod çalıştırma veya zararlı davranış tetikleme potansiyeli taşıyıp taşımadığını tespit eden güvenlik aracıdır. Tarayıcı, dosyanın serileştirme yapısını ayrıştırır; kod yürütmeye yol açabilecek tehlikeli çağrıları (örneğin os.system, eval, __reduce__ üzerinden ağ soketi açma) arar ve bulgularını raporlar.

Bu araçlar bir antivirüs değildir. İmza veritabanına değil, serileştirme biçiminin yapısal analizine dayanırlar. Amaç, modeli yüklemeden önce "bu dosya sadece veri mi, yoksa yürütülebilir talimat da içeriyor mu?" sorusuna cevap vermektir.

Neden gerekli: pickle yükleme anında kod çalıştırır

Sorunun kökeni Python'un pickle biçimidir. Pickle bir seri hale getirme formatı değil, minik bir sanal makinedir: dosya, yükleme (unpickle) sırasında yürütülen bir talimat akışı taşır. Bir modelin __reduce__ yönteminden geçirilen bir yük, dosya torch.load ya da benzeri bir çağrıyla açıldığı anda çalışır. Model henüz tek bir çıkarım (inference) yapmadan önce.

Bu, klasik bir yazılım tedarik zinciri riskidir. Bir model deposundan (Hub) indirdiğiniz ağırlık dosyası, güvenilmeyen bir kaynaktan gelen çalıştırılabilir koddur. Tehdit modelini daha ayrıntılı ele aldığımız Hugging Face Model Hub tedarik zinciri riskleri yazısı bu yüzeyin neden ciddiye alınması gerektiğini anlatır. Model tarayıcıları da tam olarak bu boşluğu, yani "yüklemeden önce doğrula" adımını doldurur.

Not: safetensors gibi tasarımı gereği yalnızca tensör verisi taşıyan, kod yürütmeyen formatlar bu riskin büyük kısmını en baştan ortadan kaldırır. Tarayıcılar, hâlâ dolaşımda olan eski pickle tabanlı dosyalar ve karışık depolar için kritik kalır.

Araçların kapsamı ve mimarisi

Alandaki başlıca açık kaynak seçenekler kapsam ve tasarım felsefesi bakımından ayrışır. Trail of Bits'in geliştirdiği Fickling, pickle akışını bir soyut sözdizim ağacına ayrıştırıp analiz eden, aynı zamanda pickle dosyalarını tersine mühendislik ve enjeksiyon için de kullanılabilen bir araçtır; odağı yalnızca pickle biçimidir. PickleScan daha dar ve pragmatiktir: pickle içindeki tehlikeli import/çağrı örüntülerini bir kara listeye göre tarar. Protect AI'ın ModelScan aracı ise kapsamı genişletir; pickle'ın yanı sıra TensorFlow ve Keras formatlarını da inceler. Promptfoo'nun açık kaynak yaptığı ModelAudit, daha geniş bir format ve kontrol setini hedefleyen daha yeni bir alternatiftir. Bunların üstünde, model depolarının kendi Hub tarayıcıları, yüklenen dosyaları otomatik tarayıp bir bayrak/etiket gösterir.

Kapsam farkı önemlidir: yalnız pickle kapsayan bir araç, deponuzda TensorFlow SavedModel veya Keras dosyaları varsa bu dosyalardaki riskleri hiç görmez.

Kamuya açık karşılaştırma sonuçları

Bu araçların yetkinliğini kendi ölçümümüzle değil, bağımsız ve kamuya açık iki değerlendirme üzerinden aktarıyoruz. Sayılar bu kaynaklara aittir; AltaySec'in kendi kontrollü çalıştırması değildir.

Kamuya açık bir pickle tarayıcı karşılaştırması, kontrollü bir zararlı örnek seti üzerinde araçları yan yana koydu. Bu değerlendirmede PickleScan ve ModelScan beş zararlı örnekten dördünü yakalarken, Fickling örneklerin yalnızca birini yakaladı. Bu, aracın kötü olduğu anlamına gelmez; Fickling'in tespit odağı farklıdır ve genel amaçlı bir kara liste tarayıcısı gibi davranması beklenmez. Ancak "kutudan çıktığı haliyle en geniş yakalama" beklentisiyle Fickling'e güvenen bir ekip, sessiz boşluklarla karşılaşabilir.

Promptfoo'nun ModelAudit'i açık kaynak yaptığı çalışmada yayımlanan doğrudan karşılaştırmada ise 11 dosyalık bir set üzerinde ModelScan 3 bulgu üretirken ModelAudit 16 bulgu raporladı. Bulgu sayısındaki fark hem daha geniş kapsam hem de daha agresif kural setiyle açıklanabilir. Burada kritik nokta şudur: daha fazla bulgu her zaman "daha iyi" değildir; bulguların ne kadarının gerçek risk, ne kadarının gürültü olduğunu ekibinizin doğrulaması gerekir.

Format kapsamı ve yanlış pozitif gerçeği

Araç seçiminde en çok hafife alınan eksen yanlış pozitiftir. Kamuya açık analizler, GGUF ve ONNX formatlarında somut yanlış pozitif kaynaklarına işaret eder. ONNX modellerinde harici veri (external-data) yol referansları, meşru olsa bile bir path traversal şüphesi olarak işaretlenebilir. GGUF dosyalarında ise metadata alanındaki bazı dizeler, zararsız oldukları halde "şüpheli dize" olarak bayraklanabilir.

Bunun operasyonel sonucu nettir: bir tarayıcıyı yeni bir format ailesine körlemesine açıp her bulguyu bloke edici (fail) sayarsanız, CI hattınız meşru modeller yüzünden sürekli kırılır ve ekip zamanla uyarıları görmezden gelmeye başlar. Alarm yorgunluğu, bir güvenlik kontrolünü sessizce etkisizleştirmenin en yaygın yoludur.

Pratik çıkarım: tarayıcıyı kapsadığı formatla eşleştirin. Pickle ağırlıklı bir depo için PickleScan/ModelScan; TensorFlow/Keras karışımı için ModelScan; geniş denetim için ModelAudit mantıklıdır. GGUF/ONNX için bulguları otomatik reddetmek yerine önce inceleme (triyaj) kuyruğuna alın.

CI entegrasyonu ve maliyet

Bir model tarayıcısının değeri, tek seferlik elle çalıştırmada değil, sürekli entegrasyon (CI) hattına yerleştiğinde ortaya çıkar. Hedef, her yeni model dosyası depoya girmeden önce otomatik taranmasıdır. Tipik bir akış şu şekildedir:

# Bağımlılık kurulumu
pip install modelscan

# Tek dosya veya dizin taraması
modelscan -p ./models/

# CI için: bulgu varsa çıkış kodunu değerlendir
modelscan -p ./models/ --reporting-format json > scan.json

Üç araç da komut satırından çalışır ve çevrimdışı (offline) kullanılabilir; yani modeli dış bir servise göndermeden, kendi hattınızda tararsınız. Bu, gizli/kurumsal modeller için önemli bir gerekliliktir. Entegrasyon maliyeti düşük olsa da asıl maliyet, taramanın çıktısını nasıl ele aldığınızdadır:

• Bloke edici (fail-closed): Herhangi bir yüksek riskli bulguda derlemeyi durdur. En güvenli, ama yanlış pozitif yönetimi zayıfsa en kırılgan seçenek.
• Uyarı (fail-open + triyaj): Bulguları raporla, insan onayına bağla. Yanlış pozitif çokken tercih edilir, ama disiplin gerektirir.
• Katmanlı: Bilinen tehlikeli çağrılarda bloke et, belirsiz format bulgularında uyar.

CI hattına yerleştirilmiş taramayı, model kaynağının kriptografik doğrulamasıyla birleştirmek yerinde olur; imza ve köken doğrulamasını model imzalama ve provenance yazısında ele alıyoruz.

Hangi aracı seçmeli? Karar çerçevesi

Tek bir "kazanan" araç yoktur; seçim deponuzun format profiline ve risk toleransınıza bağlıdır. Savunulabilir bir karar çerçevesi:

• Depom ağırlıklı pickle/PyTorch: PickleScan hızlı ön filtre, ModelScan CI'da geniş yakalama için birlikte.
• TensorFlow/Keras da var: ModelScan tek başına yalnız-pickle araçlarından daha kapsayıcı.
• Derin araştırma/olay incelemesi: Fickling ile pickle akışını manuel çözümle.
• Geniş denetim ve daha fazla kontrol: ModelAudit, ama bulgu gürültüsünü triyajlamaya hazır olun.
• Kaynakta ilk filtre: Hub tarayıcı bayrağı bir başlangıç sinyalidir, tek savunma katmanı değildir.

En sağlam yaklaşım tek araç değil, zincirlemedir: birbirini tamamlayan iki tarayıcı (örneğin biri geniş kapsam, biri derin pickle analizi) çalıştırmak, tek bir aracın kör noktasını kapatır. Kamuya açık benchmark'lar da tam olarak bunu gösteriyor: hiçbir araç tüm örnekleri tek başına yakalamadı.

Bu tarayıcılar statik, yükleme-öncesi bir kontroldür. Modelin çalışma zamanındaki davranışını, çıktı sızıntısını veya prompt injection'ı görmezler. AltaySec tarafında model dosyası taramasını, çalışma zamanında istem/çıktı denetimi yapan LLM güvenlik duvarı (Guardian) katmanıyla birlikte konumlandırıyoruz: biri tedarik zincirini, diğeri çalışma zamanını korur. Veri seti tarafındaki gizli enjeksiyon riskini ise açık kaynakladığımız hf-dataset-scan aracıyla ayrı bir eksende ele alıyoruz; bu, model serileştirme taraması değil, eğitim/ince-ayar verisindeki enjeksiyonu hedefleyen tamamlayıcı bir kontroldür.

Sınırlar ve doğru beklenti

Model tarayıcılarına dair üç dürüst sınır:

• Statik analiz atlatılabilir. Obfuscation veya kara listede olmayan yeni çağrı zincirleri, örüntü tabanlı tarayıcıları geçebilir. Cisco'nun sertleştirme çalışmasının varlık nedeni de budur.
• Format kapsamı = kör nokta. Aracın kapsamadığı bir biçim (ör. yalnız-pickle bir araç için Keras dosyası) sessizce taranmadan geçer.
• Bulgu ≠ istismar edilebilirlik. Bir bayrak, o dosyanın kesin zararlı olduğunu kanıtlamaz; triyaj gerektirir. Tersine, temiz bir tarama da mutlak güvence değildir.

Doğru zihinsel model şudur: tarama, güvenilmeyen bir dosyaya duyulan güveni azaltan bir katmandır; tek başına "güvenli" mührü değil. Onu imza/provenance doğrulaması, safetensors'a geçiş ve çalışma zamanı denetimiyle birlikte kullanın. Tedarik zincirinin bütününü upstream veri ve provenance perspektifiyle ele almak, tek bir tarayıcıya aşırı güvenmekten daha savunulabilir bir duruştur.

Kaynaklar

• Promptfoo — Open-sourcing ModelAudit (ModelScan vs ModelAudit karşılaştırması)
• Cisco Blogs — Hardening Pickle File Scanners
• modelaudit — PyPI
• picklescan — PyPI
• Fickling — Trail of Bits (GitHub)
• ModelScan — Protect AI (GitHub)
• OWASP Top 10 for LLM Applications — Supply Chain Vulnerabilities
• MITRE ATLAS — ML Supply Chain Compromise

İlgili Yazılar

• Hugging Face Model Hub Tedarik Zinciri Riskleri
• Model İmzalama ve Provenance
• Upstream AI Güvenlik Veri Seti: Şema ve Provenance
• Model Yükseltme ve Güvenlik Regresyonu