Açık Kaynak Güvenlik Açıkları: 2025’te Neler Değişti, Ne Anlama Geliyor?
Başlangıçta Bir Sessizlik: Daha Az Uyarı Gerçekten Daha Güvenli mi?
Şöyle bir durum var; geçen sene, yani 2025’in ortalarında, GitHub’daki güvenlik bildirimi sayısı bir anda aşağı indi. Rakam da net: 4.101 incelemeli uyarı. Son dört yılın en düşüğü, hem de açık ara. İlk bakışta insanın aklına “Demek ki her şey toparlandı” fikri geliyor, ama dur bir saniye — grafik aşağı inince genelde işin içinde başka bir hikâye de çıkıyor. Bak, ben bunu defalarca gördüm.
2019’da kendi sunucu altyapımı elden geçirirken benzer bir şey yaşamıştım. Zafiyet raporu azaldı diye sevindim; meğer script sapıtmış! Yani tabloya bakıp “Sorunlar bitti” demek bana fazla iyimser geliyor.
Açıkçası, Peki neden? Aslında cevap çok dolambaçlı değil: Eski tip açıkların çoğu. Ayıklanmış durumda, GitHub’ın arşivinde incelenecek yeni malzeme iyice azalmış. Az bildirim görmek = riskin bitmesi demek değil, işin aslı bu.
Kuyunun Dibine Varmak: Bildirimler ve Eski Güvenlik Açıkları Nerede?
Aslında, Kendi kurumsal işlerde, özellikle finans projelerinde eski zafiyetlerin ne kadar inatçı olduğunu çok gördüm (ciddiyim). Düşün; 10 yıllık yazılımların arasında öyle kadim paketler dönüyor ki Dependabot bile bir an durup bakıyor… Aynen burada olduğu gibi:
- Eski açıklardan geriye küçük ve biraz tuhaf paketler kaldı. Büyük kısmını daha önce incelemişler, kalanlar da genelde köşede kalmış library’lerden ibaret.
- Yeni bulunan açıklara gelince %19 artış var. Yani sistem eskisi kadar temiz değil; sadece eski dosyaların sonuna yaklaşmış durumdayız.
Dönemsel Dalgalanmalar Bize Ne Öğretiyor?
Bazen bazı seneler beklenmedik yerden sıçrama geliyor… 2025’te Go dilinin ekstra öne çıkması mesela! Golang’de çalışırken üçüncü parti modüllerin dokümantasyonunda eksiklik sık yaşanıyor — Mart ayında Logosoft’taki bir müşteri için Go bağımlılıklarını tararken üç ayrı potansiyel açık bulduk, üstelik hepsi sandığımdan daha derindi. Daha fazla bilgi için
Denge Bozan Zayıflıklar Hangileri?
- CWE-863 (“Yanlış Yetkilendirme”) hızla yükseldi çünkü teknik sınıflama değişti (CWE-284’ten kaydı). Detay deyip geçmeyin — geçen yıl bankanın Kubernetes ortamında test ettik, yetki tarafında ciddi karışıklık vardı!
- Sürekli gündeme gelen konular arasında resource exhaustion (CWE-400 & CWE-770) ile unsafe deserialization (CWE-502) var.
Geçen yıl biri bana “Node.js’de deserialize edilen JSON’a dikkat et” dediğinde pek kulak asmadım… Meğer haklıymış adam! — bunu es geçmeyin - Bazı tipler pratikte baya can sıkıcı şekilde yükseldi; örneğin server-side request forgery geçmişte pentest raporlarında nadiren görünürdü ama şimdi ilk ondayız!
Maliyet-Yarar Dengesi Nereye Evriliyor?
Bak şimdi, müşterilere her seferinde şunu söylüyorum: “Yamaya harcadığın süre kadar maliyet yönetirsin.” Küçük startup ile devasa kurum arasındaki fark tam burada ortaya çıkıyor;
- Küçük ekipler genelde dependabot alertleri azaldığında rahatlayıp eskiye takılmaz.
Geçen ay Bodrum’daki girişimci arkadaşım bana sordu — “Abi niye CVE kovalıyoruz?” Çünkü orada SLA düşük, risk iştahı yüksek. - Kurumlarda işler böyle yürümüyor.
Regülasyona tabi sektörlerde — örneğin banka ya da sağlık — eski advisory’i atlamak direkt ceza kesilebiliyor.
Bir kamu projesinde eski MySQL paketi yüzünden canlıya çıkamamıştık; danışmanlık saatlerinin yarısı bu tip “gözden kaçan klasiklere”a gidiyor resmen! - Ara çözüm isteyenlere önerim:
oss-review toolkit + GitHub Advisory API + otomatik Slack/Teams bot = minimum el emeğiyle maksimum farkındalık. - Daha büyük yapılarda FinOps gözüyle bakmazsan ROI’yi öldürmek mümkün;
her ‘security ticket’ için anında yama yapmak bazen gereksiz pahalıya patlıyor… Oraya dikkat!
Zafiyet Yönetimine Yeni Bakış Açısı Lazım mı?
Bazen aklımdan geçiyor… Onca advisory’nın hangisi gerçekten kritik? Hangisi ortamınızı tehdit ediyor?
Şimdi hemen panik yapınca olan şu:
“CVE geldi mi alarm çal!” kafası hâkim.
Ama benim deneyimlerimde şunu gördüm — hepsi o kadar acil değil!
Son dönemde EPSS skoru denen sistem baya popüler oldu zaten.
Karmaşık matematik falan sanmayın;
Basitçe söyleyeyim:
EPSS = Açığın suistimal edilme ihtimali puanı (“exploit probability score”)
ve çoğunlukla CVSS skorundan daha işe yarar olabiliyor!
Şöyle örnek vereyim:
Azure’daki container imajlarımızdan biri için CVE alarmı geldiğinde
ilk iş EPSS’ye baktık — “Bu zayıflığın istismar oranı %0.05.”
Ekip bir rahatladı…
Aksi hâlde herkes paniklemiş olacaktı!
Hâliyle ağırlıklı risk yaklaşımıyla ilerlemek gerek…
API throttling ya da review scope daralması gibi teknik sebepler olabilir.
Loglara bakmadan rehavete kapılmayın!
Detaylar için GitHub Pull Request Dashboard Yeniliği yazımı okuyabilirsiniz..
Ters Köşe Sorular & Pratik İpuçlarıyla Sonuçlarım:
- Açık kaynakta gerçekten “düşüş” varsa nedeni metodoloji değişimi ya da verinin doygunluğa ulaşmasıdır – bunu aklınızdan çıkarmazsanız yol alırsınız!
- Aynı CWE tipi sürekli yükseliyorsa normal değil – burada ekosistemde trend kırılması vardır (örneğin authorization zaafının re-classification ile yukarı fırlaması).
- Zaman zaman dependency zincirinizi rastgele seçilmiş iki eski projede test edin – ‘Kör nokta kalmış mı?’ analizi ciddi işe yarıyor!
Geçen yıl Antalya’daki Azure Bootcamp’te buna katılanlara yaptırdığımda herkes dumura uğradı…
Hiç radarımızda olmayan NodeJS paketi ortalığı karıştırdı resmen! - Eko-sisteme uygun araç kombinasyonu şart:
Tek başına Dependabot yeter sanmayın;
Mesela Snyk veya Trivy ile manual scan yaparsanız beklenmedik sürprizlerle karşılaşmanız gayet muhtemel… - Mümkünse yılda iki kez “incelenmemiş advisories listesi” çıkarıp eko-sisteminize çapraz kontrol uygulayın – risksiz görünen repo bile bazen bomba taşıyor olabiliyor.
- Daha detaylı workflow optimizasyonları peşindeyseniz
(agentic workflow ayarlarını izlemek üzerine mini rehberime göz atabilirsiniz.).
Sıkça Sorulan Sorular
Açıklardaki azalma sistemlerin daha güvenilir olduğu anlamına mı geliyor?
Kısaca hayır! Aslında eski vakaların tükenmesiyle sayı düşüyor gibi görünüyor—ama yeni açıklarda tam tersine bir artış var.
Bunu biraz açayım.
Neden özellikle Go dili bildirilerde öne çıktı?
Bence bunun arkasında ilginç bir sebep var: Github ekibi eksik Go paketleri için özel bir kampanya yürütüyordu—yani otomatik farkındalık arttı, oransal sıçrama da o yüzden ortaya çıktı (ki bu çoğu kişinin gözünden kaçıyor)
XSS neden hâlâ listenin zirvesinde yer alıyor?
Açıkçası XSS o kadar yaygın ki şaşırmamak lazım. Çoğu zaman basit hatalardan kaynaklanıyor—mesela form inputlarından admin paneline kadar her yerde karşınıza çıkabiliyor, tecrübeme göre de en çok göz ardı edilen zafiyet türlerinden biri.
Tüm advisories eşit derecede önemli midir? Hangilerine öncelik vermeli?
Hepsi yangın değil yani—EPSS skoru düşük olanları biraz bekletebilirsiniz, ama yüksek riskli olanlar gerçekten acil. Bence bu ayrımı iyi yapmak, kaynak yönetiminde ciddi avantaj sağlıyor.
Kaynaklar ve İleri Okuma
- GitHub Resmî Blog Yazısı – Open Source Vulnerability Trends 2025
- GitHub Advisory Database – Güncel Tüm Advisories Listesi
- Microsoft Software Supply Chain Security Guide
- Dilerseniz ilgili diğer içeriklerime bakabilirsiniz:
→ GitHub Actions 2026 Güvenlik Yol Haritası: Sırada Bizi Neler Bekliyor?
→ Merge Çakışmalarında Copilot Devrimi Nasıl İşledi?
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.
