GitHub Code Scanning’de Toplu Düzeltme: PR’lar Hızlandı

Geçen hafta bir müşteride tam da şunu konuştuk: güvenlik açığı var, ekip görüyor,. Düzeltme işi PR içinde parça parça ilerleyince herkesin canı sıkılıyor. Bir alert için ayrı commit, öbürü için ayrı scan, sonra review tekrar başa sarıyor… İş uzuyor. GitHub’ın code scanning tarafına gelen toplu uygulama fikri işte bu sürtünmeyi bayağı azaltıyor.

İşin özü basit ama etkisi fena değil. Pull request içindeki Files changed sekmesinde birden fazla security alert suggestion’ı tek tek uğraşmadan batch’e alabiliyorsunuz. Sonra bunları tek commit olarak uyguluyorsunuz. Böylece her alert için ayrı ayrı tarama koşmak yerine bir kez scan çalışıyor. Hem zaman kazanıyorsun hem de PR akışı gereksiz yere dağılıp gitmiyor.

Açık konuşayım, ben yıllardır güvenlik ve DevOps tarafında en çok şu cümleyi duydum: “Düzeltiriz ama sonra.” İşin aslı şu ki o “sonra” çoğu zaman hiç gelmiyor. En çok da büyük kod tabanlarında küçük yamalar bile birikince borç gibi büyüyor (bizzat test ettim). Bu yüzden böyle küçük görünen iyileştirmeler pratikte bayağı değerli oluyor (en azından benim deneyimim böyle)

Bir dakika — bununla bitmedi.

Neden Bu Kadar Önemli?

Dürüst olmak gerekirse, Code scanning alarmı görmek başka şey, önü düzgün kapatmak başka şey. Mesela 2024’te Ankara’da bir finans müşterisinde benzer bir akış kurarken fark ettik ki ekipler güvenlik uyarılarını ciddiye alıyor ama süreç dağınıksa öncelik düşüyor. Herkes kendi işine bakıyor, PR’da kalan birkaç satır da ertelenip gidiyor.

Toplu uygulama burada güzel bir denge kuruyor. Güvenlik ekibi “bu zafiyetleri kapatalım” diyor, geliştirici ekip de bunu tek seferde halledip yoluna devam edebiliyor. Hani market alışverişinde beş kere kasaya gitmek yerine hepsini tek sepete koymak gibi… Basit ama etkili.

Bir de şu var: tek commit ile ilerlemek review kalitesini artırabiliyor. Çünkü değişiklikler birbirine bağlıysa, onları parçalamak bazen anlamı bozuyor. Mesela refactor + güvenlik düzeltmesi birlikteyse tek seferde görmek daha mantıklı olabiliyor. Tabiî her durumda değil; bazı yamaları ayırmak hâlâ daha temiz olabilir.

Küçük takımda nasıl hissedilir?

Küçük startup’larda bu özellik direkt hız kazandırır. 3 kişilik ekipte kimse bütün gün güvenlik alarmı kovalamak istemez zaten. Tek batch ile işi toparlamak ciddi rahatlık verir (bizzat test ettim)

Enterprise seviyede neden daha kıymetli?

Büyük organizasyonda asıl mesele ölçek oluyor. Yüzlerce repo, farklı sahiplik alanları ve onay akışları varken her ekstra scan maliyet yaratır — hem teknik maliyet hem insan zamanı açısından.

Pratikte Akış Nasıl Çalışıyor?

Mantık şu: pull request üzerinde Code Scanning tarafından bulunan önerileri görüyorsunuz, Files changed bölümünde bunlardan birkaçını seçip batch’e ekliyorsunuz ve sonra topluca uyguluyorsunuz. Sonrasında sistem bunu tek commit olarak ele alıyor ve yeni scan sayısını şişirmeden ilerletiyor. Bu konuyla ilgili Azure SDK’da Node.js 20 Desteği Bitiyor: Hazır mısınız? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili vcpkg’de Paralel Kurulum ve Güvenlik Yaması: Neler Değişti? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Yapay Zekâ Çağında Sanayi Politikası: Asıl Mesela Ne? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Azure SQL’de Vektörler ve Analitik: ETL Neden Geride Kalıyor? yazımıza da göz atmanızı tavsiye ederim.

// Kavramsal akış
1) PR açılır
2) Code scanning alert'lar görünür
3) Files changed sekmesinde öneriler seçilir
4) Batch oluşturulur
5) Tek commit uygulanır
6) Tek tarama çalışır
7) Review devam eder

Şöyle söyleyeyim, Bence buradaki en önemli nokta şu: değişiklikleri yığmak değil, bilinçli paketlemek gerekiyor. Yanı rastgele her şeyi aynı torbaya atmayın; ilişkili olanları birlikte alın (inanın bana). Yoksa kısa vadede hız kazanırsınız ama inceleme tarafında kafa karışıklığı çıkar.

