Başlangıçta Bir Sessizlik: Daha Az Uyarı Gerçekten Daha Güvenli mi?
Şöyle bir şey var; geçen sene, yani 2025’in ortalarında GitHub’daki güvenlik bildirimi sayısı birden dip yaptı. Rakam da net: 4.101 incelemeli uyarı. Son dört yılın en düşüğü, hem de açık ara. İlk başta kulağa mis gibi geliyor tabii—sanki bir sabah kalkıp “Hah, açık kaynak artık neredeyse tertemiz!” diyebiliriz. Ama öyle kolay atlamayın; grafik aşağı indiği zaman her daim bir pürüz çıkıyor ya… Bak, ben defalarca yaşadım bunu.
2019’da kendi sunucu altyapımı elden geçirirken benzerini yaşamıştım. Zafiyet raporu azaldı diye sevindim—meğer script takla atmış! Yani tabloya bakıp “Sorunlar bitti!” demek bence fazla saflık olur.
Peki neden böyle? Aslında cevabı karmaşık değil: Eski tip açıkların çoğu. Elekten geçmiş durumda, GitHub’ın arşivinde incelenecek neredeyse yeni kalmadı. Az bildirim görmek = riskin bitmesi demek değildir yani.
Kuyunun Dibine Varmak: Bildirimler ve Eski Güvenlik Açıkları Nerede?
Kendi kurumsal işlerde özellikle finans projelerinde eski zafiyetlerin sinsiliğini çok gördüm. Düşün: 10 yıllık yazılımların arasında öyle kadim paketler dönüyor ki Dependabot şaşkına döner… Aynen burada olduğu gibi:
- Eski açıklardan geriye minik dünya dışı paketler kaldı. Büyük kısmını daha önce incelediler, kalanlar işe genellikle kenarda köşede duran library’lerden ibaret.
- Yeni bulunan açıklara gelince %19 artış var. Yani sistem eskisi kadar güvenli değil, sadece eski dosyaların tükendiği yerdeyiz aslında!
Dönemsel Dalgalanmalar Bize Ne Öğretiyor?
Bazen bazı seneler hiç beklenmeyen yerden fırlama gelir… 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. GitHub Credential Revocation API ile Sızıntılara Anında Fren: Yeni Destekler ve Gerçek Hayat Senaryoları yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Graph API ile E-posta İçeriği Artık O Kadar Esnek Değil: Neler Değişiyor, Kimler Dikkat Etmeli? yazımıza bakabilirsiniz.
Neden Go Bu Sene Ön Planda?
Sebebi oldukça net ve teknik ekiplerin genellikle gözünden kaçan cinsten; GitHub ekibi iç taramada bugüne dek kimsenin yüzüne bakmadığı Go paketlerini özel olarak taradı ve topluca advisory bastılar. Dolayısıyla istatistiklerde kayma oluştu.
Ama diğer diller hâlâ riskte — Python veya JavaScript’i yok saymak tam hata olur! (en azından benim deneyimim böyle) Bu konuyla ilgili Mart 2026 Azure SDK Güncellemeleri: Sürprizler, Detaylar ve Gerçek Hayat Yansımaları yazımıza da göz atmanızı tavsiye ederim.
“Güvenlik açığı bildirimi azaldığında ilk işim veri kapsamını sorgulamak olur—sadece grafiklere odaklanırsan yanılırsın.”
– Sen Aşkın KILIÇ
CWE Tablosu Üzerinden Gerçek Hayat Okumaları
| # | CWE Tipi | Açık Sayısı (2025) | Birkaç Değişiklik* |
|---|---|---|---|
| 1 | CWE-79 (XSS) |
672 | = |
| 2 | CWE-22 (Path Traversal) |
214 | ↑ |
| 3 | CWE-863 (Incorrect Authorization) |
169 | ↑↑ |
| 4 | CWE-20 (Improper Input Validation) |
154 | ↑ |
| 5 | CWE-200 (Info Exposure) |
145 | ↓ |
| * Ok yönü önceki seneye göre yer değişimini gösteriyor. | |||
XSS zirvede mi hâlâ? Evet! O kadar yaygın ki insan şaşırıyor… Geçen hafta GitHub Actions güvenliği makalemde de bahsetmiştim;, XSS zaafları bitmiyor—hep biri formda kalmayı başarıyor resmen! Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak: Hayal Kırıklığı mı, Gerçekçi Bir Mimarı mi? yazımızda bu konuya da değinmiştik.
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, ciddi yetki karmaşası 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! - Bazı tipler pratikte hayli can sıkıcı oldu; ö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 startuplarla devasa kurum arasındaki fark burada ortaya çıkıyor: Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek yazımızda bu konuya da değinmiştik.
- 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 tabii 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’ 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çek anlamda 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 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 kullanışlı 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 halde 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?
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!
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…
(agentic workflow ayarlarını izlemek üzerine mini rehberime göz atabilirsiniz.).
Kısaca hayır! İncelenen açık sayısının azalmasının nedeni eski vakaların tükenmiş olmasıdır. Yeni açıklarda aslında artış var.
Neden özellikle Go dili bildirilerde öne çıktı?
Sebebi Github ekibinin eksik kalan Go paketlerinde özel kampanya yapmasıydı—otomatik farkındalık arttığı için oransal sıçrama görüldü.
XSS neden hâlâ listenin zirvesinde yer alıyor?
XSS aşırı yaygın ve çoğu zaman basit hatalar sonucu ortaya çıkan klasik zafiyet türüdür—form inputlarından admin paneline kadar türlü yerde karşımıza çıkabiliyor maalesef.
Tüm advisories eşit derecede önemli midir? Hangilerine öncelik vermeli?
Tümü acil değildir—EPSS skoru düşük olanları bekletebilirsiniz ama yüksek riske sahip olanlara öncelik vermelisiniz; pratikte kaynak yönetiminizde büyük avantaj sağlar.
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?
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder