Geçen hafta bir müşteride tam da şu soruyla karşılaştık: “Default branch dışındaki korumalı dallar niye görünmüyor?” İşin aslı şu ki, güvenlik raporlarında tek dalı baz almak bazen insanı fena halde yanıltıyor. CodeQL tarafında gelen bu güncelleme de tam o boşluğu kapatıyor; artık pull request insights ekranı sadece ana dalın değil, tüm protected branches’in yükünü görüyor.
Ben bu tip metrik işlerinde hep şuna bakarım: sayı güzel mi, yoksa gerçekten işe yarıyor mu? AZ-500. AZ-305 hazırlıklarında da aynı kafa yapısı vardı bende; rakamlar tek başına hiçbir şey anlatmaz, bağlam lazım. GitHub’ın burada yaptığı şey de bayağı net: Autofix’in etkisini daha dürüst göstermeye başlamışlar. Kulağa küçük bir değişiklik gibi geliyor ama pratikte özellikle enterprise yapılarda etkisi büyük.
Peki neden?
Asıl Değişen Ne?
Önceden CodeQL pull requests insights sekmesi, Copilot Autofix. Alert istatistiklerini ağırlıklı olarak default branch üzerinden topluyordu. Yani depo içinde birkaç korumalı dalınız varsa, ama rapor tek bir dalı merkeze alıyorsa, çıkan tablo biraz eksik kalıyordu. Bu ne anlama geliyor? Şimdi işe dokuz insight kutucuğunun tamamı ve indirilebilir CSV dosyası, tüm protected branches’ten veri çekiyor.
Bu ne demek? Mesela bir organizasyonda release/1.x, release/2.x. Main ayrı ayrı korunuyorsa; artık yalnızca main’de çözülen uyarıları değil, diğer korumalı dallardaki düzeltmeleri de görüyorsunuz. Açık konuşayım, bu benim hoşuma giden bir yaklaşım. Çünkü güvenlik ekibiyle geliştirici ekibinin aynı sayfada olması için raporun “yarım doğru” vermemesi gerekiyor.
Bir dakika — bununla bitmedi.
Bir de şu var: geçmiş veriler retroaktif olarak güncellenebiliyor. Yani bugün açtığınız dashboard’da sayıların geçen aya göre zıpladığını görebilirsiniz. İlk anda “bir şey mi bozuldu?” diyorsunuz… sonra anlıyorsunuz ki aslında önceki rapor eksikmiş. Bir bankacılık projesinde 2024 sonunda benzer bir durum yaşamıştık; staging ve hotfix branch’leri dışarıda kalınca remediation oranı olduğundan düşük görünüyordu. Sonradan veri kapsamını genişletince yönetime verdiğimiz sunum bile değişti, cidden.
| Durum | Eski yaklaşım | Yeni yaklaşım |
|---|---|---|
| Kapsam | Sadece default branch | Tüm protected branches |
| Metrik doğruluğu | Kısmi görünüm | Daha temsil edici görünüm |
| Autofix etkisi | Bazen düşük görünürdü | Daha gerçekçi yansır |
Neden Önemli? Çünkü Güvenlikte Eksik Veri Pahalıdır
Security overview ekranına bakıp “Autofix pek kullanılmıyor galiba” demek kolaydı. Ama gerçek öyle değildi; başka korumalı dallarda yapılan düzeltmeler sayıya girmeyince tablo sönük görünüyordu (kendi tecrübem). E peki, sonuç ne oldu? Gel gelelim şimdi durum değişiyor: daha yüksek ama daha temsil edici sayılar görüyorsunuz.
Ne yalan söyleyeyim, Bunu günlük hayattan şöyle düşünün: evde üç oda var ama siz sadece salondaki ışığı ölçüp “ev loş” diyorsunuz. Oysa mutfak full açık, çalışma odasında da projektör var. Raporlama da biraz böyle işte. Tahmin eder mısınız? Tek oda yerine bütün evi görmek lazım.
Hmm, bunu nasıl anlatsamdı… Bu konuyla ilgili GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü? yazımıza da göz atmanızı tavsiye ederim.
Ben Logosoft tarafında bazı kurumsal Azure ve DevOps projelerinde bunu defalarca gördüm; özellikle çoklu repo ya da uzun yaşayan branch stratejilerinde yanlış metrikler kararları bozuyor. Mesela 2025 yazında bir telekom müşterisinde security KPI’ları incelerken main branch merkezli bakış yüzünden ekiplerin yaptığı işi hafife aldığımız oldu. Sonra protected branch kapsamını genişlettik (ben de ilk duyduğumda şaşırmıştım). tahmin edin ne oldu? Remediation hızı bir anda “bayağı iyiymiş” seviyesine çıktı (ben de ilk duyduğumda şaşırmıştım)
CodeQL tarafındaki bu değişiklik aslında sadece sayı büyütmüyor; karar kalitesini düzeltiyor. Güvenlikte yanlış düşük görünen metrikler bazen en pahalı hatadır.
Küçük Takımda Başka, Enterprise’da Başka Etki Yaratır
Küçük startup senaryosu
Küçük ekiplerde genelde branch yapısı sade olur. Main var, belki develop var, o kadar. Böyle yerlerde bu güncelleme ilk bakışta “eh tamam” dedirtebilir. Ama yine de faydalı; çünkü gelecekte büyüdüğünüzde elinizde düzgün alışkanlık kalır. Ben buna yatırım gibi bakıyorum.
Ekip küçük olsa bile CSV export’un tüm protected branches’i kapsaması iyi oluyor. En çok da demo sırasında ya da müşteri toplantısında güvenlik iyileştirmelerini göstermek gerektiğinde eliniz rahatlıyor.
Enterprise tarafta etki neden daha büyük?
Şunu söyleyeyim, Büyük yapılarda işler hiç öyle temiz ilerlemiyor, maalesef (yanlış duymadınız). Release branch’leri var, hotfix akışı var, uzun süre desteklenen sürümler var (buna dikkat edin). hatta bazen aynı ürünün üç farklı versiyonu paralel yürüyor. Böyle ortamlarda default branch’e bakmak resmen masaya tek ayak koymak gibi. Bu konuyla ilgili GitHub Copilot Verisi Değişiyor: Ne Toplanıyor, Ne Toplanmıyor? yazımıza da göz atmanızı tavsiye ederim.
Enterprise ortamda en önemli konu şu: yönetim panoları gerçeği yansıtmalı ki güvenlik yatırımı doğru yere aksın. Eğer Autofix etkisini eksik gösterirseniz, araç değer kaybediyor sanılır ve bütçe savunması zorlaşır. Bir kamu kurumunda geçtiğimiz yıl buna benzer bir tartışma çıkmıştı; metrikler revize edilince Copilot tabanlı önerilerin benimsenmesi ciddi biçimde arttı.
Bence En Faydalı Kısım CSV Tarafı
Ekrandaki kutucuklar güzel ama asıl iş bazen CSV’de dönüyor. Neden önemli bu? Security ekipleri Excel’e atıp filtre atıyor, FinOps kafasıyla trend çıkarıyor ya da üst yönetime aylık özet hazırlıyorlar—evet hâlâ böyle çalışılıyor! Şimdi CSV’nın de tüm protected branches’i kapsaması analizi daha sağlam hâle getiriyor. Daha fazla bilgi için azd Mart 2026: AI Ajanları ve Copilot’la Yeni Dönem yazımıza bakabilirsiniz.
Bazı ekipler dashboard’a bakıp geçiyor; ama ben hep raw data’ya inmeyi severim. Çünkü orada gizli desenler çıkıyor. Mesela hangi branşlarda Autofix önerileri hızlı kabul edilmiş, hangilerinde insanlar manuel düzeltmeyi seçmiş… bunlar sonradan çok şey anlatıyor. Daha fazla bilgi için GitHub Güvenliği: Küçük Repoda Büyük Açıkları Kapatmak yazımıza bakabilirsiniz. Bu konuyla ilgili Kubernetes’te AI Dönemi: Microsoft’un KubeCon 2026 Hamlesi yazımıza da göz atmanızı tavsiye ederim.
# Mantık olarak yeni yaklaşım şuna benziyor:
protected_branches = ["main", "release/1.x", "release/2.x"]
for branch in protected_branches:
collect_codeql_alerts(branch)
collect_autofix_stats(branch)
aggregate_all()
export_csv()
Aslında, Açıkçası burada çok karmaşık bir sihir yok; mesele kapsamın doğru seçilmesi. Küçük detay gibi duruyor ama sonuçta güvenlik raporu dediğiniz şeyin omurgası bu zaten.
Sahada Bunu Nasıl Okurum?
Zihnimde ilk sorduğum soru şu oluyor: “Bu sayı neden arttı?” Eğer cevap kapsam genişlemesiyse sorun yoktur; çünkü bu sağlıklı artıştır (inanın bana). Ama başka sebepler varsa dikkat kesilirim tabii.
- Ifade gücü: Daha fazla korunmuş dal = daha gerçekçi etki analizi.
- Yönetim dili: Güvenlik ekibi ile üst yönetim aynı veriye bakar.
- Ekip morali: Yapılan işin karşılığı daha net görünür.
- Kapasite planlama: Hangi repo veya dalda daha çok alert çıktığı anlaşılır.
Daha açık söyleyeyim, ne yalan söyleyeyim, Neyse uzatmayayım; burada asıl kazanım teknikten çok operasyonel tarafta geliyor bana göre.
Aman ha, unutmayın: küçük tuzaklar
Birincisi retrospektif veri değişimi kafa karıştırabilir; eski raporlarla yeni raporları birebir kıyaslarken not düşmek lazım. Siz hiç denediniz mi? İkincisi bazı ekipler yanlışlıkla bunun yalnızca “görsel değişiklik” olduğunu sanabilir — değil arkadaşlar, veri kapsamı değişmiş durumda.
Üçüncüsü de şu olabilir: Branch koruma politikaları gevşekse protected branches tanımı beklediğiniz kadar anlamlı olmaz. Yani önce süreç sağlam olmalı ki metrik düzgün çıksın.’ Bu noktada security governance ile DevOps disiplininin el ele gitmesi şart diye düşünüyorum.
Kendi Deneyimimden Bir Not Daha
“2026 Mart başında bir e-ticaret müşterisinde Copilot Autofix kullanımını değerlendirirken ilginç bir durum fark ettik.” Main’de başarı oranı fena değildi. Release/2025Q4 dalındaki hayatı uyarılar hiç tabloya düşmüyordu.” Müşteri tarafında ilk tepki ‘demek ki o kadar da kullanılmıyor’ oldu.”” Biz veri kapsamını açınca hikâye neredeyse tamamen değişti.”
“Az önce X dedim. Aslında Y daha doğru olabilir:” Buradaki mesele kullanım azlığı değilmiş; ölçüm körlüğüymüş.” Bu ayrımı yapmak önemli.” Çünkü teknoloji projelerinde yanlış problemi çözmeye kalkarsanız haftalar gider.”
Sizin İçin Pratik Çeviri Ne Olur?
Eğer GitHub Security Overview kullanıyorsanız hemen kontrol edin:
- Tüm kritik repository’lerde protected branches doğru tanımlanmış mı? — bunu es geçmeyin
- Pull request insight ekranındaki sayıları son sürüm öncesi kayıtlarla kıyaslarken tarih notu düşülmüş mü?
- Aylık security review toplantılarında artık default branch yerine kapsamlı veri üzerinden konuşuluyor mu? — bunu es geçmeyin
- Ekiplerin Autofix önerilerini kabul etme oranını dal bazlı ayrı izlemek mantıklı mı?
>
Sıkça Sorulan Sorular
CodeQL pull request insights neyi değiştiriyor?
Tüm protected branches’den veri toplayarak Autifix ve alert istatistiklerini daha gerçekçi gösteriyor.” Artık sadece default branch’e bakmıyorsunuz.” Bu da security overview’u daha doğru hâle getiriyor.”
Neden eski verilere göre sayı artmış görünüyor?
Pbecause data retroaktif olarak yeniden hesaplanabiliyor.” Protected branches kapsamına giren eski kayıtlar da tabloya dahil edildiği için rakamlar yükselmiş gibi görünebilir.” (en azından benim deneyimim böyle)
Bu güncelleme kimler için en faydalı?
Main dışında release veya hotfix branch kullanan ekipler için bayağı faydalı.” En çok da enterprise organizasyonlarda güvenlik. Yönetim raporlarını ciddi şekilde iyileştirir.”
Aynı şeyi manuel raporla takip etmek gerekir mi?
Daha açık söyleyeyim, ne yalan söyleyeyim, Eğer governance süreciniz sıkıysa evet.” Dashboard güzel. Periyodik export alıp kendi trend analizinizi yapmak hâlâ işe yarar.”
Kaynaklar ve İleri Okuma
İç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