GitHub’da Deployment Context: Repo ve Alert Yönetimi

Bence, Şunu açıkça söyleyeyim: güvenlik alertlerini önceliklendirmek, hele büyük yapılarda, insanın canını sıkıyor. Geçen ay bir finans kuruluşunda tam da buna takıldık. Dependabot 200’den fazla alert üretmişti ve ekip, hangisinin gerçekten production’da çalışan bir servise ait olduğunu anlamak için saatler harcıyordu. Hani düşünün — bir kütüphanede hayatı zafiyet var. O kütüphane sadece test reposunda kullanılıyor; aynı zafiyet, canlıda müşteri trafiği alan bir mikroserviste de var. İkisine aynı gözle mi bakacaksınız? Tabii ki hayır (yanlış duymadınız)

İşte GitHub’ın yeni duyurduğu “deployment context” özelliği bu işi biraz toparlamaya çalışıyor. Repo seviyesinde iki yeni yerleşik property ve güvenlik alert sayfalarında runtime risk bağlamı… Kağıt üstünde fena değil. Ama dur bir saniye — asıl soru şu: pratikte gerçekten iş görüyor mu? Benim ilk refleksim “eh, bakalım” öldü.

Deployable ve Deployed: İki Yeni Repo Property’si

Açıkçası, GitHub, repository’lere iki yeni built-in property ekledi: deployable ve deployed. Bunlar artifact. Deployment metadata’sından otomatik besleniyor, yanı elle “bu repo canlıda” diye bir yere not düşmenize gerek kalmıyor. Sistem zaten görüyor, işin güzel yanı da bu.

Kısa bir not düşeyim buraya.

Peki neden? Deployable demek “bu repodan bir artifact çıkabilir, deploy edilebilir” demek. Deployed işe “bu repo şu anda gerçekten bir ortama deploy edilmiş durumda” demek. Arada ince ama baya hayatı bir fark var. Bir repo deployable olabilir ama henüz hiçbir yere deploy edilmemiş olabilir; mesela yeni geliştirilen bir mikroservis düşünün, CI/CD pipeline’ı hazır, container image’ı build ediliyor (hatta testler de geçiyor olabilir), ama daha staging’e bile çıkmamış. Bu repoyu deployed olanlarla aynı sepete koymak pek mantıklı durmuyor.

Logosoft’ta bir telekomünikasyon müşterimizde tam olarak bu tarz bir sınıflandırma sıkıntısıyla uğraşıyorduk. 400’den fazla repo var, hangisi production’da aktif, hangisi arşivlenmiş ama silinmemiş, hangisi sadece deneme için açılmış — kimse net söyleyemiyordu. Manuel bir Excel tablosu tutuluyordu, inanabiliyor musunuz? 2025’te Excel’le repo takibi… Şey yanı, biraz yorucu bir yöntemdi. Neyse uzatmayayım, bu yeni property’ler o Excel dosyasını kenara itebilir.

Kendi deneyimimden konuşuyorum, Tam da öyle.

Filtreleme ve Ruleset Entegrasyonu

Bu property’lerin asıl işe yaradığı yer filtreleme ve policy tarafı. Organizasyon seviyesinde şunu yapabiliyorsunuz:

• Deployed olan büyük çoğunluk repolara otomatik olarak branch protection kuralları uygulama
• Deployable ama henüz deployed olmayan repolara farklı bir ruleset atama
• Compliance policy’lerini sadece canlıya çıkan repolara hedefleme
• Organizasyon dashboard’unda “şu anda canlıda olan repolar” diye filtreleme

Bak şimdi, benim en hoşuma giden kısım şu: bu property’ler deployment durumu değiştikçe otomatik güncelleniyor. Yanı bir servisi decommission ettiğinizde deployed property’si de düşüyor. Policy enforcement da buna göre şekil alıyor. Eskiden bunu yapmak için ya custom GitHub Actions yazıyordunuz ya da üçüncü parti bir araçla uğraşıyordunuz; açık konuşayım, ikisi de idare ederdi. Biraz el işi kokuyordu.

Bir şey dikkatimi çekti: Evet.

Neyse, çok dağıttım gibi öldü ama konu aslında basit: GitHub artık repo’nun neye uygun olduğunu ve gerçekten nerede yaşadığını daha net biliyor. Peki, sız ne dersiniz? Böyle bir ayrım size de mantıklı geliyor mu?

Runtime Risk Context: Alertler Artık Bağlam Taşıyor

Bu ikinci kısım, açık konuşayım, daha ilginç. Dependabot ve GitHub Code Scanning alert sayfalarında artık runtime risk bağlamı da görünüyor. Bir alert’i açınca, etkilenen artifact’ın deployment durumunu, hangi ortamda çalıştığını. Risk seviyesini tek bakışta seçebiliyorsunuz.

