# Yama Yönetimi Süreci: Envanterden Doğrulamaya 7 Adımda Güncellemeleri Zamanında ve Güvenle Uygulamak

> Yama yönetimi nedir, nasıl kurulur? Envanterden doğrulamaya 7 adımlık süreç, risk bazlı öncelik tablosu ve yamalanamayan sistemler için çözümler.

Kaynak: https://digitalbridge.com.tr/blog/yama-yonetimi-sureci.html
Yayıncı: Digital Bridge Teknoloji (https://digitalbridge.com.tr)
Konu: Siber Güvenlik ve KVKK
Yayın: 2026-10-26 · Güncelleme: 2026-10-30

Yama yönetimi; işletim sistemi, uygulama, ağ cihazı ve donanım yazılımlarına çıkan güvenlik güncellemelerini belirleme, önceliklendirme, test etme, kurma ve kurulduğunu doğrulama sürecidir. Amaç her yamayı aynı gün kurmak değil, istismar edilen açıkları riske göre sıralayıp işi durdurmadan, kanıtlanabilir biçimde ve düzenli bir takvimle kapatmaktır.

## Kısaca

- Yama yönetimi; güncellemeleri belirleme, önceliklendirme, test etme, kurma ve kurulumu doğrulama adımlarından oluşan sürekli bir süreçtir (NIST SP 800-40 Rev. 4).
- Verizon DBIR 2026'ya göre zafiyet istismarı, %31 payla ihlallerde en yaygın ilk erişim yolu oldu.
- Öncelik, açığın puanına göre değil; açığın istismar edilip edilmediğine ve varlığın internete açık olup olmadığına göre belirlenir.
- Yamalanamayan sistemler (desteği bitmiş işletim sistemleri, PLC, SCADA) ağ ayrımı, erişim kısıtı ve izlemeyle korunur.
- "Dağıtıldı" ile "kuruldu" aynı şey değildir; her yama tarama ya da sürüm kontrolüyle doğrulanıp kayda geçirilmelidir.

## Yama yönetimi nedir, "güncellemeler otomatik" neden yetmez?

Çoğu işletmede yama, bilgisayarların kendi kendine güncellendiği varsayımına bırakılır. Oysa en riskli varlıklar genellikle otomatik güncellemenin dışında kalır: VPN ve güvenlik duvarı, uzak masaüstü sunucusu, ERP'nin çalıştığı eski sunucu, depo terminalleri, kameralar ve fabrika bilgisayarları. Bunlar "çalışıyor, dokunmayalım" denilerek aylarca, bazen yıllarca yamasız kalır.

Sorunun bir kısmı sahipsizliktir: yamayı kimin onaylayacağı, hangi gece uygulanacağı ve bir şey bozulursa kimin geri alacağı belli değildir. Diğer kısmı görünürlüktür. Envanteri olmayan bir işletme, hangi sürümün nerede çalıştığını bilmediği için yeni duyurulan bir açıktan etkilenip etkilenmediğini de söyleyemez.

ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün (NIST) [SP 800-40 Rev. 4 yayını](https://csrc.nist.gov/pubs/sp/800/40/r4/final) kurumsal yama yönetimini yamaların belirlenmesi, önceliklendirilmesi, edinilmesi, kurulması ve kurulumun doğrulanması olarak tanımlar ve yamalamayı önleyici bakımın bir parçası, işin olağan bir maliyeti olarak konumlar. Yani yama, bir BT iyiliği değil; bakım takvimi olan her makine gibi planlanması gereken bir iştir.

## Yamayı geciktirmek neden bu kadar riskli?

Yaması gecikmiş sistemler, saldırganların başlıca giriş kapılarından biri hâline geldi. [Verizon 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf) verisine göre zafiyet istismarı %31 ile ihlallerde en yaygın ilk erişim yolu oldu; önceki lider olan kimlik bilgisi kötüye kullanımı %13'e geriledi. Aynı raporda ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı'nın (CISA) Bilinen İstismar Edilen Zafiyetler (Known Exploited Vulnerabilities, KEV) kataloğundaki kritik açıkların 2025'te yalnızca %26'sı tamamen giderildi ve tam giderme için medyan süre 32 günden 43 güne uzadı.

> Avrupa Birliği Siber Güvenlik Ajansı'nın (ENISA) [ENISA Threat Landscape 2025](https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf) raporuna göre zafiyet istismarı %21,3 ile başlıca ilk sızma yollarından biri; yaygın kampanyalar açıkları duyurulmalarından günler içinde silaha dönüştürüyor.

Yama gecikmesindeki hız farkı burada netleşir: saldırgan günlerle, kurumlar haftalarla ölçülür. DBIR 2026'nın bir milyardan fazla anonim tespit kaydına dayanan analizine göre KEV zafiyetlerinin %60–70'i tespitten 7 gün sonra hâlâ açık kalıyor. [CISA'nın KEV kataloğunda](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) 24 Eylül 2026 itibarıyla 1.723 zafiyet listeleniyor ve liste sürekli büyüyor.

Gecikmenin sık görülen sonuçlarından biri fidye yazılımıdır. Sistemler şifrelendiğinde işi kurtaracak olan [fidye yazılımına karşı yedekleme düzeni](https://digitalbridge.com.tr/blog/fidye-yazilimi-yedekleme.html) ve [düzenli geri yükleme testi](https://digitalbridge.com.tr/blog/yedekleme-geri-yukleme-testi.html) olur; ama her iki önlem de yama yapılmayan kapıyı kapatmaz, yalnızca hasarı sınırlar.

Kişisel veri işleyen işletmeler için bir de mevzuat boyutu var. 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun (KVKK) 12. maddesi veri sorumlusuna uygun teknik ve idari tedbirleri alma yükümlülüğü getirir; bir ihlal yaşandığında ise Kurul kararıyla belirlenen [72 saatlik bildirim süresi](https://digitalbridge.com.tr/blog/kvkk-veri-ihlali-72-saat.html) işlemeye başlar. "Bilinen bir açık neden kapatılmadı?" sorusunu olaydan sonra yanıtlamak zordur.

## Yama yönetimi süreci nasıl işler? 7 adımlık uygulanabilir çerçeve

Yedi adımlık bu yama yönetimi çerçevesi, tam zamanlı güvenlik ekibi olmayan bir işletmenin de yürütebileceği biçimde sıralandı. Her adımın bir sorumlusu ve yazılı bir çıktısı olmalıdır.

1. **Varlık envanteri çıkarın.** Sunucular, bilgisayarlar, ağ cihazları, bulut hizmetleri, iş uygulamaları ve donanım yazılımı olan cihazlar; her birinin sürümü, sahibi ve internete açık olup olmadığı tek listede toplanır.
2. **Yama kaynaklarını takip edin.** Üretici güvenlik bültenleri, işletim sistemi güncelleme kanalları ve KEV kataloğu düzenli izlenir. Envanterle eşleşmeyen bülten, gürültüden ibarettir.
3. **Riske göre önceliklendirin.** Soru "açığın puanı kaç?" değil, "bu açık istismar ediliyor mu ve bizdeki varlık internete açık mı?" olmalıdır. CISA da Haziran 2026'da yayımladığı [BOD 26-04 direktifiyle](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) sabit süreler yerine varlığın açıklığına ve istismar riskine dayanan önceliklendirmeye geçti.
4. **Test edin.** Kritik iş uygulamalarında yama önce bir test makinesinde ya da küçük bir pilot grupta denenir. ERP, üretim yazılımı ve entegrasyonların yamadan sonra çalıştığı kontrol edilir.
5. **Bakım penceresinde dağıtın.** Dağıtım, işin en az etkilendiği zamana planlanır ve kullanıcılara önceden duyurulur. Yeniden başlatma gerektiren sunucular için sıra belirlenir.
6. **Geri dönüş planı hazırlayın.** Yamadan önce anlık görüntü ya da yedek alınır, geri alma adımları yazılır. Geri dönüş planı olmayan ekip, yamayı erteleme eğilimindedir.
7. **Kurulumu doğrulayın ve raporlayın.** "Dağıtıldı" ile "kuruldu" aynı şey değildir. [Zafiyet taraması](https://digitalbridge.com.tr/sozluk.html#vulnerability-scan) ya da sürüm kontrolüyle yamanın gerçekten uygulandığı doğrulanır; kapanmayan açıklar ve istisnalar gerekçesiyle kayda geçer.

### Hangi yama önce? Risk bazlı öncelik tablosu

| Varlık ve durum | Risk düzeyi | Önerilen yaklaşım |
|---|---|---|
| İnternete açık cihaz (VPN, güvenlik duvarı, e-posta sunucusu), açığı KEV kataloğunda | Çok yüksek | Acil değişiklik; günler içinde yama ya da geçici önlem |
| İnternete açık web uygulaması veya uzak erişim servisi | Yüksek | Bir sonraki kısa bakım penceresi, öncesinde hızlı test |
| İç ağdaki sunucular ve kritik iş uygulamaları | Orta–yüksek | Aylık döngü; test ortamında deneme şart |
| Çalışan bilgisayarları ve tarayıcılar | Orta | Otomatik güncelleme, uyumsuzluk için pilot grup |
| Üretim bilgisayarları, PLC, SCADA | Değişken | Üretici onayıyla bakım penceresinde; yamalanamıyorsa ağ ayrımı |
| Desteği bitmiş (güncelleme almayan) sistemler | Yüksek, kalıcı | Değiştirme ya da yalıtma planı; istisna kaydı |

Risk bazlı öncelik tablosunun mantığı basittir: aynı açık, internete açık bir cihazda iç ağdaki bir yazıcıdan çok daha tehlikelidir. Önceliklendirme bu yüzden varlık envanterine dayanır; envanter yoksa tablo da uygulanamaz.

## Yamalanamayan sistemler için ne yapılır?

Her sistem yamalanamaz. Fabrika bilgisayarları üretici onayı olmadan güncellenemez, desteği bitmiş bir işletim sistemi artık yama almaz, bazı cihazların donanım yazılımı ise hiç güncellenmez. Bu varlıklarda yama yerine telafi edici önlem uygulanır: ağ ayrımı, erişimin yalnızca gerekli kişilere açılması, izleme ve değişim planı.

Üretim tarafındaki telafi edici önlemleri [OT ve SCADA güvenliği yazımızda](https://digitalbridge.com.tr/blog/ot-guvenligi-scada.html) ayrıntılı anlattık; eski tezgâhları ağa bağlarken aynı riski [eski makineleri dijitalleştirme rehberinde](https://digitalbridge.com.tr/blog/eski-makineleri-dijitallestirme.html) ele aldık.

Sahaya yeni cihaz alırken ise uzaktan güncellenebilir olup olmadığını sorun; [IoT cihaz geliştirme sürecinde](https://digitalbridge.com.tr/blog/iot-cihaz-gelistirme-sureci.html) güncelleme yeteneğinin tasarım aşamasında ele alınması gerektiğini vurguluyoruz.

Ağ içinde her cihaza varsayılan güven tanımayan bir mimari ([sıfır güven](https://digitalbridge.com.tr/sozluk.html#zero-trust)), yamalanamayan sistemin etkisini de sınırlar. [Zero trust yaklaşımı](https://digitalbridge.com.tr/blog/zero-trust-nedir.html), yaması gecikmiş bir makinenin ele geçirilmesi hâlinde saldırganın ağda serbestçe dolaşmasını zorlaştırır.

## Yama yönetimi zafiyet taraması, sızma testi ve SIEM ile nasıl birleşir?

Yama yönetimi tek başına yaşayan bir süreç değildir. [Zafiyet taraması](https://digitalbridge.com.tr/blog/zafiyet-taramasi-nedir.html) hangi açığın nerede olduğunu gösterir, yama o açığı kapatır, [sızma testi](https://digitalbridge.com.tr/blog/sizma-testi-nedir.html) ise yamaların ve yapılandırmaların birlikte gerçekten dayanıklı olup olmadığını sınar. Üçü birbirinin alternatifi değil, aynı döngünün parçalarıdır.

Yama sürecinde izleme tarafı da önemlidir. Yamanın kurulduğu, başarısız olduğu ya da bir sistemin geri alındığı olaylar kayıt altında tutulmalıdır; [SIEM ve log yönetimi](https://digitalbridge.com.tr/blog/siem-log-yonetimi.html) bu kayıtları tek yerde toplar ve yaması eksik bir sisteme yönelik şüpheli trafiği görünür kılar. ISO 27001'e hazırlanan işletmeler için yama kayıtları, teknik zafiyet yönetimi kontrolünün en somut kanıtları arasındadır; ayrıntılar [ISO 27001 rehberimizde](https://digitalbridge.com.tr/blog/iso-27001-nedir.html).

Yama sıklığı ve sorumluluğu ayrıca tedarikçi sözleşmelerine de girmelidir. Sunucunuzu ya da yazılımınızı bir hizmet sağlayıcı işletiyorsa, kritik yamaların ne kadar sürede uygulanacağı ve nasıl raporlanacağı yazılı olmalıdır; aksi hâlde sorumluluk iki taraf arasında kaybolur. Bu hizmetleri dışarıdan alacaksanız firmayı nasıl seçeceğinizi [siber güvenlik firması seçimi](https://digitalbridge.com.tr/blog/siber-guvenlik-firmasi-secimi.html) rehberimizde anlattık.

## Digital Bridge yama yönetimini nasıl kuruyor?

Yama yönetimini hazır bir araç satarak değil, işletmenin gerçek altyapısını çıkararak kuruyoruz. [Siber güvenlik danışmanlığı](https://digitalbridge.com.tr/danismanlik/siber-guvenlik.html) kapsamında izlediğimiz yol şöyle:

- **Keşif ve envanter.** Sunucu, ağ cihazı, bulut hizmeti ve saha cihazlarını sahipleriyle birlikte listeliyor; internete açık olanları ve desteği bitmiş sistemleri ayrıca işaretliyoruz.
- **Zafiyet taraması ve önceliklendirme.** Envanteri tarayıp bulguları istismar durumu ve varlığın açıklığına göre sıralıyoruz; her bulgu için uygulanabilir düzeltme adımını yazıyoruz.
- **Pilot döngü.** İlk döngüde kritik birkaç sistemde test, dağıtım, geri dönüş ve doğrulama adımlarını birlikte uyguluyor, süreci ekibinizin yürütebileceği biçimde belgeliyoruz.
- **Altyapı kararları.** Yaması zorlaşan eski sunucular için taşıma ya da yenileme seçeneklerini [bulut geçiş ve altyapı danışmanlığı](https://digitalbridge.com.tr/danismanlik/bulut-gecis-altyapi-danismanligi.html) kapsamında değerlendiriyoruz; dosya sunucusu gibi iş yüklerinde [dosya sunucusundan buluta geçiş](https://digitalbridge.com.tr/blog/dosya-sunucusundan-buluta-gecis.html) seçeneği yama yükünü de azaltabilir.
- **Entegrasyonların korunması.** Yama sonrası bozulma riski en çok ERP, üretim ve muhasebe bağlantılarındadır; bu bağlantıları [sistem entegrasyonları](https://digitalbridge.com.tr/teknoloji-donanim/sistem-entegrasyonlari.html) deneyimimizle test planına dahil ediyoruz.
- **Uyum kanıtı.** Kişisel veri işleyen sistemlerde yama kayıtlarını, [KVKK uyum danışmanlığı](https://digitalbridge.com.tr/danismanlik/kvkk-uyum-danismanligi.html) kapsamında alınan teknik tedbirlerin belgesi olarak düzenliyoruz.

Kendi IoT cihazlarımızı ve endüstriyel yazılımlarımızı geliştirdiğimiz için fabrika bilgisayarları, PLC ve SCADA gibi yamalanması zor sistemlerde de üretimi durdurmadan çalışacak telafi önlemlerini planlayabiliyoruz.

## Sonraki adım

Başlamak için büyük bir proje gerekmez: bu hafta internete açık cihazlarınızı ve bunların sürümlerini listeleyin, ardından her birinin son ne zaman güncellendiğini yazın. Bu liste, ilk öncelik sıranızdır. Temel kontrollerin tamamını [KOBİ siber güvenlik kontrol listemizle](https://digitalbridge.com.tr/blog/kobi-siber-guvenlik-kontrol-listesi.html) gözden geçirebilir, diğer rehberler için [Siber Güvenlik ve KVKK konu sayfasına](https://digitalbridge.com.tr/blog/konu/guvenlik-kvkk.html) bakabilirsiniz.

Envanteri birlikte çıkarmak ve ilk yama döngüsünü kurmak isterseniz [iletişim sayfamızdan](https://digitalbridge.com.tr/iletisim.html) bize ulaşın; ihtiyaç analizinden sonra kapsamı ve aşamaları yazılı bir teklifle paylaşalım.

## Sık Sorulan Sorular

### Yama yönetimi ile zafiyet yönetimi aynı şey mi?

Hayır. Zafiyet yönetimi, açıkları bulma, değerlendirme ve kapatma döngüsünün tamamıdır; yama yönetimi ise bu döngünün güncellemeleri edinme, test etme, kurma ve doğrulama kısmıdır. Her açık yamayla kapanmaz: bazıları yapılandırma değişikliği, erişim kısıtı ya da sistemin değiştirilmesiyle giderilir. İki süreç aynı envantere ve öncelik listesine dayanmalıdır.

### Güvenlik yamaları ne sıklıkla uygulanmalı?

Tek bir süre herkese uymaz. İnternete açık cihazlarda aktif olarak istismar edilen açıklar günler içinde, iç ağdaki sunucular aylık bir döngüde, çalışan bilgisayarları otomatik güncellemeyle yamalanabilir. Önemli olan sürenin riske göre yazılı olarak belirlenmesi ve gerçekleşen sürelerin düzenli ölçülmesidir; ölçülmeyen hedef kısa sürede unutulur.

### Otomatik güncelleme açıksa ayrıca yama süreci gerekir mi?

Gerekir. Otomatik güncelleme genellikle çalışan bilgisayarlarını ve bazı uygulamaları kapsar; VPN, güvenlik duvarı, sunucu uygulamaları, ağ cihazları ve saha cihazları çoğu zaman dışında kalır. Ayrıca güncellemenin gerçekten kurulduğu doğrulanmazsa başarısız kurulumlar fark edilmez. Süreç, otomatik güncellemenin kapsamadığı yerleri ve doğrulamayı yönetmek içindir.

### Yama bir uygulamayı bozarsa ne yapılmalı?

Önceden hazırlanmış geri dönüş planı uygulanır: yama kaldırılır ya da yamadan önce alınan anlık görüntüye dönülür. Ardından sorun üreticiye bildirilir ve açık, yama yeniden denenene kadar ağ kısıtı gibi geçici bir önlemle korunur. Bu nedenle kritik sistemlerde yama önce test ortamında ya da küçük bir pilot grupta denenmelidir.

### Yama yönetimi maliyeti neye bağlıdır?

Maliyeti belirleyen başlıca etkenler varlık sayısı ve çeşitliliği, internete açık sistemlerin sayısı, desteği bitmiş ya da üretici onayı gerektiren cihazlar, test ortamı ihtiyacı ve kullanılacak dağıtım ile tarama araçlarıdır. İlk envanter ve pilot döngü en çok emeği ister; süreç oturduktan sonra aylık döngü büyük ölçüde rutin bir işe dönüşür.

### KEV kataloğu nedir, neden önemlidir?

KEV kataloğu, ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı'nın (CISA) gerçek saldırılarda istismar edildiği doğrulanan zafiyetleri listelediği herkese açık bir listedir. 24 Eylül 2026 itibarıyla katalogda 1.723 zafiyet bulunuyor. Bir açığın bu listede olması, teorik bir riskten değil, sahada kullanılan bir saldırı yolundan söz edildiğini gösterir; internete açık bir cihazdaki KEV açığı bu yüzden ilk sıraya alınmalıdır.

### Küçük bir işletme yama yönetimini nasıl yürütebilir?

Tam zamanlı bir güvenlik ekibi şart değildir. Güncel bir varlık listesi, sorumlusu belli bir aylık yama günü, internete açık cihazlar için acil yama kuralı ve kurulumun doğrulandığı basit bir kayıt çoğu küçük işletme için yeterli başlangıçtır. Yılda bir dış göz tarafından yapılan inceleme, gözden kaçan sistemleri ortaya çıkarır.