C#’ta Bellek Güvenliği Neden Şimdi Daha Önemli?
Bak şimdi, İşin aslı şu ki, C# tarafında unsafe kelimesi uzun zamandır ortada dürüyor ama çoğu ekip önü “gerekirse açarız” köşesine atıyordu. Ben de yıllardır böyle gördüm. Ta ki 2024 sonlarında bir finans müşterisinde, küçük bir performans iyileştirmesi için yazılmış birkaç satırlık pointer kodunun review’da kaçtığını görene kadar (ben de ilk duyduğumda şaşırmıştım). O gün anladım ki mesele sadece hız değil; mesele, bu hızın arkasındaki sorumluluğu görünür yapmak.
Microsoft’un yeni yaklaşımı da tam buraya dokunuyor (kendi tecrübem). Klasik anlamda “burada tehlikeli bölge var” demek yerine, artık “bu kodun üstlenmesi gereken güvenlik sözleşmesi var” diyor. Küçük gibi dürüyor, ama pratikte bayağı fark ediyor. Çünkü ekipler çoğu zaman (belki yanılıyorum ama) tehlikeyi biliyor; sorun, o bilginin kod içinde açıkça taşınmaması. Sonra hata review’dan sıyrılıyor.
Durun, bir saniye.
Doğrusu, Ben bunu ilk duyduğumda biraz şüpheyle yaklaştım. Hatta kendi kendime “yine mi dil tasarımında işim değişikliği?” dedim. Sonra.NET 11 Preview ile gelen erken derleyici davranışını görünce fikrim değişti. Bu kozmetik bir dokunuş değil; güvenlik sınırlarını compiler seviyesinde daha sert çizme çabası.
Eski model neden yetmiyordu?
C# 1.0’daki unsafe yaklaşımı temelde şunu söylüyordu: “Burada pointer kullanacaksan dikkat et.” Güzel, net, kısa. Ama iş sahaya gelince — kendi adıma konuşayım — yetmedi; çünkü işaretlenen şey çoğu zaman sadece syntax’tı. Yanı metodun gövdesi ya da tipi unsafe oluyordu ama çağıran taraf neye bulaştığını neredeyse her zaman açıkça görmüyordu (eh, fena değil)
2019’da bir lojistik firmasının İstanbul ofisinde buna benzer bir durum yaşadık. Sistem eski bir native kütüphaneyle konuşuyordu ve araya birkaç Marshal çağrısı girmişti (bu konuda ikircikliyim). Kod çalışıyordu, evet. Ama code review sırasında kimse “bu satırın yanında hangi güvenlik borcu var?” sorusunu sormuyordu. Sonuç? Küçük görünen bir refactor, testlerde yakalanmayan bir bellek erişim hatası doğurdu.
Hmm, bunu nasıl anlatsamdı…
Bir de şu var: Unsafe API’ler yalnızca pointer ile sınırlı değil artık; runtime kütüphanelerindeki bazı yardımcılar da aynı dikkatle ele alınıyor. Bana bu doğru geliyor çünkü gerçek dünyada risk tek biçimli olmuyor. Bazen pointer görüyorsunuz, bazen array sınırı dışına taşan marjinal bir kullanım, bazen de interop katmanında sessizce dolaşan bir hata…
Koddan çok sözleşme konuşuluyor
Yeni modelde unsafe, sadece “yasak bölge” etiketi değil; doğrulanamayan ama yine de mecburen kabul ettiğiniz bir sözleşme gibi davranıyor. Yanı geliştirici olarak sizden beklenen şey daha net: Bu bloğun neden güvenli olduğunu açıklayın, yoksa compiler sizi rahat bırakmasın.
Şimdi gelelim işin can alıcı noktasına.
Bence burada asıl kazanım görünürlük (ben de ilk duyduğumda şaşırmıştım). Kurumsal tarafta en büyük problemimiz çoğu zaman kötü kod değil; açıklanmamış varsayımlar oluyor. Kod inceleyen ekip başka şey düşünüyor, yazan ekip başka şey varsayıyor… Sonra üretimde sürpriz çıkıyor. Yeni yaklaşım bu sürprizi azaltmaya aday.
.NET ekosistemine etkisi ne olacak?
.NET 11’de preview olarak gelmesi bana yerinde geliyor. Çünkü büyük kurumsal yapılarda böyle değişiklikleri önce kontrollü denersiniz; sonra template’lere koyarsınız; sonra yavaş yavaş standart hâle getirirsiniz. Zaten nullable reference types’ta da benzer yolu izledik (evet, doğru duydunuz). Açık söyleyeyim, başta herkes homurdandı ama sonra ciddi faydasını gördü.
Küçük startup’larda işe tablo farklı olabilir. Eğer takımınız üç kişiden oluşuyorsa ve native interop ile uğraşmıyorsanız bu değişiklik size hemen dokunmayabilir bile. Ama enterprise ölçekteyseniz? Orada iş değişiyor. Hele bir de finans, savunma, sağlık gibi alanlarda güvenlik sözleşmesinin compiler tarafından zorlanması bayağı kıymetli.
Yeni yaklaşım sahada ne kazandırıyor?
Açık konuşayım: Her şeyi otomatik çözmüyor. Hatta öyle beklerseniz hayal kırıklığı olurdu zaten. Çünkü memory safety sadece dil meselesi değil; mimarı meselesi de var, operasyon meselesi de var, test stratejisi meselesi de var.
Yine de avantajları net görünüyor. Birincisi, review süreci daha dürüst hâle geliyor. İkincisi, supply chain ve engineering policy tarafında somut kontrol noktaları oluşuyor. Üçüncüsü —ve bence en önemlisi— AI destekli kod üretimi arttıkça insan gözünün kaçırabileceği riskler compiler seviyesinde biraz daha baskılanıyor.
Kod güvenliği artık yalnızca “iyi niyetli geliştirici disiplini”ne bırakılamaz; derleyicinin de elini taşın altına koyması gerekiyor.
| Konu | Eski yaklaşım | Yeni yaklaşım |
|---|---|---|
| Kapsam | Sadece syntax odaklı | Sözleşme odaklı |
| Review görünürlüğü | Düşük/orta | Daha yüksek |
| Ekip disiplini ihtiyacı | Tamamen insana bağlı | Kısmen compiler destekli |
| Maliyet etkisi | Kısa vadede düşük | Migrasyon maliyeti olabilir |
| Kurumsal uyum | Zor takip edilir | Daha denetlenebilir |
Bütçe ve benimsenme açısından bakınca…
Hani, E tabi burada maliyet boyutu da var. Türkiye’de birçok şirket için mesele yalnızca teknik doğruluk değil; aynı zamanda ekip zamanı ve dönüşüm maliyeti oluyor — itiraf edeyim, beklentimin üstündeydi —. Azure’da nasıl ki bazen pahalı servisin yerine daha sade bir seçenek öneriyorsak, burada da her projeye hemen yeni modeli açmak yerine önce riskli modüllerden başlamak mantıklı olabilir. Bu konuyla ilgili MSVC Build Tools Preview Mayıs 2026: Derleyicide Sessiz Ama Kritik Güncellemeler yazımıza da göz atmanızı tavsiye ederim.
Büyük kurumlarda önerim şu olurdu: Önce interop kullanan servisleri bulun, sonra bu alanlarda yeni safety modelini pilot yapın (mesela bankacılık ödeme entegrasyonları veya cihaz sürücüsüyle konuşan servisler). Küçük ekiplerdeyse doğrudan tüm solution’a yaymak yerine can alıcı assembly’lerle başlamak daha akıllıca. Daha fazla bilgi için Gemini 3.5 Flash Copilot’ta: Hız, Maliyet ve Gerçek Etki yazımıza bakabilirsiniz. Prompt Injection’ı Durdurmak: Agent Framework’te FIDES yazımızda bu konuya da değinmiştik.
Sahada nasıl uygulanır?
Bakın, Neyse uzatmayalım… Denemek istiyorsanız ilk iş mevcut unsafe kullanımınızı çıkarın muhtemelen tablo sandığınızdan biraz kalabalık çıkacak diye tahmin ediyorum bugünkü pratikte ben genelde önce repo içinde tarama yapıyorum: pointer geçen yerler nereler, Marshal nerede kullanılıyor, System.Runtime.CompilerServices.Unsafe kaç yerde dönüyor? Bu liste çıktıktan sonra işler berraklaşıyor.
// Basit tarama fikri
grep -R "unsafe\|Marshal\|System.Runtime.CompilerServices.Unsafe".
Bundan sonra iki yolunuz var: Ya mevcut kullanımınızı olduğu gibi bırakıp yeni modelin üstüne geçiş planı yaparsınız ya da kritik parçaları yeniden düzenlersiniz. İkinci yol daha zahmetli ama uzun vadede temiz sonuç veriyor.
Benim önerim şu üç adımla başlamak:
- Tüm unsafe bölgeleri envanter hâline getirin.
- Bunları risk seviyesine göre sınıflandırın: düşük, orta, yüksek.
- Önce yüksek risklileri kapatın ya da çevreleyin.
- Sona kalan parçalar için code review checklist hazırlayın.
- Mümkünse CI içinde uyarı kapıları kurun.
Kendi yaptığım hatadan çıkan ders
2025’in Mart ayında Logosoft’ta yürüttüğümüz bir kurumsal migration projesinde benzer bir hata yaptık diyebilirim — iyi niyetle yapılan optimizasyonlardan biri production öncesi testte sorun çıkardı çünkü boundary check beklentisi yanlış kurulmuştu (ben de ilk duyduğumda şaşırmıştım). Hata mesajı ilk bakışta — kendi adıma konuşayım — anlamsızdı ama kök sebep basitti: kod güvenliydi sanıyorduk, meğer değildi (bizzat test ettim). Çözümü işe oldukça düz öldü; ilgili bloğu daraltıp etrafına net kontrat ekledik ve tekrar etmeyen hâle getirdik.
Türkiye’de kurumsal tarafta ne anlama geliyor?Bunu Türkiye’deki şirketler açısından değerlendirirsek… Bizde çoğu zaman performans baskısı güvenlikten hızlı geliyor; özellikle eski sistemlerde “çalışıyorsa dokunma” kültürü hâlâ güçlüdür. Ama memory safety konusu tam da bu alışkanlığı sorgulatıyor çünkü üretimde çıkan bellek kaynaklı hata hem maddi zarar veriyor hem itibar yiyor hem de kriz yönetimini yoruyor. Yanı iş sadece teknik borç değil; direkt operasyonel risk!
Açık konuşayım, enterprise müşterilerde bu tip yeniliklerin benimsenmesi startup’a göre yavaş olur ama etkisi daha kalıcıdır. Çünkü change management vardır, CAB vardır, security approval vardır… Fakat onay geçtikten sonra standartlaşma gücü çok yüksektir (şaşırtıcı ama gerçek). Küçük ekiplerde işe karar hızlı alınır ama disiplin zayıf kalabilir; o yüzden orada tooling desteği şarttır (buna dikkat edin)
Hani,.NET 11 Preview dört gibi ara sürümlerde deneme yapmak bana hep mantıklı geldi.AZ-305 sınavına hazırlanırken bile şunu tekrar tekrar gördüm: mimarı kararların değeri ancak sınırlamalarla birlikte anlaşılır.Bellek güvenliği de öyle.Sadece feature listesi olarak okumayın; operasyonel karşılığını düşünün.
Şuna dikkat: eksikler ve sınırlarBeni en çok heyecanlandıran kısım kadar rahatsız eden tarafı da var: Mesela migrasyon hikâyesi kağıt üstünde düzgün dursa da eski kod tabanlarında can sıkıcı sürtünmeler çıkacak.Mesela üçüncü parti paketlerle çalışan sistemlerde her şey sizin kontrolünüzde olmuyor.Bu yüzden yeni modelin güzel olması yetmez; araç zinciri uyumu da lazım.
Buna rağmen biraz temkinliyim: Çünkü her geliştirici bellek güvenliği sözleşmesini aynı ciddiyetle okumaz. İşte burada eğitim devreye giriyor. Sadece derleyiciye yaslanırsanız yarım kalır; ekibin — ki bu tartışılır — neyi neden yaptığını bilmesi gerekiyor. Yoksa yeni etiket eskisinin üstüne yapıştırılmış olur, hepsi bu.
Sıkça Sorulan Sorular
C#’ta yeni unsafe modeli neyi değiştiriyor?
Kendi deneyimimden konuşuyorum, Aslında iletilen mesaj artık çok daha net: Unsafe kullanım sadece bir syntax meselesi değil, yanı bir sözleşme olarak görülüyor. Derleyici de bu sözleşmenin dışına çıkılmasını eskiye göre çok daha sıkı takip ediyor.
.NET 11’de hemen zorunlu mu olacak?
Hayır, ilk etapta opt-in bekleniyor. Yanı sız açmadan mevcut projeleriniz sessizce değişmiyor, merak etmeyin.
Küçük projelerde buna geçmek mantıklı mı?
Eğer zaten unsafe kullanmıyorsanız büyük ihtimalle doğrudan etkilenmeyeceksiniz. Ama bence ileride büyüme planınız varsa, erken deneme yapmak hiç fena bir fikir değil — tecrübeme göre bu tür şeyleri erken görmek sonradan çok işe yarıyor.
Bellek güvenliği performansı düşürür mü?
Zorunlu olarak düşürmüyor, hani bazı kontroller ekstra maliyet getirebilir elbette. Ama açıkçası çoğu senaryoda kazanç, kaybından oldukça büyük oluyor.
Kaynaklar ve İleri Okuma
- Microsoft.NET Blog — Improving C# Memory Safety
- Microsoft Learn — unsafe keyword documentation
- Microsoft Learn -.NET Garbage Collection overview
- Azure IaaS’te Savunma Katmanları: Güvenlik Nasıl Oturuyor?
- PowerShell Paketlerini Güvenli Yönetmek: PSResourceGet’te Yeni Dönem
- .NET ve.NET Framework Mayıs 2026 Güncellemeleri: Ne Değişti?
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder