Copilot Autofix Azure DevOps’ta: Alert Yığını Bitiyor mu?
Ne yalan söyleyeyim, GitHub’a göç… Lafı uzatmayayım, herkes için aynı kolaylıkta değil. Microsoft kaç yıldır “Azure Repos’tan GitHub’a geçin” diyor, ben de müşterilere aynı şeyi anlatıyorum. Ama gerçek şu: bazı ekipler bunu bir hafta sonu halledebiliyor, bazıları için bu üç yıllık bir dönüşüm programı. Regülasyonlar, özelleştirilmiş pipeline’lar, sektörel kısıtlar, sertifika zincirleri… işin içine girince köstebek yuvası gibi.
Hani, Peki o ekipler ne yapacak? Hâlâ Azure Repos’ta kalanlar yanı (şaşırtıcı ama gerçek). Geçişe niyetli ama sırada bekleyenler. Kısacası durum net.
Garip gelecek ama, İşte bu sorunun cevabı olarak Microsoft tarafında yeni bir şey var: Copilot Autofix, GitHub Advanced Security for Azure DevOps (GHAzDO) için sınırlı özel önizlemede yayınlandı. Yazıyı bitirene kadar size hem ne yaptığını, hem niye önemli olduğunu, hem de Türkiye’deki kurumsal müşteri perspektifinden nereye oturduğunu anlatacağım. Bakalım gerçekten iş görüyor mu?
Önce şu “Autofix” denen şey aslında ne yapıyor?
Aslında, CodeQL’i bilmeyen var mı bilmiyorum. Kısaca özetleyeyim: GitHub’ın geliştirdiği bir static analysis (SAST) motoru. Kodunuzu tarıyor, SQL injection mı var, path traversal mı var, sabit kodlanmış (hardcoded) credential mı bırakmışsınız — buluyor, alert açıyor. İşin kaba hali bu.
Araya gireyim: Şu ana kadar hikâye burada bitiyordu. Yanı alert geliyor, geliştiriciye düşüyor. Geliştirici oturuyor, vulnerability’yi araştırıyor, “ben buna nasıl bir patch yazarım, başka bir yeri kırmadan?” diye düşünüyor, deneme yanılma yapıyor, PR açıyor. Bu süreç ortalama bir kurumsal ekipte 2-3 gün sürüyor; bazen daha da uzuyor. Araya toplantı giriyor, biri izin alıyor, sonra konu tekrar raftan iniyor.
Autofix tam burada devreye giriyor. Aynı CodeQL motoru — vulnerability’yi bulan motor — bu sefer fix önerisini de üretiyor. Üstelik bunu Azure DevOps’un kendi alert ekranında yapıyor. Generate fix diye bir buton var. Tıklıyorsunuz, AI öneriyi getiriyor, gözden geçiriyorsunuz, gerekirse düzenliyorsunuz, sonra direkt PR olarak commit’liyorsunuz. Yanı yol biraz kısalıyor.
Evet, doğru duydunuz.
“Buluyoruz” ile “düzeltiyoruz” arasındaki uçurumu daraltan bir şey bu. Asıl mesele de zaten orada. Bulmak değil, kapatabilmek.
Neden bu kadar önemli? “Alert yorgunluğu” diye bir şey var
Doğrusu, Sahada en sık karşılaştığım manzara şu: bir bankacılık ekibinde ya da sigorta tarafında CodeQL açılıyor, ilk tarama 800-1200 alert döküyor. Geliştirici takım dehşete kapılıyor. Güvenlik ekibi “bunları kapatmanız lazım” diyor. Geliştiriciler “biz feature da yazacağız ya” diyor (inanın bana). Üç ay sonra bakıyorsunuz, alert sayısı 1500’e çıkmış; çünkü yenileri eklenmiş ama eskiler yerinde dürüyor.
Bu duruma alert fatigue deniyor. Ve sektördeki en büyük güvenlik açığı sebeplerinden biri açıkçası. Çünkü gerçek bir kritik alert geldiğinde bile gözden kaçabiliyor — yığının içinde kaybolup gidiyor.
Autofix bunu çözmüyor tabiî; sihirli değnek değil. Ama önemli bir şey yapıyor: kapatma maliyetini düşürüyor. Bir alert’i çözmek 2 saatten 5 dakikaya iniyorsa, ekibin “ya bunu da hallederiz” deme eşiği düşüyor. Backlog büyüme hızı yavaşlıyor. Bence asıl etkisi burada.
Default Setup ile birlikte tam manasıyla devreye giriyor
Burada bir not düşmek istiyorum. CodeQL’in Azure DevOps tarafında default setup diye bir konfigürasyonu var — pipeline’a tek satır YAML yazmadan taramayı açıyorsunuz; biraz tembel. Baya işe yarayan tarafı da bu zaten (inanın bana). Autofix de bunun üstüne oturuyor. Bu konuyla ilgili MSVC Build Tools Haziran 2026 Önizleme: Sessiz Ama Derin İyileştirmeler yazımıza da göz atmanızı tavsiye ederim.
Yanı tarama otomatik, fix önerisi otomatik, PR oluşturma otomatik; geliştiriciden istenen tek şey review yapmak oluyor. Güvenlik artık ayrı bir kulvar gibi durmuyor. DevSecOps’un yıllardır vaat ettiği şey buydu zaten — ama itiraf edelim, çoğu yerde sadece slogan kalmıştı.
Önizlemede neler var?
Limited private preview demişler; doğrusu da bu. Henüz herkese açık değil, başvuru yapıyorsunuz, dalgalar halinde aktif ediliyor, mail geliyor “sizinki açıldı” diye. Şu an kapsamda olanlar:
| Kapsam | Detay |
|---|---|
| Diller | C/C++, C#, Go, Java, Kotlin, JavaScript, TypeScript, Python, Ruby, Swift |
| Query seti | GitHub.com’da kullanılan curated set — en sık görülen sınıflar |
| Tipik vulnerability’ler | SQL injection, XSS, path traversal, hardcoded credentials, vb. |
| Entegrasyon noktası | Repo’nun Advanced Security sekmesi — alert detayında “Generate fix” butonu |
Dikkat : neredeyse tüm CodeQL query’leri kapsamda değil. Curated set var ; yanı GitHub bunu belli vulnerability sınıflarıyla başlatıyor — bence çok yerinde bir karar —. Bu mantıklı — çünkü AI üretilen fix’lerin doğruluk oranı her query için aynı değil. SQL injection için — en azından ben öyle düşünüyorum — bir patch üretmek, kompleks bir authorization akışını düzeltmekten daha öngörülebilir. Hatta dürüst olayım, fark baya belirgin.
Akışı pratikte nasıl gözünüzde canlandırın?
Bir senaryo üzerinden gidelim. Diyelim C# bir API’niz var, Azure Repos’ta dürüyor. CodeQL default setup açılmış. Yeni bir PR mergle’andıktan sonra tarama tetikleniyor. Bir SQL injection alert’i düşüyor — UserController.cs içinde string concat ile sorgu kuran bir yer. Basit gibi dürüyor ama işte tam orada patlıyor genelde. Bu konuyla ilgili Visual Studio’dan Çıkmadan Pull Request İncelemek: Artık Daha Rahat yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı yazımıza bakabilirsiniz.
- Advanced Security sekmesine gidiyorsunuz ; alert açık dürüyor.
- Generate fix” butonuna basıyorsunuz.
- Autofix birkaç saniye içinde önerilen değişikliği getiriyor — parametrize edilmiş bir sorgu, muhtemelen
SqlParameterkullanan hâliyle. - Diff’i inceliyorsunuz ; beğendiyseniz “commit to new PR” diyorsunuz.
- PR otomatik açılıyor ; build, test, code review gates normal şekilde çalışıyor.
- Merge olduktan sonra bir sonraki CodeQL taraması alert’i kendiliğinden kapatıyor.
İlginç olan şu ki, Evet, kağıt üzerinde oldukça temiz görünüyor ; ama sahada bazen iki satırlık değişiklik on iki dosyaya yayılıyor ve tablo bozuluyor, önü da söyleyeyim. Eskiden 2 saat süren iş gerçekten 5 dakikaya düşebiliyor ; tabiî her zaman değil, bazı önerileri reddetmeniz gerekecek ve bazı durumlarda manuel düzeltme şart kalacak. Ama oran meselesi bu, ortalama maliyet aşağı geliyor.
Evet.
Tam da öyle.
Şey.
Aynen.
Yanı insan eli şart.
Peki neden?
Çünkü yanlış fix daha pahalıya patlayabiliyor.
Bazen görünürde düzeltiyor ama alttaki akışı bozuyor.
O yüzden review kısmını atlamayın.
Bak şimdi…
Bu küçük not bence işin asıl sigortası.
Gözden kaçırmayın.
Ciddi söylüyorum.
Neyse uzatmayalım.
Küçük ekip vs büyük kurum — kim ne yapmalı?
Bakın, Küçük ekip ya da startup’taysanız:
Bana sorarsanız zaten GitHub’a geçin ; Autofix orada zaten production’da yaşıyor gibi düşünün. Azure Repos’ta kalmak için ciddi bir sebebiniz yoksa geçişin maliyeti küçük ekipte minimal kalır ; aksine GitHub Marketplace, Codespaces (ciddiyim). İlginç, değil mi? Daha geniş Copilot entegrasyonu gibi şeylerden kazancınız büyük olur. Bu konuyla ilgili EWS Bildirimlerinden Microsoft Graph’a Geçiş: Sessiz Ama Büyük Değişim yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazımıza bakabilirsiniz.
İşte tam da bu noktada devreye giriyor.
Ekip orta ölçekliyse (50-200 geliştirici):
Pilot repo’da deneyin derim ; önce görün ne çıkıyor ortaya çünkü kağıt üstündeki hesap bazen tutmuyor. GHAzDO lisansı maliyetli olabilir — kullanıcı başına aylık model dolar bazlı ilerliyor ve TL tarafında bütçeyi kabartabiliyor.
Önce ROI hesabını yapın.
SAST kapatma süreniz şu an 30 günden uzunsa yatırım kendini hızlı amorti ediyor.
Eğer enterprise / regüle sektördeyseniz:
Burada hikâye farklıdır biraz.
AI tarafından üretilen kodun production’a girmesi için iç governance süreçleriniz hazır mı ?
Yoksa önce önü kurun.
Autofix’in önerdiği her commit’in “AI-generated” olarak işaretlenmesi,
bir geliştiricinin onayından geçmesi,
audit trail’in tutulması —
bunlar tartışılır konular.
Compliance ekibinizle önden konuşmadan pilot başlatmayın.
Aksi hâlde geri dönüp açıklama yapmak zorunda kalırsınız.
Neyse ki çoğu kurumda bunların cevabı zamanla netleşiyor.
Bu arada kafa karıştırıcı gelebilir ama normal.
Bazı yerlerde güvenlik ekibi hız istiyor,
bazılarında işe hukuk frene basıyor.
İkisi de haklı olabiliyor.
İşin garibi burada.
Bak şimdi,
dengeyi kurmak esas mesele.
Sadece teknik bakarsanız eksik kalır.
Sadece uyum tarafına bakarsanız süreç taşlaşıyor.
Ortası lazım.
Bence soru bu değil aslında.
Asıl soru,
ne kadar kontrollü geçeceğiniz.
Tam da öyle.
Kafadan atlamak yok.
Ama sonsuza kadar beklemek de yok.
İkisinin arasında yürümek gerekiyor.
Biraz sıkıcı,
ama gerçek hayat böyle çalışıyor.
Evet,
bazen tam olarak böyle.
Konuya nereden bakarsanız bakın eksikler. Dikkat edilecek noktalar var mı?
Yazıyı sadece övgüyle bitirmek istemiyorum çünkü bu doğru olmaz.
Birkaç gerçekçi nokta:
-
Limited private preview:
Yanı kuyrukta bekleyeceksiniz.
Üretim planınızı buna bağlamayın şimdilik.
-
Curated query set:
Tüm vulnerability sınıfları kapsamda değil.
Mesela iş mantığına özel custom CodeQL query’leriniz varsa,
Autofix muhtemelen onlarda çalışmayacak. -
Yanlış pozitifler için fix önerisi:
Eğer alert zaten false positive işe,
Autofix size doğru görünen ama gereksiz bir patch sunabilir.Önce alert’in gerçekten gerçek olduğunu doğrulayın.
-
Multi-file fix’ler:
AI tek dosyada lokal değişikliklerde başarılı.
Birden fazla katmanı etkileyen değişikliklerde hâlâ insan gerekiyor.
-
Maliyet:
GHAzDO + Copilot kombinasyonu ucuz paket sayılmaz.
Karşılığında ne aldığınızı net hesaplayın.
Neyse uzatmayayım;
mesele net.Bir de şu var:
Microsoft GitHub’a göç mesajını hâlâ koruyor.Yanı Autofix’i Azure DevOps’a getirmiş olması vazgeçtik anlamına gelmiyor.
Yeni özellikler önce GitHub.com’da çıkacak,
sonra belki Azure DevOps’a gelecek,
belki hiç gelmeyecek.
Stratejik kararı buna göre verin.İlk adımda ne yapayım derseniz
- GHAzDO lisansınız yoksa,
önce onun maliyet/fayda analizini yapın. - CodeQL default setup’ı pilot repo’da açın,
ilk taramadan ne döndüğünü görün. - Autofix private preview’a başvurun —
bekleme listesi var,
bu süreyi kaybetmeyin. - Bu arada güvenlik ekibi + dev ekibi arasında AI-suggested patch review prosedürü taslağı hazırlayın.
Geldiğinde hazır olun. - Eğer aynı zamanda Azure DevOps’tan GitHub’a Kesintisiz Geçiş:
ELM ile Yeni Dönem yazımdaki ELM aracını da inceliyorsanız uzun vadeli geçiş planınızı paralel ilerletin.
Neden?
Çünkü yollar bazen kesişiyor.
Mesela bugün güvenliği toparlarsınız,
yarın platform kararını yeniden masaya koyarsınız.Konuyla ilgili teknik derinlik için CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması yazıma da göz atmanızı öneririm —
Autofix’in çalıştığı motor orada anlatılıyor.Bir de güvenlik tarafında yapılan başka sessiz hamleleri merak edenler için GitHub’ın Unuttuğu Depolar İçin Güvenlik Kontrolü:
Bence Asıl Mesaj Bu yazımı da hatırlatayım.Tamamdır.
Sıkça Sorulan Sorular
Copilot Autofix tüm Azure DevOps müşterilerine açık mı?
Hayır, şu an limited private preview aşamasında. Başvuru formu üzerinden enrollment talep edebiliyorsunuz; dalgalar halinde aktif ediliyor. Aktivasyon birkaç hafta sürebilir, aktif olduğunda Microsoft size e-posta atıyor.
Autofix kullanmak için ekstra lisans gerekiyor mu?
Aslında Autofix, GitHub Advanced Security for Azure DevOps (GHAzDO) lisansının içinde geliyor. Yanı Advanced Security’ye zaten ödüyorsanız — ki bu tartışılır — ekstra bir şey çıkmıyor; ama GHAzDO yoksa o lisansı almanız şart. Önizleme döneminde ek ücret yok, ancak GA olduğunda durum değişebilir — bence bu noktayı takipte tutmak mantıklı.
Hangi diller ve vulnerability sınıfları destekleniyor?
CodeQL’in desteklediği tüm diller kapsamda: C/C++, C#, Go, Java, Kotlin, JavaScript, TypeScript, Python, Ruby ve Swift. Vulnerability tarafında mesela SQL injection, XSS, path traversal, hardcoded credentials gibi en sık karşılaşılan sınıflar için hazır bir query seti var. Custom query’lerinizde çalışmayabilir, bunu göz önünde bulundurun.
Önerilen fix’ler güvenli mi? Doğrudan production’a girer mi?
Hayır, kesinlikle doğrudan production’a girmemeli. Autofix size bir öneri sunuyor ve bir pull request açıyor; bu PR mevcut review, build ve test gate’lerinizden geçmek zorunda. Açıkçası AI önerilerinin %100 doğru olduğunun garantisi yok — özellikle business logic ile iç içe geçmiş vulnerability’lerde manuel inceleme şart.
GitHub’a göç planımız varsa şimdi Autofix’e yatırım yapmalı mıyız?
Göç planınız 12 aydan kısaysa, enerjinizi göçe odaklayın; hani GitHub.com’da bu özellik zaten production’da çalışıyor. Ama göç planınız 18 ay ve üstüyse ya da henüz net bir takvim yoksa, tecrübeme göre Autofix bu süreçte değerli bir köprü olabiliyor — yatırımın geri dönüşü mantıklı.
Peki neden?
Kaynaklar ve İleri Okuma
Copilot Autofix for GitHub Advanced Security for Azure DevOps — Microsoft DevBlogs
GitHub Advanced Security for Azure DevOps Overview — Microsoft Learn
About Autofix for CodeQL Code Scanning — GitHub Docs
- GHAzDO lisansınız yoksa,
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder