LLM Framework Güvenlik Güncellemesi: Yama Yönetimi Rehberi

LLM framework güvenlik güncellemesi neden ayrı bir disiplin ister?

LLM çatıları modelleri, vektör veritabanlarını, araçları ve dış servisleri birbirine bağlar. Sürüm hızları yüksek, bağımlılık ağaçları geniştir. Daha önemlisi, bu kütüphaneler modelden gelen metni kod çalıştırma, dosya ve ağ işlemlerine yaklaştırır. Bu yüzden bir hata, sıradan bir web kütüphanesindeki hatadan daha büyük etki doğurabilir.

Örnekler bunu gösterir. CVE-2023-29374 kaydına göre LangChain'in 0.0.131 ve öncesindeki LLMMathChain zinciri, istem enjeksiyonuyla Python exec üzerinden kod çalıştırmaya izin veriyordu. CVE-2025-3248 kaydına göre Langflow'un 1.3.0 öncesi sürümlerinde /api/v1/validate/code ucu, kimlik doğrulamasız uzaktan kod çalıştırmaya açıktı. CISA bu açığı 5 Mayıs 2025'te KEV kataloğuna ekledi.

Eğilim sürüyor. CISA KEV kataloğunun 8 Ekim 2026 sürümünde Langflow'a ait altı, LiteLLM'e ait üç, MLflow ve Ray'e ait birer kayıt yer alıyor. LiteLLM gibi model ağ geçitleri de bu listede. Yani yama yönetimi yalnız uygulama çatısını değil, ağ geçidini, iş akışı aracını ve model sunucusunu da kapsamalıdır. Tarihli bir döküm için AI ajan ve MCP CVE zaman çizelgesi yazısına bakabilirsiniz.

Bağımlılık envanteri nasıl çıkarılır?

Envanter, uygulamanın doğrudan ve dolaylı tüm bileşenlerini sürümleriyle listeleyen güncel bir kayıttır. Elle tutulan liste çabuk eskir. Envanteri kilit dosyalarından, konteyner imajından ve derleme hattından otomatik üretin.

• Kilit dosyaları dolaylı bağımlılıkları sürüm numarasıyla verir.
• Konteyner imajı sistem paketlerini ve çalışma zamanı bileşenlerini gösterir.
• Derleme hattı hangi sürümün hangi ortama çıktığını kaydeder.
• Ağ geçitleri, iş akışı araçları, model sunucuları ve MCP sunucuları ayrı satır olarak listelenir.

LLM uygulamalarında envanter paket adlarından ibaret değildir. Modeller, gömme servisleri, vektör veritabanı sürümü ve istem şablonları da kayda girer. Bu geniş listenin şablonu için AI-BOM yazısına bakın. Her bileşen için bir sahip atayın. Bülten geldiğinde işin kime gideceği tartışılmamalıdır.

Sürüm sabitleme ne zaman yardımcı olur?

Sabitleme, bir bağımlılığın tam sürümünü kilitleyerek her derlemenin aynı sonucu vermesini sağlar. Hatanın hangi sürümle oluştuğu kesin bilinir. Bir paketin sahipliği el değiştirirse ya da zararlı bir sürüm yayımlanırsa, otomatik çekilen sürüm sizi etkilemez. Zarar, sabitlemenin unutulmasıyla başlar.

Python'da pip'in hash-checking modu, requirements.txt içindeki her paket için --hash değeri ister ve indirilen dosyayı bu değerle doğrular. --require-hashes bayrağı modu zorunlu kılar. Konteyner imajlarını da etiket yerine özet değeriyle çağırın. Kümede bu kuralın nasıl uygulandığı Kubernetes LLM güvenliği yazısında anlatılır.

Hangi kaynaklar izlenmeli?

Takip dört katmanda yapılır. Her katman farklı bir soruya yanıt verir.

1. Çatının kendi güvenlik duyuruları ve depo güvenlik bildirimleri: ilk ve en ayrıntılı bilgi.
2. CVE ve NVD kayıtları: açığa ortak bir kimlik, etkilenen sürüm aralığı ve şiddet puanı.
3. CISA KEV kataloğu: açığın gerçekten sömürüldüğüne dair kanıt.
4. FIRST EPSS: yayımlanmış bir CVE'nin önümüzdeki 30 gün içinde sömürülme olasılığı tahmini.