Bunu Türkiye’deki şirketler açısından düşününce tablo biraz tanıdık geliyor. Çoğu kurumsal müşterimde güvenlik ekibi ile geliştirme ekibi arasında ince değil, baya kalın bir kopukluk var; güvenlik ekibi alert’i görüyor, “kritik” deyip ticket açıyor, geliştirici de “abi bu repo 6 aydır kullanılmıyor, o servis kapandı” diye dönüyor, sonra iş başka bir ekibe gidiyor ve ping-pong uzayıp gidiyor. İşte runtime context tam burada devreye girip bu döngüyü kırabiliyor (en azından benim deneyimim böyle)

Bir güvenlik alert’ının gerçek riskini anlamak için sadece CVSS skoruna bakmak yetmez — o zafiyetin production’da, müşteriye açık bir serviste çalışıp çalışmadığını bilmek gerekir. GitHub’ın runtime context özelliği tam olarak bu eksik parçayı tamamlıyor.

Triage Sürecinde Somut İyileşme

Geçen yıl bir bankacılık projesinde güvenlik triage sürecini ölçmüştük. Ortalama bir can alıcı Dependabot alert’ının çözülme süresi 4.2 gündü; bunun yaklaşık %60’ı da “bu gerçekten canlıda mı” sorusunun cevabını aramakla geçiyordu. Hmm, bir düşününce mesele aslında çok net: neredeyse 2.5 gün sadece bağlam toplama var ortada. Runtime context ile bu sürenin en az yarıya inmesini bekliyorum,. Tabi %100 doğru olmayabilir; pratikte nasıl oturacağını biraz kullanım belirleyecek.

Bir dakika — bununla bitmedi.

Güvenlik ekibiniz artık alert listesini açtığında şöyle bir tabloyla karşılaşabilir:

alert test-sandbox

?

Kurumsal Yapılar vs Küçük Ekipler: Kim Nasıl Kullanmalı?

Size bir şey söyleyeyim, Açık konuşayım, bu özellik küçük ekiplerde biraz “olsa da olur” tarafında kalıyor. 10-15 reponuz varsa, hangi repo canlıda, hangisi testte, çoğu zaman zaten aklınızda dürüyor. Ama 100+ repo, 5+ ekip ve birden fazla deployment ortamı varsa? İşte orada iş değişiyor; açıkçası o noktada bu iş baya kurtarıcı oluyor.

Enterprise tarafında tablo daha net. Bir holding grubunda 15 farklı şirket düşünün, her birinin ayrı GitHub organizasyonu var ve ortak güvenlik ekibi bütün alertleri tek yerden izlemeye çalışıyor (evet, doğru duydunuz). Deployment context olmadan bunu nasıl yönetecekler? Manuel envanter listeleri, spreadsheet’ler, belki bir CMDB entegrasyonu (ama onun da bakımı ayrı dert), yanı kısacası sürekli el isteyen çözümlerle uğraşıyorsunuz. .NET ve .NET Framework Nisan 2026 Güvenlik Yama… yazımızda bu konuya da değinmiştik.

Türkiye Özelinde Bir Gözlem

Türkiye’deki kurumsal müşterilerde benzer ama biraz daha karışık bir resim görüyorum. Çünkü birçok şirket hâlâ GitHub Enterprise Cloud yerine self-hosted tarafta kalıyor; regülasyonlar, veri lokalizasyonu kaygıları derken iş uzuyor. Bilhassa bankacılıkta ve kamu tarafında bu yaklaşım yaygın. Bu yeni özellikler şimdilik GitHub.com üzerinde GA (Generally Available),. Enterprise Server’a ne zaman gelir, doğrusu henüz belli değil (inanın bana). Ha bu arada, GitHub Secret Scanning API ve Webhook İyileştirmeleri yazımda da buna benzer bir GHES gecikmesinden söz etmiştim; GitHub çoğu zaman bu tip şeyleri 3-6 ay sonra GHES’e taşıyor.

Küçük bir startup için benim tavsiyem basit: Özelliği açın, arka planda dursun,. Sırf bunun için workflow’u baştan yazmayın. Zaten az repo var; yanı günlük hayatınızı kökten değiştirmesi gerekmiyor. Fakat büyüme başladığında elinizde hazır bir zemin olmuş olur. MSVC 14.51 ile C++23 Desteği: Sahadan Notlar yazımızda bu konuya da değinmiştik.

Pratik Uygulama: İlk Adımlar

Dürüst olmak gerekirse, Tamam, teori güzel de pratikte ne yapacağız? Şimdi adım adım gidelim. Peki neden bu kadar uğraşıyoruz? Çünkü işin özü, küçük bir eksik yüzünden bütün akışın sessizce bozulabilmesi.

