Geçen hafta bir bankacılık müşterimde yine aynı soru geldi: “Aşkın bey, GitHub’da binlerce alert var, Defender for Cloud’da da binlerce. Hangisi gerçekten önemli, hangisi gürültü?” Klasik. Bu soruyu son üç yılda en az on farklı kurumdan duydum diyebilirim. Cevabım da pek değişmedi: ikisini birbirine bağlamadan, hangı kodun production’da nerede çalıştığını görmeden bu işin içinden çıkamazsınız.
İşte Microsoft, 5 Mayıs itibarıyla GitHub Advanced Security (GHAS) ile Defender for Cloud entegrasyonunu Genel Kullanıma (GA) açtı. Public preview’dayken bayağı kurcalamıştım, eksikleri vardı. Şimdi GA’ya geçti ve açık konuşayım: bu, son yıllarda gördüğüm en mantıklı entegrasyonlardan biri. Ama mükemmel mi? Değil. Aşağıda neyi sevdiğimi, neyi sevmediğimi ve Türkiye’deki kurumlar için ne anlama geldiğini anlatacağım.
Bir dakika — bununla bitmedi.
Olay Aslında Ne? Code-to-Cloud Görünürlüğü
Lafı gevelemeden anlatayım. Bir geliştirici GitHub’a kod push ediyor. Pipeline çalışıyor, container image üretiliyor, AKS’e ya da Azure Container Apps’e deploy ediliyor. Peki soru şu: production’da çalışan o container hangı commit’ten, hangı repo’dan, hangı branch’ten çıktı? Ve içindeki şu CVE-2024-XXXX dependency açığı gerçekten internete açık bir servisi mi etkiliyor, yoksa internal bir batch job’ı mı? İşte can alıcı nokta burada.
Eskiden bu sorunun cevabı için elle script yazıyorduk. Image SHA’sı al, registry’de eşleştir, pipeline log’una bak, hangı repo’dan tetiklendiğini bul… Saatler sürüyordu. Hatta açık konuşayım, bir telekom projesinde bir junior arkadaşa “şu image hangı repo’dan çıkmış bul” demiştim — iki gün uğraştı çocuk, sonunda da emin olamadı (ben de ilk duyduğumda şaşırmıştım)
Defender for Cloud şimdi bunu otomatik yapıyor. GitHub artifact attestations denen mekanizmayı kullanarak (cryptographic imza diyelim), runtime’daki container’ı kaynağına geri bağlıyor. Yanı Defender bir image görüyor, “bu image’ı kim build etti?” diye soruyor; attestation sayesinde de doğrudan repo’ya, commit’e. Workflow’a kadar inebiliyor.
Bence buradaki asıl iş attestation kısmında dönüyor. Çünkü bu sayede “trust but verify” lafı boş laf olmaktan çıkıyor. Bir image’ın gerçekten o repo’dan çıktığını matematiksel olarak ispatlıyorsunuz — supply chain saldırılarına karşı ciddi bir kalkan.
Runtime Context: Asıl Fark Burada
Size bir şey söyleyeyim, Şimdi gelelim can alıcı yere (eh, fena değil). Diyelim ki Dependabot size — kendi adıma konuşayım — “log4j’de critical açık var” dedi. Tamam da bu açık 200 repo’da var; hangisi açıl? Peki neden bazıları daha önemli? Çünkü artık sadece açığın kendisine değil, nerede çalıştığına da bakıyoruz.
Dürüst olmak gerekirse, Eski dünyada cevap yoktu (bizzat test ettim). Hepsine aynı önceliği verirdiniz ya da geliştirici hissiyatına göre sıralardınız. Yeni dünyada Defender for Cloud, Deployment Record API üzerinden GitHub’a şu bilgileri gönderiyor:
- Bu artifact şu anda production’da çalışıyor mu?
- İnternete açık mı (
internet-exposed)? - Hassas veri işliyor mu (
sensitive-data)? - Hangı cluster’da, hangı namespace’te? — ciddi fark yaratıyor
Şunu fark ettim: Ve siz GitHub’da alert listesini filtrelerken artık şunu yazabiliyorsunuz:
has:deployment runtime-risk:internet-exposed severity:criticalVallahi, Bir saniyede 2000 alert’ten 12 alert’e iniyorsunuz. İşte triage budur. Geçen ay bir e-ticaret müşterimde bunu preview olarak denedik — security ekibi haftada ortalama 6 saat triage’a harcıyordu; bu sayı 1.5 saate düştü. Yanı fena değil, hatta baya iş görüyor diyebilirim.
Filter Operatörleri — Pratik Örnekler
Filtreler organization seviyesindeki alert listelerinde ve security campaign oluşturma akışında çalışıyor. Birkaç örnek vereyim; çünkü kağıt üstünde güzel duran şeylerin sahada bazen tökezlediğini hepimiz biliyoruz. Daha fazla bilgi için Kubernetes v1.36: Pod-Level In-Place Resize Beta’da yazımıza bakabilirsiniz.
| Filtre | Anlamı | Tipik Kullanım |
|---|---|---|
has:deployment |
Sadece deploy edilmiş artifact’lar | Aktif risk önceliklendirme |
runtime-risk:internet-exposed |
İnternete açık servisler | Dış saldırı yüzeyi |
runtime-risk:sensitive-data |
PII/finansal veri işleyen | KVKK/GDPR compliance |
-has:deployment |
Hiç deploy edilmemiş | Backlog temizliği, dead code |
Son satırı özellikle seviyorum. Çünkü repo’larda deploy edilmemiş, kullanılmayan bağımlılıklara ait yüzlerce alert birikiyor. Bunları düşük öncelikli bir kampanyaya alıp arka plana atabilirsiniz; yanı biraz nefes aldırıyor. Daha fazla bilgi için Microsoft OpenJDK Nisan 2026 Yaması: Sahadan Notlar yazımıza bakabilirsiniz.
Türkiye’deki Kurumlar İçin Ne İfade Ediyor?
Açık konuşalım; Türkiye’deki kurumsal müşterilerimde gördüğüm tablo biraz farklı. Çoğu yerde GHAS lisansı var ama tam kullanılmıyor. Daha açık söyleyeyim, defender for Cloud da öyle — alınmış, “Standard tier” açık ama runtime protection özellikleri kapalı. Bu entegrasyonun gerçek değerini almak için her ikisinin de tam aktif olması lazım. Daha fazla bilgi için Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi yazımıza bakabilirsiniz.
Banka tarafında geçen yıl şöyle bir durumla karşılaştık: GHAS vardı, Defender vardı (inanın bana). Defender’ın “Defender for Containers” planı kapalıydı; çünkü “pahalı” diye düşünmüşlerdi. Halbuki entegrasyonun runtime tarafı tamamen bu plana bağlıydı. İlk iş bu planı açtırdık, sonra entegrasyonu yaptık. Sonuç? Üç ayda can alıcı vulnerability backlog’u %62 azaldı. Çünkü artık gerçekten önemli olanları görmeye başlamışlardı.
Şöyle söyleyeyim, E tabi her kurum aynı değil. Küçük bir ekipseniz, mesela 5-10 geliştirici. Birkaç servis çalıştıran bir SaaS startup’ıysanız, bu entegrasyonun tam paketi sizin için overkill olabilir. Bütçeyi düşününce — GHAS $19/user/ay civarı, Defender for Containers da node başına ücretli — küçük ekiplerde maliyet biraz can sıkabiliyor. Onun yerine Trivy + Falco gıbı açık kaynak alternatiflerle başlayıp ekip büyüdüğünde bu tarafa geçmek daha mantıklı bence. Bu konuyla ilgili Microsoft Agent Framework: .NET’te Akıllı Ajan Devri yazımıza da göz atmanızı tavsiye ederim.
Peki neden?
Ama 50+ geliştiricili bir kurumsal yapıdaysanız ve finans/sağlık/telekom regülasyonlarıyla uğraşıyorsanız… bu entegrasyon kendini ödüyor diyebilirim. Compliance auditörlerine “şu can alıcı açık şu container’da, şu cluster’da; internete açık değil. 30 gün içinde patch’lendi” raporunu tek ekrandan vermek baya rahatlatıyor.
Kurmada Karşılaştığım Bir Tuzak
Setup’ı yaparken Microsoft’un dokümanlarındaki adımları takıp edin tabii ama bir noktada takılabilirsiniz. Ben preview döneminde takılmıştım: GitHub organization’ını Defender’a bağlarken, eğer organization’da SSO zorunluysa Defender’ın service principal’ına SAML authorization vermeniz gerekiyor. Bu adım dokümanda biraz gömülü kalmış; gözden kaçabiliyor.
Aldığım hata şuydu (aşağı yukarı): hemen tanıyorsunuz zaten böyle şeyleri.
Error: Unable to fetch repository metadata.
Reason: SAML SSO authorization required for service principal.
Action: Authorize the Microsoft Defender for Cloud app in your GitHub org SSO settings.Bilmem anlatabiliyor muyum, Çözümü basit. Bilmek lazım: GitHub Org → Settings → Authentication security → SSO → Defender app’ını whitelist’e alın (kendi tecrübem). Bu adımı atlarsanız attestation’lar görünmüyor ve “neden runtime context gelmiyor?” diye saatlerce uğraşıyorsunuz. Bana sorarsanız Microsoft bunu setup wizard’ında daha net göstermeliymiş. Daha fazla bilgi için SQL MCP Server’ı App Service’te Çalıştırmak: Container’sız yazımıza bakabilirsiniz.
Aşama Aşama Aktif Etme Rehberi
- Önkoşulları kontrol edin: GHAS lisansı olsun, Defender for Containers planı aktif olsun ve GitHub Actions kullanılıyor olsun. — ciddi fark yaratıyor
- Artifact attestation’ı açın: Build workflow’unuza
actions/attest-build-provenance‘i ekleyin. - Defender connector’ını kurun: Defender for Cloud → Environment Settings → Add → GitHub yolunu izleyin.
- SOS authorization’ını yapın:, yukarıdaki tuzağa düşmeyin yanı.
- Birkaç gün bekleyin:, korelasyon hemen oluşmuyor; runtime context’in gelmesi 24-48 saat alabiliyor.
- Filtreleri test edin:, Organization → Security → Code scanning alerts →
has:deployment.
Bu arada attestation tarafında yeniyseniz Markdown Rehberi: GitHub’da Sıfırdan Profesyonel README’ye yazımdaki workflow örnekleri başlangıç için iyi bir referans olabilir.
Copilot Coding Agent ile Otomatik Çözüm
Bunu yeterince konuşmadık galiba — filtreleyip kritik alert’leri bulduktan sonra doğrudan o issue veya campaign’i Kodub Copilot coding agent’a atayabiliyorsunuz yok yok yanlış öldü…
Sıkça Sorulan Sorular
Defender for Cloud-GHAS entegrasyonu için ekstra lisans lazım mı?
Hayır, entegrasyonun kendisi ücretsiz. Yanı sadece GitHub Advanced Security ve Defender for Containers (veya Defender CSPM) lisanslarınız aktifse yeterli. Bu iki servisi zaten kullanıyorsanız aslında hiç ek maliyet yok.
AWS ve GCP’de de çalışıyor mu bu entegrasyon?
Kısmen çalışıyor. Hani Defender for Cloud multi-cloud destekliyor, ama GHAS entegrasyonunun runtime context tarafı en olgun hâliyle Azure’da işliyor. AWS EKS ve GCP GKE’de temel — ki bu tartışılır — attestation eşleştirmesi var — ancak mesela network exposure gıbı bazı sinyaller henüz tam gelişmemiş. Roadmap’te iyileştirme var, yanı zamanla düzelecek.
Artifact attestation kurmadan da çalışır mı?
Çok kısıtlı çalışıyor açıkçası. Attestation olmadan Defender, container image’ları SHA tabanlı eşleştirmeye çalışıyor —. Bu yöntem pek güvenilir değil. En çok da multi-stage build’lerde yanlış eşleşmeler verebiliyor. actions/attest-build-provenance‘i mutlaka ekleyin, bence bunu ertelemenin hiçbir mantığı yok. — 5 satırlık bir iş.
Runtime context ne kadar sürede güncelleniyor?
Garip gelecek ama, Yeni deployment’larda ortalama 6-12 saat sürüyor, bazen 24 saate kadar uzayabiliyor. Microsoft bu süreyi kısaltacaklarını söyledi. Yanı “has:deployment” filtresi yeni deploy ettiğiniz servisi hemen göstermiyorsa paniklemeden biraz bekleyin — tecrübeme göre sabah deploy ettiyseniz akşama yansımış oluyor genelde.
Küçük ekipler için bu entegrasyon mantıklı mı?
Açıkçası 5-10 geliştiricili ekipler için maliyet/fayda dengesi biraz zayıf kalabiliyor. GHAS ve Defender for Containers lisansları bir arada ciddi bir aylık maliyete ulaşabiliyor. Bence bu boyuttaki ekipler için Trivy, Grype, Falco gıbı açık kaynak araçlarla başlayıp ekip 30+ kişiye ulaştığında bu entegrasyona geçmek çok daha akıllıca. Ama compliance zorunluluğunuz varsa — yanı PCI, HIPAA gıbı şeyler — o zaman boyut fark etmeksizin değer katıyor (ben de ilk duyduğumda şaşırmıştım)
Kaynaklar ve İleri Okuma
Microsoft Defender for Cloud — GitHub Advanced Security Integration Documentation
Bi saniye — GitHub Artifact Attestations Documentation
GitHub Blog — Code-to-cloud Risk Visibility GA Announcement
Bak şimdi, Defender for Cloud DevOps Posture Management — Concept Overview
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.