Bağımlılık tarayıcısını derleme hattına bağlayın ve bulguları otomatik iş kaydına dönüştürün. Haftalık gözden geçirmede yeni kayıtları envanterle eşleştirin. Kullanmadığınız bir pakete ait uyarı gürültüdür. Uyarıları envanterle süzmek, ekibin dikkatini gerçekten önemli bulgulara toplar.

Dolaylı bağımlılıklara özellikle dikkat edin. Doğrudan eklediğiniz bir çatı, kendi içinde onlarca paket çeker. Açık çoğu zaman bu derin katmanda çıkar ve ekip adını hiç duymadığı bir paketi güncellemek zorunda kalır. Kilit dosyasından türetilen tam envanter bu katmanı görünür kılar. Bir başka kör nokta, geliştiricilerin dizüstü bilgisayarlarında ve not defteri ortamlarında çalışan araçlardır. Langflow ve Ray gibi araçlar geliştirme makinesinde açık bir portla çalıştığında, üretimde olmasa bile saldırı yüzeyidir. Bu kurulumları da envantere alın, ağa açık çalışmalarını yasaklayın ve sürümlerini aynı bültenlerle izleyin.

Önceliklendirme nasıl yapılır?

FIRST'ün CVSS v4.0 belirtimi şiddet bantlarını şöyle tanımlar: 0.0 yok, 0.1-3.9 düşük, 4.0-6.9 orta, 7.0-8.9 yüksek, 9.0-10.0 kritik. Aynı belge, temel puanın açığın kendi özelliklerine göre şiddetini yansıttığını ve tehdit ile ortam ölçütlerini uygulamanın puanı kullanan kurumun sorumluluğu olduğunu belirtir. Yani puan, açığın sizin ortamınızdaki yerini bilmez.

Karar üç soruya dayanır: bileşen ortamınızda gerçekten çalışıyor mu, açık sizin yapılandırmanızda erişilebilir mi, sömürü kanıtı ya da yüksek EPSS olasılığı var mı? Aşağıdaki tablo bir örnek politikadır. Süreleri kendi risk iştahınıza göre ayarlayın.

Acil kısa yolda onay zinciri daralır ve testler odaklanır, ama kayıt ve geri dönüş planı korunur.

Yama test ortamında nasıl doğrulanır?

Doğrulama, güncellemenin üretime benzeyen bir ortamda denenmesidir. LLM bileşenlerinde klasik testler yetmez. Yeni sürümde istem şablonunun işlenişi, araç çağrısı biçimi, yapılandırılmış çıktı ayrıştırması ya da güvenlik süzgeçlerinin davranışı değişebilir. Küçük ama temsili bir değerlendirme kümesi tutun ve her yamada yeniden çalıştırın.

• Kritik kullanıcı akışları çalışıyor mu?
• Güvenlik süzgeçleri ve politika kontrolleri aynı sonucu veriyor mu?
• Araç çağrıları aynı yetki sınırlarıyla mı yapılıyor?
• Gecikme ve kaynak kullanımı kabul edilebilir mi?
• Geri dönüş adımı denendi mi?

Üretime kademeli çıkın: önce küçük bir trafik dilimi, sonra tamamı. Bileşen değişikliklerinde güvenlik davranışını karşılaştırılabilir değerlendirme setleriyle doğrulama yöntemi model yükseltme güvenlik regresyonu yazısında ayrıntılı anlatılır.

Yama hemen uygulanamıyorsa ne yapılır?

Bazen yeni sürüm uygulamayı bozar ya da henüz yayımlanmamıştır. Bu durumda geçici hafifletme uygulanır:

• Etkilenen özelliği ya da ucu kapatın. Langflow örneğinde kod doğrulama ucunu ağ geçidinde engellemek gibi.
• Bileşene erişimi ağ düzeyinde yalnız iç ağa ya da VPN'e daraltın.
• Girdiyi ek doğrulamadan geçirin.
• Bileşeni ayrı bir ağ bölümüne alın ve çıkış trafiğini kısıtlayın.
• Sömürü belirtileri için kayıtları yoğun izlemeye alın.

Geçici önlem kalıcı çözüm değildir. Tarihli bir iş kaydıyla izlenir ve yama yayımlandığında kapatılır.

Süreç nasıl ölçülür ve sürdürülür?

Sürdürülebilirlik, işin kişilere değil sürece bağlanmasıyla sağlanır. Üç gösterge yeterli bir başlangıçtır: bulgunun açılıştan kapanışa geçen süresi, açık kritik bulgu sayısı ve envanter kapsamı. Hangi bileşenlerin sürekli geciktiğini görün ve nedenini ayırın: sahiplik eksikliği mi, test altyapısı mı, onay zinciri mi?

