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. Tabii 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. Yani 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ı…
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Tek tek düzeltme | Daha kontrollü inceleme | Daha çok scan, daha uzun süre |
| Batch apply | Daha hızlı remediation | Paketleme iyi yapılmazsa review zorlaşabilir |
| Karma yaklaşım | Denge sağlar | Süreç disiplini ister |
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 oldu” 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?
- Küçük startup: Kod sahipliği belli olduğu için batch apply hızlı adapte edilir.*
- Büyük enterprise: Onay zinciri ve policy katmanı nedeniyle önce pilot yapmak gerekir.*
Aksi halde ekipler gereksiz yerde hızlı davranıp yanlış yerde yavaşlayabilir.
Bugünlerde Copilot Code Review metriklerine bakarken gördüğüm şey tam da buydu:
ölçmediğin şeyi iyileştiremiyorsun.
Bu yüzden yeni özellikleri körlemesine açmak yerine birkaç sprint boyunca izlemek bence daha doğru.
Sıkça Sorulan Sorular
GitHub code scanning’de batch apply ne işe yarar?
İşte, pull request içindeki birden fazla security alert suggestion’ını topluca uygulamanızı sağlar. Böylece her fix için ayrı ayrı işlem yapmak zorunda kalmazsınız ve tarama sayısı azalır (ciddiyim)
Tek commit ile uygulamak neden avantajlı?
Tek commit sayesinde yalnızca bir kez scan çalıştırırsınız. Review süresi kısalır.
Bu yöntem özellikle birbirine bağlı küçük düzeltmelerde oldukça iş görür.
Bütün alert türlerinde kullanmalı mıyım?
Hayır, her durumda uygun olmayabilir. Alakasız değişiklikleri aynı pakete koyarsanız inceleme zorlaşabilir. En doğrusu ilişkili olanları birlikte gruplamak olur — E tabii ekip disiplini de şart!
This feature small team and enterprise’de farklı mı kullanılır?
Evet.
Küçük takımlarda doğrudan hız kazandırır.
Enterprise tarafta işe politika, onay ve ownership katmanları yüzünden önce pilot deneme yapmak daha sağlıklı olur.
Kaynaklar ve İleri Okuma
GitHub Code Scanning Resmî Dokümantasyonu
GitHub Blog Changelog Duyurusu
Bi saniye — About Code Scanning in GitHub Docs (yanlış duymadınız)
İlgili Yazılarımızdan Bazıları
İç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