Ortak Güvenlik Açıkları ve Maruziyetler (CVE) sistemi, yazılım güvenlik açıklarının küresel standartta kataloglanmasını sağlar. MITRE tarafından yönetilen ve CISA tarafından desteklenen bu program, her güvenlik açığına bir kimlik ve tanım atayarak geliştiriciler, satıcılar ve savunucuların bilinen risklere hızlıca müdahale edebilmesini sağlar.
Yapay zeka (YZ) modelleri, kurumsal sistemlerin temel bileşenleri haline geldikçe, güvenlik topluluğu şu soruyu sormaya başladı: CVE sistemi, YZ modellerine de uygulanmalı mı? YZ modelleri, tehditkar istemler, zehirlenmiş eğitim verileri ve veri sızıntısı gibi yeni hata modları sergiliyor. Bu durumlar, CVE tanımına uymayan güvenlik açıkları olarak kabul edilebilir. CVE politikalarına göre, bir güvenlik açığı, bir ürün içindeki bir zayıflığın, gizlilik, bütünlük veya erişilebilirlik garantisini ihlal etmesi durumunu ifade eder.
Çoğu durumda, bir modele CVE atamak, yanlış bir kapsamdır. Gerçek zayıflıklar, bu ağırlıkları yükleyen ve kullanan çerçevelerde ve uygulamalardadır. Modeller, parametrelerle tanımlanmış matematiksel sistemlerdir: API’ler, araçlar ve iş mantığı sağlayan çerçevelere yüklenen ikili nesneler. Güvenlik açıkları, oturum yönetimi, veri işleme veya çerçeve serileştirmesi gibi çevredeki kodda bulunmaktadır, statik ağırlık dosyalarında değil.
Bu yazıda, CVE’lerin genellikle uygulamalara ve çerçevelere, değil YZ modellerine yönelik neden uygulanmaması gerektiğini açıklıyoruz.
Bir modele CVE önerildiğinde neyi tanımlıyor?
Önerilen YZ modeli CVE’leri genellikle üç kategoriye düşer:
- Uygulama veya çerçeve zayıflıkları: Modelin etrafını sardığı veya hizmet ettiği yazılımdaki problemler. Örnek: güvensiz oturum yönetimi ya da çerçeve seviyesindeki kusurlar (örneğin, TensorFlow CVE’leri).
- Tedarik zinciri sorunları: Zehirlenmiş ağırlıklar, zehirlenmiş veri setleri veya tehlikeye atılmış depolar gibi riskler. Bunlar, CVE’lerle izlenmekten çok tedarik zinciri güvenliği mekanizmalarıyla izlenmelidir.
- Modellerin istatistiksel davranışları: Veri ezberleme, önyargı veya düşmanlık hassasiyeti gibi doğal özellikler. Bunlar, CVE’nin tanımında güvenlik açığı olarak kabul edilmez ve uygulama tasarımında hafifletilmelidir.
Örneğin, kör SQL enjeksiyonu durumunu düşünelim: Hata SQL veritabanında değil, sorguları temizlemekte başarısız olan uygulamadadır. Bu tür bir saldırıda, bir saldırgan duyarlı verileri birer birer çalmak için sorgular oluşturabilir, oysa veritabanı tam olarak beklenen şekilde çalışmaktadır. Zayıflık, uygulamanın ham sorgu erişimini açığa çıkarmasında yatmaktadır, veritabanında değil.
Düşmanlık ve çıkarım zamanındaki saldırılar da aynı paterni izler. Model, beklenildiği gibi çıkarım yapıyor ama çevredeki uygulama erişimi kontrol etmede ya da kötü niyetli sorguları tespit etmede başarısızdır. Uygun olduğunda, herhangi bir CVE, uygulama katmanına karşı verilmelidir, model ağırlıkları değil.
YZ modellerine yönelik farklı saldırı sınıfları CVE kriterleriyle nasıl uyumlu veya uyumsuz?
YZ modelleri yazılım eserleridir, ancak olasılıksal doğaları, güvenlik açığı gibi görünen davranışlar üretebilir. Bunların çoğu, güvenli olmayan uygulama bağlamlarında sömürülen normal çıkarım sonuçlarıdır.
Bir CVE’nin uygulanabilir olup olmadığını değerlendirirken, iki soru önemlidir:
- Model, güvenlik özelliğini ihlal edecek şekilde amaçlanan çıkarım işlevinde başarısız mı oldu?
- Sorun, bu model örneğine özgü olup, bir CVE ID’sinin kullanıcıların bunu tanımlayıp düzeltmelerine yardımcı olmasını sağlar mı; yoksa tüm modellere uygulanan saldırı sınıfını tekrar mı ifade ediyor?
Çoğu durumda, her iki sorunun da yanıtı hayırdır. Sınırsız erişime sahip herhangi bir model, çıkartma, çıkarım, düşman sorguları veya zehirleme saldırılarına maruz kalabilir. Bu, belirli bir model örneği üzerindeki zayıflık değil, makine öğrenim sistemleri sınıfının bir özelliğidir. Burada bir CVE vermek, hiçbir uygulanabilir değer eklemez; yalnızca YZ modellerinin bilinen saldırı ailelerine karşı hassas olduğunu tekrarlar.
CVE’ler, düzeltilebilen zayıflıkları izlemek için mevcuttur. Çoğu YZ saldırı tekniği ya:
- Normal çıkarım davranışı: Modellerin, girdi ve çıktı arasında istatistiksel eserleri ortaya çıkarması durumunu ifade eder.
- Sistem tasarım kusurları: Uygulamaların modeli gereksiz yere erişime açması, sorgu izleme veya çıktı filtrelemesi eksikliği gibi sorunlardır.
Bunları “model güvenlik açıkları” olarak etiketlemek, CVE’lerin amacını sulandırır. Doğru kapsam, uygulanabilir zayıflıkların bulunduğu çerçeveler, API’ler ve uygulamalardır.
Saldırganlar model ağırlıklarını nasıl çıkarır veya model davranışını nasıl yeniden üretir ve bu bir güvenlik açığı mıdır?
Bu saldırılar, izinsiz olarak model ağırlıklarını çıkarmak veya model davranışını yeniden üretmeyi hedefler. Örnekler arasında model çalma, kısmi ağırlık çıkarımı ve bir sonraki simge dağıtımını tekrar oynatma yer alır. Temel neden, genellikle sınırsız sorgular veya maruz bırakılan çıktılar (örneğin, açıklanan logits) gibi zayıflıklardır. Model, normal çıkarım yapmaktadır. Zayıflık, uygulamanın erişim kontrolünde ve çıktı yönetiminde yatmaktadır.
Modeller eğitim verileri hakkında bilgi sızdırdığında bu bir CVE oluşturur mu?
Burada saldırgan, eğitim setinden hassas bilgileri açığa çıkarmayı hedefler. Teknikler arasında, bir kaydın eğitimde kullanılıp kullanılmadığını tahmin eden üye çıkarımı ve modelin ezberlediği örnekleri yeniden üretmesini sağlama (veri yeniden yapılandırması) yer alır. Bu saldırılar, dikkatli bir şekilde hazırlanmış girdiler yoluyla aşırı uyuma ve güven sızıntısı gibi durumları istismar eder. Yine, model beklenildiği gibi davranmaktadır. Differansiyel gizlilik veya sorgu izleme gibi hafifletmeler sistem düzeyinde uygulanmalıdır.
Düşman girdiler sınıflandırmayı zorunlu kıldığında bu bir model güvenlik açığı mı, yoksa bir sistem hatası mı yaratır?
Bu saldırılar, girdileri manipüle ederek sınıflandırmayı zorlamak veya istenmeyen çıktılar üretmek için yapılır. Görsel alanda, görünmez müdahaleler etiketleri (örneğin, dur işareti yerine hız sınırı işareti) değiştirebilir. Dil alanında, kısıtlamaları aşmak için jailbreak istemleri kullanılabilir. Üretken modeller, düşman istemlerle yasaklanan içerik üretmek için yönlendirilebilir. Model, eğitildiği gibi parametrelerini uygular. Başarısızlık, uygulamanın düşman sorguları tespit etme veya sınırlama yeteneğindeki eksiklikten kaynaklanmaktadır.
Eğer model yüklenirken kötü niyetli kod çalışırsa, modelin kendisi mi suçlu?
Pek çok “model saldırısı”, modelleri yüklemek ve sunmak için kullanılan çerçevelere yönelik saldırılardır. Örnekler arasında, uzaktan kod yürütme imkanı sunan pickle serileştirme istismarları ya da ileri geçişte kötü niyetli kod barındıran lambda-layer yükleri bulunur. Bu sorunlar, güvenli olmayan serileştirme formatları ve çerçeve kusurlarından kaynaklanır. Modelin kendisi etkilenmez. Güvenli bir formata geçerek veya çerçeve değiştirerek bu riski ortadan kaldırmak mümkündür ve herhangi bir CVE, model ağırlıkları değil çerçevenin üzerine olmalıdır.
Ne zaman zehirlenmiş eğitim verileri, bir arka kapılı model oluşturur ve bu bir CVE’yi hak eder mi?
Bu kategori, bir CVE’nin değer taşıyabileceği tek kesimdir. Eğitim sürecinde kötü niyetli örneklerin yerleştirilmesi ile bir saldırGAN, modelin içinde arka kapılar veya hedeflenmiş davranışlar oluşturabilir. Örneğin, bir görüntü sınıflayıcısı gizli bir tetikleyici ile girdi etiketlerini yanlış adlandırabilir veya bir dil modeli zehirlenmiş istemler yoluyla önyargı kazanabilir. Bu tür durumlarda, model eğitim sırasında tehlikeye atılmıştır ve zehirlenmiş ağırlıklar, izlenebilir, takip edilebilir birer nesnedir. Ancak birçok olay, veri kökeni ve doğruluk kontrolleri yoluyla tedarik zinciri sorunları olarak daha iyi ele alınmaktadır; ama kasıtlı arka kapılı modeller, CVE seviyesinde izlemeyi gerektirebilir.
CVE’ler nerelerde uygulanmalı ve YZ’ye özgü riskler nasıl izlenmelidir?
CVE kimlikleri oluşturulmasının belirli bir amacı vardır: geliştiricilerin ve güvenlik ekiplerinin riskleri önceliklendirebilmesi ve düzeltmesi için yazılım bileşenlerindeki sömürülmesi mümkün olan güvenlik açıklarını izlemek ve iletişim kurmaktır.
YZ modelleri, bu kapsamın içine girmez. Çoğu saldırı, beklenen çıkarım davranışını veya modeli sunan yazılımlardaki zayıflıkları istismar eder. Model düzeyinde CVE vermek, uygulanabilir kılavuzlar sağlamaktan çok, gürültü ekler.
CVE’lerin doğru kapsamı, modelleri yükleyen ve sergileyen çerçeveler ve uygulamalardır. İşte sömürülebilir koşulların var olduğu ve yamaların uygulanabileceği yer burasıdır. Tek dar istisna, belirli ağırlık dosyalarında tekrarlanabilir arka kapılar oluşturan kasıtlı eğitim verisi zehirlemesidir; ancak bu durum bile genellikle tedarik zinciri bütünlüğü mekanizmalarıyla daha iyi ele alınmalıdır.
Gelecek yolu açıktır: CVE’leri, gerçek düzeltmeleri yönlendirecek yerlerde uygulayın ve çevre sistemleri tedarik zinciri güvencesi, erişim kontrolleri ve izleme ile güçlendirin. YZ güvenliği, modeli çevreleyen sistemlerin savunulmasına dayanır; her bir istatistiksel özelliği güvenlik açığı olarak kataloglamaktan ziyade.
Daha fazla bilgi almak için güvenlik açığı bildirim formunu doldurarak veya psirt@nvidia.com adresine e-posta göndererek NVIDIA’nın YZ Kırmızı Takımı ile ilgili bilgiler edinebilirsiniz.