Şöyle ki, Önce artifact’larınızı production context ile eşleştirmeniz gerekiyor. GitHub Actions workflow’unuz deployment event’lerini doğru tetikliyorsa sistem bunu kendi kendine yakalıyor; (eh, fena değil). Sız ne dersiniz? Custom bir CI/CD pipeline kullanıyorsanız — mesela Azure DevOps ya da Jenkins — o zaman GitHub API üzerinden bu metadata’yı beslemeniz gerekecek, yoksa ortada çalışan bir deployment olsa bile GitHub tarafı bunu görmeyebiliyor. Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler… yazımızda bu konuya da değinmiştik.

# GitHub Actions workflow örneği — deployment context için
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
environment: production  # Bu satır kritik!
steps:
— uses: actions/checkout@v4
— name: Deploy
run: |
# deployment komutlarınız
echo "Deploying to production..."
— name: Verify deployment
run: |
# deployment doğrulama
curl -s https://api.myapp.com/health | jq.status

Burada environment: production satırı gerçekten kilit nokta. GitHub bu bilgiyi alıp repo’nun deployed property’sını güncelliyor; sız bunu koymazsanız özellik pat diye susuyor. Ben ilk kurcaladığımda environment tanımlamayı atlamıştım, sonra da “neden property güncellenmiyor” diye iki saat debug yaptım, hatta bir ara sorun bende değilmiş gibi düşündüm. Meğer mesele tek satırdaymış.

Şöyle ki, Bir de şunu ekleyeyim — bütçe tarafı sıkışıkysa ve GitHub Enterprise kullanmıyorsanız, bu özelliklerin bir kısmını GitHub Free ve Team planlarında da kullanabiliyorsunuz. Ama ruleset entegrasyonu ile organizasyon seviyesinde filtreleme işi biraz başka hikâye; orada Enterprise planına ihtiyaç duyuyorsunuz. Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle yazımda da güvenlik özelliklerinin plan bazlı farklarına değinmiştim, hani orası da ayrı bir dünya.

Eksik Kalan ve Beni Hayal Kırıklığına Uğratan Kısımlar

Her şey güllük gülistanlık değil tabi. Birkaç nokta beni dürttü, açık konuşayım.

Birincisi şu: multi-cloud deployment tracking yok. Yanı bir repo hem Azure’a hem AWS’ye gidiyorsa, hangi ortamda hangi versiyon dönüyor sorusuna net cevap alamıyorsunuz; sadece “deployed” ya da “not deployed” gibi iki uçlu bir bilgi var, bu da kurumsal tarafta biraz eksik kalıyor. GitHub Pages ile Ücretsiz Site Kurulumu: Tam Re… yazımızda bu konuya da değinmiştik.

Oysa bizim tarafta işin rengi başka. Çoğu müşteri multi-cloud kullanıyor, bazen de aynı uygulama üç ayrı yerde koşuyor; az önce “iyi fikir” dedim ama burada küçük bir fren var, çünkü bu kısıt pratikte baya can sıkıyor.

İkincisi — geçmiş deployment history yok. Property sadece anlık durumu gösteriyor, hepsi bu. “Bu repo 3 ay önce production’daydı. Şimdi değil” gibi bir izi göremiyorsunuz; audit yaparken, compliance kontrol ederken, hatta iç denetimde bile insanın eli boş kalabiliyor.

Evet.

Üçüncüsü işe Dependabot alert sayfasındaki runtime context kısmı fena değil, ama Code Scanning tarafı biraz ham dürüyor. CodeQL ile yakalanan bir zafiyet için “bu production’da” bilgisi geliyor, güzel;. Hangi endpoint’ten erişiliyor, public-facing mi yoksa internal mı gibi kritik detaylar ortada yok, yanı resim tam oturmuyor. Bu konuyla ilgili Ingress2Gateway 1.0: Ingress’ten Gateway API’ye… yazımıza da göz atmanızı tavsiye ederim.

Nasıl desem… burada veri var ama bağlam eksik. Biraz daha pişmesi lazım derken abartmıyorum; çünkü güvenlik ekipleri için asıl soru sadece “var mı?” değil, “nerede. Nasıl erişiliyor?” oluyor.

Bir bakıma, dürüst olmak gerekirse, Neyse uzatmayalım. Şu hâliyle iş görüyor ama bazı senaryolarda insanı yarı yolda bırakabiliyor.

FinOps ve Güvenlik Kesişimi: Gözden Kaçan Bir Açı

Şahsen, Bakın, burada ilginç bir nokta var. Bu özelliğin güvenlik tarafı konuşuluyor, ama FinOps tarafı nedense hep kenarda kalıyor.