Sık görülen hatalar şunlardır:

• Envanter otomatik değil, elle tutuluyor.
• Bileşenlerin sahibi belli değil.
• Sürümler sabit ama yükseltme takvimi yok.
• Yama sonrası güvenlik davranışı denenmiyor.
• Acil kısa yol tanımlı değil.
• Erteleme kararlarının gerekçesi yazılmıyor.

Yeni bileşen ekleme kapısını da sıkı tutun. Her yeni çatı ya da eklenti için bakımın sürüp sürmediğine, güvenlik duyurusu yayımlayıp yayımlamadığına ve istediği yetkilerin makul olup olmadığına bakın. Sonradan yama yönetmek, baştan seçici olmaktan daha pahalıdır.

Sık Sorulan Sorular

Her güvenlik güncellemesi hemen uygulanmalı mı?

Hayır, ama bekleme süresi bilinçli bir karar olmalıdır. CISA KEV listesinde yer alan, yani sömürüldüğü bilinen ve sizin kullandığınız bileşeni etkileyen bir açık acil ele alınır. Erişilemeyen bir bileşendeki düşük şiddetli açık planlı döngüye bırakılabilir. Her erteleme kararına gerekçe, sorumlu kişi ve yeniden gözden geçirme tarihi yazılmalıdır.

Sürüm sabitleme güvenlik için iyi mi, kötü mü?

İkisi de olabilir. Sabitleme, beklenmeyen değişikliklerin üretime girmesini önler ve tekrar üretilebilir derleme sağlar. Ancak güncellenmeyen sabit sürüm bilinen açıkları biriktirir. Sabitlemeyi otomatik güncelleme önerileri ve düzenli yükseltme döngüsüyle birlikte kullanın. Sabit sürümlerin yaşını ve açık bulgularını her ay düzenli olarak raporlayın.

CVSS puanı yama önceliğini tek başına belirler mi?

Belirlemez. FIRST'ün CVSS v4.0 belirtimine göre temel puan, açığın kendi özelliklerine dayanan şiddetini yansıtır. Tehdit ve ortam ölçütlerini uygulamak puanı kullanan kurumun sorumluluğundadır. Bileşenin internete açık olup olmadığı, KEV kaydı, EPSS olasılığı ve verinin hassasiyeti önceliği değiştirir. Puan başlangıç noktasıdır, karar bağlamla tamamlanır.

Yama sonrası hangi testler çalıştırılmalı?

İşlevsel testler, kritik akışlar için duman testi ve güvenlik regresyon testleri çalıştırılmalıdır. LLM bileşenlerinde ayrıca istem şablonunun işlenişi, araç çağrısı biçimi, yanıt ayrıştırma ve güvenlik süzgeçlerinin davranışı küçük bir değerlendirme kümesiyle denenir. Sonuçlar yama öncesiyle karşılaştırılır ve geri dönüş adımı önceden denenmiş olur.

Küçük bir ekip bu disiplini nasıl sürdürebilir?

Otomasyonla başlayarak. Derleme hattına bağlı bir bağımlılık tarayıcısı, otomatik güncelleme önerileri ve haftada yarım saatlik bir gözden geçirme çoğu işi taşır. En büyük kazanç güncel envanterdir, çünkü neyin kullanıldığı bilinmeden hangi bültenin önemli olduğu da bilinemez. Sahibi atanmış küçük bir envanter, sahipsiz büyük bir listeden daha çok iş görür.

Kaynaklar

• CISA: Known Exploited Vulnerabilities Catalog
• CVE Program: CVE-2025-3248 (Langflow)
• CVE Program: CVE-2023-29374 (LangChain)
• FIRST: CVSS v4.0 Specification Document
• FIRST: Exploit Prediction Scoring System (EPSS)
• pip documentation: Secure installs

İlgili Yazılar

• AI-BOM Nedir? Yapay Zeka Malzeme Listesi İçin Türkçe Uygulama Rehberi CycloneDX ML-BOM'dan KVKK ve 7545 kolonlarına kadar model envanteri
• AI Ajan ve MCP Güvenlik Açıkları 2026: CVE Zaman Çizelgesi Tarih, CVSS, etkilenen sürüm ve ATLAS/ASI eşlemesiyle canlı takip
• Model Yükseltmelerinde Güvenlik Regresyonu Nasıl Kurulur?
• Kubernetes LLM Güvenliği: Model Servisini Sertleştirme