Model nereden geliyor

Altay Kargo'nun destek ekibi, müşteri yazışmalarını özetleyen açık kaynaklı bir model kullanıyor. Bir pazartesi sabahı özetler değişti. Bazı yazışmalarda iade talepleri artık hiç görünmüyordu. Ekip kodu inceledi ama tek satır bile değişmemişti.

Sorun modeldeydi. Servis her açılışta modeli dış depodan yalnız adıyla çekiyordu. Depo sahibi hafta sonu yeni bir sürüm yüklemişti ve servis onu sessizce almıştı.

Kimse üretimde hangi dosyanın çalıştığını kanıtlayamadı. Bu derste böyle bir olayın neden mümkün olduğunu göreceksin. Önce bir modelin kimliğini kuran dört halkayı tanıyacaksın. Sonra sürüm sabitlemeyi, taklit depoları, özet doğrulamasını, imzayı ve aynalamayı adım adım uygulayacaksın.

Bir modeli kullanmak, birinin eğittiği dosyaları kendi sunucuna almak demektir. Bu dosyalar tek parça da değildir. Ağırlıklar ayrı dosyada durur ve çoğu zaman gigabaytlarca yer kaplar. Yapılandırma dosyası katman sayısını ve boyutları söyler.

Belirteçleyici dosyaları metni sayılara çevirir. Bazı depolarda bunlara ek olarak Python kodu da bulunur. Sohbet şablonu ve belirteçleyici ayarları da modelin davranışını şekillendirir. Modeli yüklediğin anda bu parçaların hepsine güvenmiş olursun.

Biri değiştirilmişse modelin davranışı da değişir. Üstelik bu değişiklik hata mesajı üretmez. Model çalışır, sadece başka türlü çalışır.

Klasik yazılımda bu güveni paket yöneticisi yönetir. Sürüm numarası vardır, özet (hash) vardır, çoğu zaman imza da vardır. Model dünyasında bu araçların karşılığı var ama ekipler onları sık atlar. Bir ad yazarsın, kütüphane indirir, iş biter.

Aradaki her adım sessizce geçer. MITRE ATLAS bu riski yapay zekâ tedarik zinciri saldırısı adıyla AML.T0010 koduyla izler. Alt tekniklerden biri doğrudan modelin kendisidir: AML.T0010.003. OWASP'ın büyük dil modeli uygulamaları listesi de tedarik zincirini 2025 sürümünde LLM03 başlığıyla ayrı bir risk olarak sayar.

Kimlik zinciri dört halkadan oluşur. Depo, modelin nerede durduğunu ve hangi hesabın yayınladığını söyler. Sürüm, o deponun hangi anlık görüntüsünü aldığını sabitler.

Özet, indirdiğin dosyanın bit düzeyinde ne olduğunu söyler. İmza ise bu özeti kimin onayladığını kanıtlar.

Halkalar birbirini tamamlar. Özet dosyanın değişmediğini gösterir ama doğru dosyayı seçtiğini göstermez. İmza yayıncıyı gösterir ama hangi sürümü kullandığını sen sabitlemezsen eksik kalır. Saldırgan en zayıf halkayı arar, çünkü zinciri kırmak için tek halka yeter.

En sık görülen hata sürümü serbest bırakmaktır. Depo adını yazarsın, kütüphane ana dalın o anki ucunu indirir. Bugün indirdiğin dosya ile yarın indirdiğin aynı olmayabilir.

Testlerin bir dosyada geçer, üretim başka bir dosyayı yükler. Model depoları git üstüne kuruludur. Bu yüzden sürüm üç biçimde yazılabilir: dal adı, etiket ya da kayıt kimliği (commit).

Dal her yeni kayıtla ilerler. Etiketi de depo sahibi silip başka bir kayda yeniden bağlayabilir. Yalnız kayıt kimliği değişmez, çünkü kaydın içeriğinden hesaplanan bir özettir.

# Gevsek: dal ucu degisirse sessizce baska dosya gelir
model = yukle("altay-kargo/ozetleyici")

# Siki: kayit kimligi sabit, ozet dogrulanir
model = yukle("altay-kargo/ozetleyici",
              revision="3f9c1a2e7b4d0c5a9e8f1b2c3d4e5f6a7b8c9d0e",
              beklenen_ozet=OZET)