İşin aslı şu: Azure’da maliyet optimizasyonu yaparken en çok kafamı kurcalayan şeylerden biri, “bu kaynak kime ait, hâlâ kullanılıyor mu” sorusu oluyor. GitHub tarafında da — en azından ben öyle düşünüyorum — tablo pek farklı değil; GitHub Advanced Security lisansı repo bazında ücretlendiriliyor. Eğer 500 reponuz varsa ama bunların sadece 200’ü gerçekten deployed durumdaysa, kalan 300 repo için boş yere GHAS lisansı ödüyor olabilirsiniz, işte deployment context tam burada devreye giriyor — itiraf edeyim, beklentimin üstündeydi —

2024’te bir e-ticaret müşterimizde bunu birebir yaptık. Manuel audit ile uğraştık, iki hafta sürdü, biraz yorucuydu açık konuşayım; deployed olmayan repoları GHAS scope’undan çıkarınca aylık yaklaşık 1.200 dolar tasarruf ettik. Şimdi aynı işi bu property’lerle otomatik hâle getirebiliyorsunuz. Fena değil, değil mi?

İtiraf edeyim, Ha, bir de şunu atlamayayım: GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazısında da GitHub’ın platform governance yaklaşımındaki değişimlerden bahsetmiştim. Bu deployment context meselesi de aynı çizginin devamı gibi dürüyor; yanı GitHub artık sadece kod tuttuğun bir yer olmaktan çıkıp, yavaş yavaş platform governance aracına dönüşüyor. Sız ne dersiniz?

Sıkça Sorulan Sorular

Deployment context özelliği için hangi GitHub planı lazım?

Temel deployment property’leri GitHub Free ve Team planlarda da görünüyor zaten. Ama organizasyon seviyesinde ruleset entegrasyonu, otomatik policy uygulaması. Gelişmiş filtreleme istiyorsanız Enterprise plana geçmeniz gerekiyor. GHAS alertlerindeki runtime context de aynı şekilde Enterprise’a özel bir özellik.

Deployed ile deployable arasındaki fark ne?

Deployable, hani bir repodan build edilebilir bir artifact çıkıyor demek — mesela container image ya da paket gibi şeyler. Deployed işe o artifact’ın şu an gerçekten aktif olarak bir ortamda çalışıyor olduğunu gösteriyor. İşte, yanı bir repo deployable olup deployed olmayabilir — CI pipeline’ı hazır ama henüz canlıya çıkmamış bir servis düşünün mesela.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

GHES’te de kullanılabiliyor mu bu özellik?

Tuhaf ama, Şu an sadece GitHub.com (Cloud) üzerinde GA durumda. GHES takvimi henüz açıklanmadı. Ama açıkçası GitHub’ın genel pratiğine bakarsak, bence 3-6 ay içinde GHES sürümlerine de gelir. Kesin tarih için GitHub’ın changelog’ünü takip etmenizi öneririm.

Jenkins veya Azure DevOps gibi araçlarla da çalışıyor mu?

Şöyle söyleyeyim, GitHub Actions dışında bir CI/CD aracı kullanıyorsanız, deployment bilgisini GitHub API üzerinden manuel olarak beslemeniz gerekiyor. GitHub’ın Deployments API’sını kullanarak deployment event’lerini bildirebilirsiniz. Tecrübeme göre biraz ekstra iş çıkarıyor ama aslında gayet yapılabilir bir şey.

Kısa bir not düşeyim buraya.

Runtime context alertleri otomatik kapatıyor mu?

Hayır. Runtime context yalnızca ek bilgi sunuyor — alertleri ne otomatik kapatıyor ne de önceliklendiriyor. Triage kararını hâlâ sız veriyorsunuz, ama artık çok daha iyi bir bağlamla karar verebiliyorsunuz. Bence bu bile başlı başına büyük bir fark. İleride auto-dismiss gibi şeyler gelebilir, ama şimdilik sadece görsel bağlam mevcut.

Kaynaklar ve İleri Okuma

GitHub Docs — Exploring Dependencies of a Repository (şaşırtıcı ama gerçek)

Bence, GitHub Blog — Deployment Context in Repository Properties and Alerts (Orijinal Duyuru)

GitHub REST API — Deployments

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

vcpkg'de Paralel Kurulum ve Güvenlik Yaması: Neler Değişti?6 Nis 2026

GitHub'da Güvenlik Sekmesi Değişti: Kalite de Eklendi5 Nis 2026

GitHub Actions Nisan 2026 Güncellemeleri: Üç Küçük Ama Etkili Hamle3 Nis 2026

Diff Satırlarını Hızlandırmak: Büyük PR’larda Sınır Nerede?5 Nis 2026