Model İmzalama ve Provenance
AI Tedarik Zinciri Güvencesi

İmzalama ve Provenance Nedir?

İki kavramı net olarak ayırmak işin başlangıcıdır. İmzalama, bir dijital nesnenin (yazılım paketinin, model dosyasının, konfigürasyonun) belirli bir üretici tarafından üretildiğini ve sonradan değiştirilmediğini kriptografik olarak ispatlayan tekniktir. Pratikte gizli anahtar ile özet hesaplanır, dağıtım sırasında bu imza ek bir dosya olarak iletilir, alıcı tarafta açık anahtar ile doğrulanır. Sonuç ikilidir: ya imza geçerlidir, dolayısıyla nesne yayıncı tarafından üretilmiş ve değiştirilmemiştir; ya da geçersizdir, nesne ya yanlış kaynaktan gelmiştir ya da bozulmuştur.

Provenance ise daha geniştir. Yalnızca son nesnenin imzasını değil, o nesnenin üretim sürecindeki tüm adımları kayda alır: hangi kaynak kod kullanıldı, hangi derleyici hangi parametrelerle çalıştırıldı, hangi veri seti referans alındı, hangi sürüm hangi tarihte oluştu. Bir provenance kaydı "bu çıktı, şu süreçten bu girdilerle üretildi" beyanını taşır ve bu beyan imzayla güvence altına alınır.

Yapay zeka bağlamında her ikisinin de değeri farklılaşır. İmzalama, ağırlıkların güvenilir kaynaktan geldiğini söyler; provenance ise "bu model nasıl eğitildi, hangi verilere maruz kaldı, hangi süreçten geçti" sorularına cevap verir. Birincisi indirme bütünlüğüne, ikincisi ise modelin doğasına dair güvence sağlar.

Yazılımdan Yapay Zekaya

Klasik yazılım dünyası tedarik zinciri güvencesini son on yıl içinde olgunlaştırdı. SolarWinds ve Codecov gibi büyük olayların sonrasında SLSA çerçevesi, Sigstore aracı, in-toto standardı ve SBOM (Software Bill of Materials) yaklaşımı sektörel norma dönüştü. Bugün büyük yazılım dağıtım kanallarında imzasız bir paket alıp üretime almak kabul edilebilir bir uygulama değil.

Yapay zeka ekosistemi aynı olgunluğa hızla ilerliyor; ancak yolun başında. Mevcut HuggingFace platformunda imzalama desteği var, ancak yaygınlık henüz tam değil. Modellerin provenance bilgisi çoğu zaman serbest format model kart açıklaması olarak duruyor; makine tarafından doğrulanabilir değil. Bu boşluk doldurulduğunda model tedarik zinciri klasik yazılımla aynı güvence seviyesine ulaşacak.

İki dünya arasındaki temel benzerlik şudur: hem yazılımda hem yapay zekada saldırgan, üretim zincirinin herhangi bir halkasına müdahale ederek sonraki halkaları manipüle eder. Bir kütüphanenin kaynak kodunu, bir derleme aracını ya da bir paket deposunu ele geçirmek nasıl SolarWinds tipi saldırılara yol açtıysa, eğitim verisini, eğitim süreç scriptini ya da model depo hesabını ele geçirmek yapay zeka tarafında benzer sonuçlar doğurur. Çözüm de aynı: her halkayı imzayla bağlamak.

Sigstore ve in-toto

Sigstore, açık kaynak yazılım imzalama altyapısının modern standardıdır. Geliştiricinin kendi anahtarlarını yönetmek zorunda kalmadan dijital imza üretmesini, bu imzanın kamuya açık bir kayıt defterinde (transparency log) saklanmasını ve doğrulamanın merkezi otorite gerektirmeden yapılabilmesini sağlar. Sigstore'un üç temel bileşeni vardır: imzaları üreten Cosign, kısa ömürlü sertifikalar veren Fulcio, ve imzaları saydam biçimde kayda alan Rekor.

Yapay zeka tarafında Sigstore'un kullanımı son yıllarda büyüyor. Model dosyaları Cosign ile imzalanır, imza Rekor'a kaydedilir ve kullanıcı tarafta cosign doğrulamasıyla modelin yayıncıdan geldiği teyit edilir. HuggingFace de bu altyapıyı kendi platformuna entegre etme yönünde adımlar atıyor; ileride imzalı model dağıtımının standart hale gelmesi bekleniyor.

in-toto ise tedarik zincirinin her halkasını ayrı ayrı kayıt altına alan bir çerçevedir. Geliştirme, derleme, test ve dağıtım adımlarının her biri kendi attestation'ını üretir; bunlar bir layout dokümanıyla bağlanır. Yapay zeka bağlamında in-toto, "modeli kim eğitti, hangi veri ile, hangi araçlarla, hangi parametrelerle" sorularına yapılandırılmış cevap üretmenin yoludur.

Cosign ile in-toto'nun birlikte kullanımı, son halinde modelin hem yayıncısının kim olduğunu hem üretim sürecinin nasıl işlediğini doğrulanabilir kılar. Bir model ağırlıkları dosyası Sigstore ile imzalanmış olur; ayrı bir in-toto attestation dosyası modelin üretim akışını kayda alır. İkisi birlikte tedarik zincirinin sertifikasıdır.

SLSA Seviyeleri

SLSA (Supply-chain Levels for Software Artifacts), tedarik zinciri güvencesinin olgunluğunu derecelendiren bir çerçevedir. Dört seviyesi vardır; her seviye bir öncekinin üzerine ek güvenceler getirir. Çerçeve klasik yazılım için geliştirildi, ancak model dünyasına uyarlamak doğrudan mümkün.

SLSA 1, üretim sürecinin yazılı belgelenmesini gerektirir. Model bağlamında bu, "bu model şu repo'daki şu scriptin çalıştırılmasıyla, şu veri seti kullanılarak üretildi" gibi bir provenance belgesinin bulunmasıdır. Belge insan tarafından oluşturulur, makine doğrulaması zayıftır.

SLSA 2, üretim sürecinin sürüm kontrolü altında olmasını ve provenance'ın bir hizmet tarafından otomatik üretilmesini şart koşar. Yapay zeka tarafında bu, eğitim sürecinin bir CI/CD altyapısında çalıştırılması ve provenance kayıtlarının bu altyapıdan otomatik üretilmesidir.

SLSA 3, kaynak ve üretim platformunun bütünlük kontrolünü ekler. Eğitim sürecinin izole bir ortamda yapılması, derleme ve eğitim adımlarının ele geçirilemez biçimde yürütülmesi, provenance'ın bağımsız bir imza altyapısı tarafından doğrulanması gerekir. Bu seviye, yapay zeka için sektörel olarak ulaşılması beklenen orta-uzun vadeli hedeftir.

SLSA 4, en yüksek güvence seviyesidir. Tüm kaynakların ve adımların iki taraflı kontrolü, üretim hattının bağımsız incelemeye açık olması, taşımanın uçtan uca imzalı olması gibi koşullar gerekir. Bu seviye askeri, finansal kritik altyapı ve yüksek riskli kullanım senaryoları için uygun bir hedeftir.

Pratikte kurumların büyük çoğunluğu SLSA 1 ile 2 arasında bir konumda durur. SLSA 3'e geçiş ciddi mühendislik yatırımı gerektirir; ama yüksek değerli senaryolarda yatırıma değer.

Model SBOM

Klasik yazılım dünyasında SBOM (Software Bill of Materials), bir yazılımın içinde hangi bileşenlerin, hangi sürümlerle yer aldığını listeleyen makine okuyucu bir belgedir. Bilinen bir zafiyet ortaya çıktığında, hangi yazılımların etkilendiğini hızlıca tespit etmenin temel yoludur. Yapay zeka tarafında benzer bir kavram olarak AI-BOM ya da Model BOM öne çıkıyor.

Bir model BOM'u şu bileşenleri içerir. Birincisi temel model: modelin türetildiği baz aile ve sürüm. İkincisi eğitim verisi tanımı: kullanılan veri setleri, kaynakları, sürümleri, lisansları. Veri setinin kendisi paylaşılmaz ama tanımı yapılandırılmış biçimde sunulur. Üçüncüsü eğitim altyapısı: hangi framework, hangi sürüm, hangi GPU ailesi, hangi hyperparameter setiyle.

Dördüncüsü bağımlılıklar: modelin yüklenmesi ve çalışması için gereken kütüphaneler, sürümleri. Beşincisi metrik bilgileri: model hangi benchmark'larda nasıl performans gösterdi, hangi önyargı testleri uygulandı. Altıncısı lisans bilgisi: makine okuyucu lisans referansı (örneğin SPDX kimliği).

Bu bileşenlerin tamamı, modele eşlik eden bir dosya olarak (örneğin JSON, YAML ya da SPDX formatında) dağıtılır. Kurumun değerlendirme sürecinin başında bu BOM incelenir; bilinen bir bağımlılık zafiyeti, problemli bir lisans ya da şüpheli bir veri kaynağı varsa erken yakalanır.

Model BOM kavramı sektörel olarak henüz olgunlaşma sürecindedir. CycloneDX gibi standartlar yapay zeka modellerini içerecek şekilde genişletildi; hub'lar bu formatı destekleyen metadata sahaları sunmaya başladı. Önümüzdeki dönemde Model BOM'un olağan dağıtım pratiğine dönüşmesi bekleniyor.

Kurumsal Doğrulama Akışı

Bir kurumun model imzalama ve provenance çerçevesini günlük operasyonuna entegre etmesi için pratik bir akış kurması gerekir. Aşağıda altı adımlı bir uygulama önerisi sunuyoruz.

Birinci adım: politika tanımı. Kurumun hangi seviyede güvence aradığı baştan belirlenmelidir. Yüksek riskli kullanım senaryolarında SLSA 3 hedeflenirken, düşük risk senaryolarında SLSA 1-2 yeterli olabilir. Bu politika, model yönetişim komitesinin (daha önce AI Yönetişim Komitesi yazısında ele aldığımız) çıktılarından biri olmalıdır.

İkinci adım: doğrulama altyapısı. Model yüklemelerinde otomatik olarak çalışacak doğrulama altyapısı kurulmalıdır. Cosign tabanlı bir doğrulama hattı, modelin imzasını ve in-toto attestation'larını kontrol eder. İmzasız ya da geçersiz imzalı modeller otomatik olarak reddedilir.

Üçüncü adım: model BOM incelemesi. Modele eşlik eden BOM dosyası, kurum içi politika ile karşılaştırılır. Yasaklı bağımlılıklar, izin verilmeyen lisanslar ya da şüpheli veri kaynakları otomatik tespit edilir; bu kontrolü geçen modeller bir sonraki aşamaya alınır.

Dördüncü adım: bağımsız değerlendirme. Hem imza hem BOM olumlu çıksa bile yüksek değerli senaryolarda bağımsız bir değerlendirme adımı eklenebilir. Bu adım, modelin izole bir ortamda davranış testlerinden geçirilmesini, akademik backdoor tespit yöntemlerinin uygulanmasını ve operasyonel etki simülasyonlarını kapsar.

Beşinci adım: kayıt ve sürüm yönetimi. Onaylanan model, kurum içi model kayıt sistemine işlenir. Modelin sürüm bilgisi, doğrulama kanıtları, BOM dosyası ve bağımsız değerlendirme sonuçları bir arada saklanır. Aynı model güncellendiğinde sürece baştan girilir; sürüm geçişleri yazılı olarak belgelenir.

Altıncı adım: sürekli izleme. Üretime alınan model için izleme aktif tutulur. Modelin imzaladığı temel bilgilerden biri değiştiğinde (örneğin yayıncının imza anahtarı feshedildi, modelin yayını durduruldu) alarm üretilir ve gerekirse model kullanımdan kaldırılır.

Sık Yapılan Hatalar

Model imzalama ve provenance çerçevesini benimsemeye başlayan kurumların düştüğü tipik tuzakların başında imzayı yalnızca bir formalite gibi görmek gelir. İmza doğrulama otomasyonu kurulmadan, sadece "imza var" sertifikasıyla yetinmek aslında hiçbir şey doğrulamamak demektir. Doğrulama mantığı her yüklemede tetiklenmeli ve başarısız doğrulamalar otomatik olarak reddedilmelidir.

İkinci yaygın hata SLSA seviyesini kurumun teknik kapasitesinden bağımsız belirlemektir. SLSA 4 hedeflemek etkileyici görünür ama bu seviyeye ulaşmanın altyapı ve süreç maliyeti yüksektir. Kurum gerçek olgunluğuna uygun bir hedefle başlamalı; aşamalı olarak yukarı çıkmalıdır.

Üçüncü tuzak BOM'u tek seferlik bir doküman olarak görmektir. Model güncellendiğinde, bağımlılıkları değiştiğinde ya da eğitim verisi yenilendiğinde BOM da güncellenmelidir. Eski bir BOM, kuruma yanlış güven verir.

Dördüncüsü bağımsız değerlendirmeyi imzaya güvenip atlamak: imza modelin "bu yayıncıdan geldiğini" ispatlar, ama "bu model güvenli" demez. Backdoor testleri ve davranışsal değerlendirme imzanın ötesinde bağımsız bir çalışma gerektirir.

Son olarak kayıt ve sürüm yönetimini ihmal etmek: bir gün denetim ya da olay incelemesi geldiğinde "bu model nereden geldi, kim onayladı, hangi kontrollerden geçti" sorularına cevap verebilmek için kayıt sisteminin disipliniyle çalışması şarttır. Anlık karar ve formal süreç dışı onaylar uzun vadede geri çağrılamayan boşluklara dönüşür.

Sonuç

Açık kaynak yapay zeka ekosisteminin tedarik zinciri güvencesi, klasik yazılımın geçtiği yolu hızlı bir biçimde yeniden yürüyor. Sigstore tabanlı imzalama, in-toto provenance, SLSA seviye çerçevesi ve Model BOM yaklaşımı bir araya geldiğinde, kurumun "bu modeli güvenle üretime alabilirim" diyebildiği bir noktaya ulaşmak mümkün hale geliyor.

Bu çerçevelerin benimsenmesi yalnızca ticari ya da düzenleyici bir gereklilik değil; aynı zamanda açık ağırlıklı model ekosisteminin sektörel olgunluk göstergesidir. Türkiye'de bu yönde önderlik edecek kurumlar, hem kendi güvenlik konumlarını sağlamlaştırır hem ekosistemin gelişimine katkı sunar.

AltaySec olarak Türk kurumlarına açık model tedarik zinciri güvencesi, imzalama altyapısı kurulumu, SLSA olgunluk değerlendirmesi ve Model BOM süreç tasarımı konularında destek veriyoruz. Bu seri, açık kaynak yapay zeka güvenliğinin diğer halkalarını ele almaya devam edecek.