# Ayni sabitleme komut satirinda
$ hf download altay-kargo/ozetleyici model.safetensors \
    --revision 3f9c1a2e7b4d0c5a9e8f1b2c3d4e5f6a7b8c9d0e --local-dir indirilen/

Kodu satır satır oku. İlk çağrı yalnız depo adını verir, kütüphane ana dalın ucunu çeker.

İkinci çağrı revision değeriyle kırk karakterlik kayıt kimliğini verir. Depo sahibi ertesi gün yeni bir sürüm yüklese bile sen aynı dosyayı alırsın. beklenen_ozet ikinci bir kilit kurar: indirilen dosyanın özeti onaylı değerle tutmazsa yükleme durur.

Son komut aynı işi komut satırında yapar. hf download aracı --revision seçeneğiyle dal, etiket ya da kayıt kimliği alır. Kayıt kimliği vermek, üretimdeki dosyayı bir yıl sonra bile kanıtlayabilmen demektir.

İkinci hata ada güvenmektir. Popüler bir modelin adına benzeyen depo açmak kolaydır. Tek harf değişir, açıklama kopyalanır, model kartı aynı görünür. Buna yazım taklidi (typosquatting) denir ve paket dünyasında yıllardır çalışır.

Daha sinsi bir biçimi kurum taklididir. 2023'te bir güvenlik araştırmacısı, Hugging Face'te gerçek kurumları taklit eden organizasyon hesapları açtı. Bu kurumların bazı çalışanları hesabı resmi sandı ve katılma isteği gönderdi.

Araştırmacı böylece çalışanların yüklediği modellere tam erişim kazandı. Bu modelleri zararlı sürümlerle değiştirebileceğini de gösterdi. ATLAS bu vakayı AML.CS0027 koduyla kaydeder.

Şemayı bu vakayla oku. Keşif adımında saldırgan hedef kurumun hangi modelleri kullandığını ve çalışanlarının hangi hesapları izlediğini öğrenir. İlk erişim, taklit depodan inen dosyadır.

Kalıcılık, modelin iç depoya alınıp her yeniden başlatmada yüklenmesidir. Yayılma, aynı modelin başka servislere ve ince ayarlara taban olmasıdır. Sızdırma ise yükleme anında çalışan kodun veri taşımasıdır.

Zinciri en ucuz yerde, ilk erişimde kırarsın. Adı değil yayıncı hesabını doğrula. Hesabın doğrulanmış işareti var mı, hesap ne zaman açılmış, geçmişi tutarlı mı diye bak. Kurumun kendi resmi sayfasındaki bağlantıyı ikinci kaynak olarak kullan.

Doğrulamanın pratiği basittir. Modeli indir, özetini hesapla, beklenen değerle karşılaştır. Eşleşmiyorsa yükleme. Beklenen değeri nereden aldığın önemlidir.

Hugging Face Hub büyük dosyaların SHA-256 özetini dosya sayfasında gösterir. Bu değeri model ilk onaylandığında bir kez alırsın ve kendi onaylı listene yazarsın.

Sonraki her indirmede listeyle karşılaştırırsın. Böylece depo sonradan değişse bile fark anında görünür. Aşağıda Altay Kargo'nun yükleme betiğinin çalıştırdığı komutlar var.

$ sha256sum model.safetensors
90ae414a098ccdd1cfc369c0102667d9ebc1c8f94db03ef69d53aeb8fe74d238  model.safetensors

$ cat onayli/ozetleyici.sha256
90ae414a098ccdd1cfc369c0102667d9ebc1c8f94db03ef69d53aeb8fe74d238  model.safetensors

$ sha256sum -c onayli/ozetleyici.sha256
model.safetensors: OK

# Depodaki dosya sessizce degismisse
$ sha256sum -c onayli/ozetleyici.sha256
model.safetensors: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Çıktıyı satır satır oku. İlk komut dosyanın özetini hesaplar ve altmış dört karakterlik bir değer yazar.

İkinci komut, model onaylanırken kaydedilen değeri gösterir. İki değer aynı. Üçüncü komut karşılaştırmayı senin yerine yapar ve OK yazar. Son blokta depodaki dosya yalnız bir bayt değişmiş.

Özet bambaşka bir değere döner ve komut FAILED yazar. Bu durumda sha256sum sıfırdan farklı bir çıkış koduyla biter. Yükleme betiğin bu kodu görünce durmalı. Kuralı koda gömersen kimse unutmaz.

Komutu bir de kendin yaz. Linux sunucularda sha256sum aracı hazır gelir. macOS'te aynı işi shasum aracı -a 256 seçeneğiyle yapar. İki araç da aynı değeri üretir, çünkü algoritma aynıdır.

Çıktıyı gözle karşılaştırmaya güvenme. İnsan gözü altmış dört karakterin ortasındaki tek bir farkı kolayca kaçırır. Karşılaştırmayı her zaman -c seçeneğine ya da betiğe bırak, sonucu çıkış kodundan oku. Aynı adımı sürekli entegrasyon hattına da koyabilirsin, böylece her derleme modeli yeniden doğrular.

Özet dosyanın değişmediğini gösterir ama onu kimin yayımladığını söylemez. Bu soruyu imza cevaplar. Hugging Face Hub git kayıtlarının GPG ile imzalanmasını destekler.

İmzası doğrulanan kayıt sayfada Verified işaretiyle görünür. Bu işaret kaydı kimin yaptığını gösterir, dosyanın güvenli olduğunu göstermez. Model dosyalarının kendisini imzalamak için OpenSSF, Nisan 2025'te model-signing aracının 1.0 sürümünü yayımladı.

Araç model klasöründeki her dosyanın özetini bir listede toplar ve bu listeyi imzalar. İmza Sigstore ile kimlik tabanlı olabilir ya da kendi anahtar çiftinle atılabilir.

# Yayinci tarafi: model klasorunu imzala
$ model_signing sign ozetleyici/ --signature model.sig

# Tuketici tarafi: imzayi ve yayinci kimligini dogrula
$ model_signing verify ozetleyici/ --signature model.sig \
    --identity "[email protected]" \
    --identity-provider "https://kimlik.altaykargo.example"

# Anahtar ciftiyle imzalanmis model
$ model_signing verify key ozetleyici/ --signature model.sig --public-key yayinci.pub

Komutları sırayla oku. İlk komut yayıncı tarafında çalışır. Varsayılan yöntem Sigstore'dur: yayıncı bir kimlik sağlayıcıyla oturum açar, imza o kimliğe bağlanır.

İkinci komut senin tarafında çalışır. Yalnız imzanın geçerli olmasına bakmaz, imzayı atan kimliğin beklediğin kimlik olup olmadığına da bakar. Bu ayrım kritiktir. Saldırgan da kendi hesabıyla geçerli bir imza atabilir.

Doğrulamayı anlamlı kılan, kimliği önceden sabitlemendir. Üçüncü komut kurum içinde sık kullanılan anahtar çifti yöntemidir. Doğrulama tutmazsa model yükleme hattına girmez.

Kurumsal tarafta doğru cevap aynalamaktır. Onaylanan modeli kendi iç depona kopyalarsın, özetini ve imzasını kaydedersin, üretim yalnız oradan çeker. Dış depo silinse bile üretimin ayakta kalır.

Yayıncı dosyayı sessizce değiştirse bile sen onaylı sürümü tutarsın. Aynanın kendisini de koru: iç depoya yalnız onay hattı yazabilsin, mühendisler yalnız okuyabilsin. Aynalama envanteri de kolaylaştırır.

Hangi model, hangi sürüm, hangi serviste çalışıyor sorusuna tek tabloda cevap verirsin. Bu tablonun standart bir biçimi de var. CycloneDX, yazılım malzeme listesini (SBOM) modelleri ve veri kümelerini kapsayacak biçimde genişletir ve buna ML-BOM der. Bir modelde sorun çıktığında etkilenen servisleri dakikalar içinde listelersin.

Bu disiplini uygulamaya taşırken tek bir soru sor: elimdeki dosyanın kökeni bilgisayarımda doğrulanabilir mi? Yanıt hayırsa dosyayı henüz üretime sokma. Altay Kargo'nun pazartesi sabahı yaşadığı olay da bu sorunun cevapsız kalmasından doğdu.

Servis her açılışta dış depoya gidiyordu ve kimse hangi dosyanın geldiğini sormuyordu. Cevap evetse kanıtı da sakla: kayıt kimliği, özet ve imza dosyası modelin yanında dursun. Aşağıdaki örnekte aynı riski farklı bir kurulumda tanı.