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ı 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 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 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 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 ve düzenli geri yükleme testi 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 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.
- 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.
- 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.
- 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 sabit süreler yerine varlığın açıklığına ve istismar riskine dayanan önceliklendirmeye geçti.
- 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.
- 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.
- 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.
- Kurulumu doğrulayın ve raporlayın. "Dağıtıldı" ile "kuruldu" aynı şey değildir. Zafiyet taraması 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 ayrıntılı anlattık; eski tezgâhları ağa bağlarken aynı riski eski makineleri dijitalleştirme rehberinde ele aldık.
Sahaya yeni cihaz alırken ise uzaktan güncellenebilir olup olmadığını sorun; IoT cihaz geliştirme sürecinde 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), yamalanamayan sistemin etkisini de sınırlar. Zero trust yaklaşımı, 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ı hangi açığın nerede olduğunu gösterir, yama o açığı kapatır, sızma testi 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 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.
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 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ığı 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ığı kapsamında değerlendiriyoruz; dosya sunucusu gibi iş yüklerinde dosya sunucusundan buluta geçiş 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ı deneyimimizle test planına dahil ediyoruz.
- Uyum kanıtı. Kişisel veri işleyen sistemlerde yama kayıtlarını, KVKK uyum danışmanlığı 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 gözden geçirebilir, diğer rehberler için Siber Güvenlik ve KVKK konu sayfasına bakabilirsiniz.
Envanteri birlikte çıkarmak ve ilk yama döngüsünü kurmak isterseniz iletişim sayfamızdan bize ulaşın; ihtiyaç analizinden sonra kapsamı ve aşamaları yazılı bir teklifle paylaşalım.