Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor
Bak şimdi, Bakın şimdi, güvenlik taraması deyince çoğu kişinin aklına hemen “süreç, ayar, pipeline düzenleme” geliyor. Haklılar; çünkü işin içinde gerçekten bunlar var (kendi tecrübem). Ben yıllardır kurumsal müşterilerde Azure DevOps altyapısı kuruyorum. En çok uğraştıran işlerden biri, yüzlerce repo’ya tek tek CodeQL pipeline’ı eklemekti. Ciddi ciddi saatlerce YAML yazıp task kurup sonra da bunları güncel tutmaya çalışıyorduk. Artık o dönem biraz geride kalıyor gibi (ki bu çoğu kişinin gözünden kaçıyor)
Vallahi, Microsoft Azure DevOps Advanced Security’ye iki tane dikkat çekici özellik getirdi: CodeQL default setup ile tek tıkla güvenlik taraması başlatma (evet, doğru duydunuz), birleşik alert deneyimi ile organizasyon genelindeki neredeyse tüm güvenlik uyarılarını tek ekrandan yönetme — valla güzel iş çıkarmışlar —. İkisi bir araya gelince işler baya değişiyor, açık konuşayım (bizzat test ettim)
CodeQL Default Setup: Gerçekten Tek Tıkla mı?
İtiraf edeyim, Evet. Gerçekten tek tıkla. Daha doğrusu, dur bir saniye, biraz açayım bunu; şu ana kadar CodeQL’i Azure DevOps üzerinde çalıştırmak için her repo’ya özel pipeline tanımlamanız gerekiyordu. YAML yazacaksınız, CodeQL task’ını kuracaksınız, build adımlarını ayarlayacaksınız, sonra da bu pipeline’ı bakımda tutacaksınız. Yüzlerce repo’su olan bir organizasyonda bu iş tam bir baş ağrısıydı.
Bunu biraz açayım.
Bir şey dikkatimi çekti: Geçen yıl bir finans kuruluşunda birebir bunu yaşadık (evet, doğru duydunuz). 340 civarı repo vardı ve her birine CodeQL eklemek gerekiyordu. Ekip de üç kişilik bir DevOps takımıydı. Hesabı siz yapın; repo başına ortalama 20-30 dakika yapılandırma, üstüne test, üstüne de “neden çalışmıyor” debug süreci… Haftalarca sürdü işte.
Şimdi CodeQL default setup ile o sürtünme azalıyor (yanlış duymadınız). Repo, proje veya organizasyon seviyesinde tek bir tıklamayla taramayı açıyorsunuz. Azure Pipelines arka planda otomatik çalışıyor. YAML düzenleme yok. Task kurulumu yok. Kısacası uğraş azaldı.
Nasıl Etkinleştiriyorsunuz?
Doğrusu, Doğrusu, adımlar şaşırtıcı derecede basit. Hani bazen Microsoft bir şeyi “kolay” diye anlatır ama iş 15 adıma döner ya — bu sefer gerçekten kısa:
- Repository, proje veya organizasyon ayarlarına gidin — ciddi fark yaratıyor
- Code Security planını etkinleştirin — bunu es geçmeyin
- CodeQL default setup’ı açın — bunu es geçmeyin
- Taramalar belirlenen zamanlama ile otomatik çalışmaya başlasın — ciddi fark yaratıyor (bu kritik)
Açık konuşayım, Zamanlamayı organizasyon seviyesinden değiştirebiliyorsunuz. Agent pool’u da (söylemesi ayıp) kendiniz seçebiliyorsunuz; yani taramaların nerede çalışacağını kontrol ediyorsunuz. Bu detay önemli çünkü bazı müşterilerimde self-hosted agent kullanımı zorunlu oluyor (özellikle bankacılık ve kamu tarafında), verinin dış ortama çıkmaması gereken senaryolar var ya hani, tam orası. Agent pool yapılandırması bu noktada fena değil; hatta baya iş görüyor (buna dikkat edin)
Birleşik Alert Deneyimi: Sonunda Tek Ekran
Vallahi, güvenlik yöneticilerinin en büyük derdi neydi biliyor musunuz? “Repo repo dolaşıp güvenlik durumumu anlamak zorundayım.” Bu cümleyi kaç kere duydum sayamam bile. Bir telekom müşterimizde güvenlik ekibi her pazartesi sabahı 2 saat harcayıp tüm repo’ları tek tek kontrol ediyordu. 2 saat! Her hafta! İnsan şaşırıyor açıkçası.
Hmm, bunu nasıl anlatsamdı…
Yeni birleşik alert görünümü, Security Overview içindeki alerts sekmesinde organizasyonunuzdaki bütün repository’lerin default branch’indan gelen uyarıları tek ekranda topluyor (en azından benim deneyimim böyle). Arama yapabiliyorsunuz, sıralayabiliyorsunuz, filtreleyebiliyorsunuz; hepsi aynı yerde duruyor.
Şunu söyleyeyim, Açık konuşayım: bu özellik GitHub Advanced Security’de zaten vardı (evet, doğru duydunuz). Azure DevOps tarafının bunu bu kadar geç getirmesi biraz can sıkıcı oldu bende. Ama geç olsun güç olmasın demek lazım.
Security Campaign’ler: İşin Koordinasyon Tarafı
Yani ha bu arada sadece görmekle kalmıyorsunuz; Security Campaign‘ler denen bir yapı da var ki bence asıl farkı o yaratıyor (ki bu çoğu kişinin gözünden kaçıyor) (evet, doğru duydunuz). Filtrelediğiniz alert’lerden bir kampanya oluşturuyorsunuz ve bunu ekibinizle paylaşıyorsunuz.
Neyse konuyu dağıtmadan söyleyeyim; bunun pratikte ne işe yaradığını anlatırken iki yazıya da göz atabilirsiniz: VS Debugger Agent: Bug Avı Artık Ajan İşi. Bir de GitHub CLI ile Agent Skill Yönetimi: Tam Rehber.
- Belli bir CVE’nın organizasyon genelinde takibi — bunu es geçmeyin
- Sadece “critical” seviyesindeki SQL injection açıklarına odaklanma (bu kritik)
- Belli bir takımın sorumlu olduğu repo’lardaki dependency alert’leri (bence en önemlisi)
- Sprint bazlı güvenlik remediation koordinasyonu
Bence, Filtreler canlı çalışıyor. Kampanyayı oluşturduktan sonra kriterlerinize uyan yeni bir zafiyet çıkarsa otomatik olarak kampanyada görünüyor. Bu çok kritik bir detay aslında; statik liste değil bu, dinamik görünüm.
Peki neden?
Security Campaign’ler sayesinde güvenlik ekipleri artık “bu hafta şu açıkları kapatıyoruz” diyebiliyor ve ilerlemeyi gerçek zamanlı takip edebiliyorlar.. Bu yaklaşım özellikle düzenleyici denetimlere tabi sektörlerde ciddi fark yaratıyor.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Şimdi gelelim benim asıl konuşmak istediğim yere. Türkiye’deki şirketler açısından bu gelişmeleri ayrı değerlendirmek lazım; geçiş yapma süreci her yerde aynı gitmiyor (şaşırtıcı ama gerçek)
Kendi danışmanlık tarafımda gördüğüm şey şu: Müşterilerin büyük çoğunluğu Azure DevOps kullanıyor ama Advanced Security lisansını henüz aktif etmemiş durumda.
Neden? Maliyet yüzünden tabiî ki… Advanced Security committer başına aylık faturalandırılıyor ve TL bazında düşününce — özellikle 50-100 developer’lık ekiplerde — bütçede hissedilir hâle geliyor.
Aylık developer başına yaklaşık 49 USD civarında maliyet var.
Bu da 100 kişilik ekipte yıllık yaklaşık 60.000 USD ediyor.
Daha fazla bilgi için Azure Local ve Armada: Edge’de Egemen AI Dönemi. Şimdi, bir de VS Live! Las Vegas 2026: İzlenmesi Gereken 20 Oturum.
Bunu biraz açayım.
İşin garibi, Küçük ekipseniz; yani 10-15 kişilik bir startup’sanız; Advanced Security’yi açmak mantıklı olabilir bence. Hele bir de tek tıkla CodeQL kurulumu artık o “pipeline kurmak çok zor” bahanesini baya zayıflatıyor. Ama 200+ developer olan enterprise yapılarda bütçe onayı hâlâ en büyük engel olarak duruyor (bu beni çok şaşırttı)
Bir de şu var — bunu çok az kişi konuşuyor — Türkiye’deki birçok kurum hâlâ on-premises Azure DevOps Server kullanıyor.
Bu özellikler şu an Azure DevOps Services (bulut) için geçerli.
On-prem’e ne zaman gelir? Belli değil.
Bu da benimseme hızını aşağı çeken önemli faktörlerden biri (ciddiyim).
Kısa bir not düşeyim buraya.
Pratik Karşılaştırma: Eski vs Yeni Yaklaşım
Daha somut olsun diye tablo hazırladım.
Eski yöntemle yeni default setup’ı yan yana koyunca fark daha net çıkıyor:
| Kriter | Eski Yöntem (Manuel Pipeline) | Yeni Yöntem (Default Setup) |
|---|---|---|
| Kurulum süresi (repo başı) |
Sıkça Sorulan Sorular
CodeQL default setup ücretsiz mi?
Küçük bir detay: Açıkçası, hayır. CodeQL default setup, Azure DevOps Advanced Security lisansının bir parçası yani committer başına para ödüyorsunuz. Ama bence kurulum ve ayar derdini düşününce, operasyonel olarak ciddi bir tasarruf sağlıyor.
Default setup ile custom CodeQL sorguları çalıştırabilir miyim?
İnanın, Şu anki public preview’da bu biraz kısıtlı, açıkçası. Yani özel sorgulara ihtiyacınız varsa geleneksel pipeline tabanlı CodeQL kurulumuna yönelmeniz gerekiyor. Microsoft’un ilerleyen sürümlerde bunu geliştirmesi bekleniyor, bekleyelim görelim.
Security Campaign’leri kimler oluşturabilir?
Security Overview’a erişimi olan güvenlik yöneticileri oluşturabiliyor. Yani organizasyon seviyesinde uygun izinlere sahip olmanız gerekiyor (en azından benim deneyimim böyle). Neyse, kampanyayı oluşturduktan sonra ekip üyeleriyle paylaşıp koordineli çalışabilirsiniz, hani herkes kendi payına düşeni halleder gibi.
On-premises Azure DevOps Server’da bu özellikler var mı?
Şu an için yok. CodeQL default setup ve birleşik alert deneyimi yalnızca Azure DevOps Services’ta, yani bulut tarafında çalışıyor. On-prem sürüme ne zaman geleceğine dair resmî bir tarih de verilmedi maalesef.
Mevcut CodeQL pipeline’larım varsa, default setup’a geçmeli miyim?
Tecrübeme göre, eğer pipeline’larınızda özelleştirilmiş sorgular veya karmaşık build adımları varsa hemen atlamayın. Önce bir test repo’sunda default setup’ı deneyin, sonuçları karşılaştırın, ondan sonra karar verin. Basit konfigürasyonlar için ise default setup kesinlikle çok daha pratik.
Kaynaklar ve İleri Okuma
CodeQL Default Setup Resmî Dokümantasyonu
Azure DevOps Blog: One-click Security Scanning Duyurusu
Azure DevOps Advanced Security Yapılandırma Rehberi — Microsoft Learn (evet, doğru duydunuz)
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.
2 comments