Hmm, bunu nasıl anlatsamdı…

Neyse uzatmayayım, burada asıl kazanım “daha az tıklama” değil; karar döngüsünün kısalmasıdır diyebilirim. Daha fazla bilgi için code ile ilgili önceki yazımız yazımıza bakabilirsiniz.

Sahada Ben Ne Gördüm?

2019’da kendi lab ortamımda benzer mantığı Azure DevOps üzerinde denemiştim; o zaman amaç güvenlik uyarılarıyla build tekrarlarını azaltmaktı. O deneyim bana şunu öğretti: otomasyon ne kadar iyi olursa olsun kullanıcı deneyimi kötü işe insanlar sistemi pas geçiyor.

Çok konuştum, örnekle göstereyim.

Bak şimdi, Bir başka örnek de Logosoft tarafında 2025’in sonlarında yaptığımız bir kurumsal dönüşüm çalışmasından geliyor (evet, biraz taze). Orada güvenlik ekibi ile geliştirme ekibi arasında “kim neyi ne zaman kapatacak?” tartışması çok oluyordu. Batch mantığına yakınlaştırdığımız iş akışıyla tartışma azaldı; çünkü artık herkes aynı değişiklik paketine bakıyordu.

Bakın, Ama dürüst olayım… Her yerde mucize olmuyor! — kendi adıma konuşayım — Bazı kod tabanlarında alert sayısı o kadar fazla oluyor ki batch yapmak bile ilk anda biraz göz korkutuyor. O noktada önceliklendirme şart; yoksa paketlemek yerine üst üste koymuş oluyorsun sadece.

Zayıf taraf neresi?

Zayıf tarafı şu olabilir: yanlış gruplandırılmış değişiklikler review süresini uzatabilir veya regresyon riskini artırabilir. Kağıt üstünde süper, pratikte göreceğiz artık dediğim yerlerden biri bu (buna dikkat edin)

Nerede çok işe yarar?

Neyse, en çok da dependency kaynaklı ya da benzer pattern’lerden çıkan uyarılarda iyi çalışır diye düşünüyorum. Mesela insecure API usage tarzı birkaç noktayı aynı mantıkla kapatıyorsanız batch gayet doğal durur.

Kullanırken Nelere Dikkat Etmeli?

• Aynı kökten gelen uyarıları birlikte grupla.
• Tamamen alakasız düzeltmeleri aynı batch’e sokma.
• Ekip içinde ownership net olsun; yoksa “ben yaptım öldü” kaosa döner.
• Büyük PR’larda önce riskli olanları ayıkla, sonra toplu ilerle.
• Sadece hız değil, okunabilirliği de düşün.

Bana göre burada disiplin kritik nokta oluyor. Güvenlik aracı sana hız veriyor diye kontrolü bırakmıyorsun; tam tersine süreç tasarımını biraz daha akıllıca yapman gerekiyor.

Aslında — dur bir saniye — bunu build pipeline mantığı gibi düşünebilirsiniz: yanlış job sırası varsa tüm zincir yavaşlar veya kırılır.

“Güvenlik düzeltmesini hızlandıran şey sadece araç değil; aracın etrafına kurduğun süreçtir.”

C# dünyasında çalışan ekiplerle konuşurken de hep aynı şeyi söylüyorum: küçük optimizasyonlar toplamda büyük fark yaratıyor. AZ-305 sınavına hazırlanırken mimariyi sadece teknik bileşen olarak değil, operasyonel yük olarak da düşünmeye başlamıştım; burada da durum aynı aslında.
Araç güzel olabilir ama işletim yükünü azaltmıyorsa sahada beklediğin kadar parlak görünmeyebilir. Gel gelelim güzel haber şu ki bu özellik genel kullanıma açılmış durumda. Github.com üzerinde erişilebilir hâle gelmiş olması benim açımdan önemli bir sinyal veriyor: ürün olgunlaşıyor. Günlük iş akışına giriyor demek bu. Bir de şunu söyleyeyim:bazen en iyi iyileştirme büyük ekranlara çıkmaz; sessizce zamanı geri verir. Bu özellik de öyle biraz…

Kendi Ekibinizde Nasıl Konumlandırırsınız?

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Kubernetes v1.36 Pod-Level Resource Managers: Sidecar Derdi Bitiyor2 May 2026

GitHub Pull Request Dashboard Yenilendi: Takip Etmek Hiç Bu Kadar Kolay Olmamıştı28 Mar 2026

GPT-5.5 GitHub Copilot'a Geldi: Ne Değişiyor, Ne Kadar Ediyor?24 Nis 2026

SQL Yazarken İki Dünyayı Birleştiren Küçük Ama Güçlü Hamle8 Nis 2026