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. 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).
📋 İçindekiler
-
Türkiye Özelinde Bir Gözlem
Ne yalan söyleyeyim, 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,
İşin garibi, Oysa bizim tarafta işin rengi başka. Çoğu müşteri multi-cloud kullanıyor, bazen aynı uygulama üç ayrı yerde koşuyor; az önce “iyi fikir” dedim ama burada küçük bir fren var, çünkü bu kısıt sahada baya can sıkıyor ve insanın aklına hemen şu soru geliyor: Peki neden daha detaylı değil?
Çok konuştum, örnekle göstereyim.
İ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 eliniz boş kalabiliyor, biraz sinir bozucu yani (eh, fena değil)
Bakın, ne yalan söyleyeyim, Evet.
Üçüncüsü ise şu: Dependabot alert sayfasındaki runtime context kısmı fena değil,. Code Scanning tarafı biraz ham duruyor. CodeQL ile yakalanan bir zafiyet için “bu production’da” bilgisi geliyor, güzel; (inanın bana). Hangi endpoint’ten erişiliyor, public-facing mi yoksa internal mı gibi hayati detaylar ortada yok, yani resim tam oturmuyor.
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. Işin kritik kısmı da tam orada başlıyor.
Bir bakıma, dürüst olmak gerekirse bu hâliyle iş görüyor. Ama bazı senaryolarda insanı yarı yolda bırakabiliyor; yani kötü değil, sadece tam tamamlanmış hissi vermiyor (en azından benim deneyimim böyle)
FinOps ve Güvenlik Kesişimi: Gözden Kaçan Bir Açı
Bence, Bakın, burada küçük ama can sıkıcı bir detay var. Güvenlik konuşuluyor, tamam,. FinOps tarafı çoğu zaman arka cebeye atılıyor; işin aslı biraz da bu yüzden maliyetler sessizce şişiyor, sonra biri çıkıp “bu niye bu kadar tuttu?” diye soruyor.
Şahsen beni en çok kurcalayan şey şu: Azure’da maliyet optimizasyonu yaparken, “bu kaynak kime ait, hâlâ kullanılıyor mu” sorusu (kendi tecrübem) — dürüst olayım, biraz hayal kırıklığı —. GitHub tarafında da tablo (belki yanılıyorum ama) çok farklı değil gibi geliyor bana; GitHub Advanced Security lisansı repo bazında ücretlendiriliyor, yani 500 reponuz var ama sadece 200 tanesi gerçekten deployed durumdaysa, kalan 300 için boş yere lisans ödüyor olabilirsiniz — deployment context tam burada devreye giriyor, hem de beklediğimden daha anlamlı bir şekilde. Evet, böyle bir boşluk var.
Şöyle ki, 2024’te bir e-ticaret müşterisinde bunu birebir yaşadık. Manuel audit yaptık, iki hafta sürdü, biraz yorucuydu açık söyleyeyim; deployed olmayan repoları GHAS scope’undan çıkarınca aylık yaklaşık 1.200 dolar tasarruf ettik. Şimdi aynı işi (söylemesi ayıp) bu property’lerle otomatik hale getirebiliyorsunuz, hani insanın aklına “neden baştan böyle değildi?” sorusu geliyor. Fena değil.
Dürüst olmak gerekirse, İtiraf edeyim, burada başka bir bağlantı daha var: 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 (ben de ilk duyduğumda şaşırmıştım). Bu deployment context meselesi de aynı çizginin devamı gibi duruyor; yani GitHub artık sadece kod tuttuğun bir yer olmaktan çıkıp yavaş yavaş platform governance aracına dönüşüyor, hatta bazen fark etmeden FinOps kararlarını da etkiliyor. Siz ne dersiniz?
Sıkça Sorulan Sorular
Deployment context için hangi GitHub planı gerekiyor?
Hani, Temel deployment property’leri zaten Free ve Team planlarda da görünüyor. Ama organizasyon seviyesinde ruleset entegrasyonu, otomatik policy uygulaması, gelişmiş filtreleme istiyorsanız — bunlar için Enterprise’a geçmeniz gerekiyor. GHAS alertlerindeki runtime context de aynı şekilde Enterprise’a özel.
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 ise o artifact’ın şu — itiraz edebilirsiniz tabi — an gerçekten aktif olarak bir ortamda çalışıyor olduğunu gösteriyor. Şimdi, yani bir repo deployable olup deployed olmayabilir — CI pipeline’ı hazır ama henüz canlıya çıkmamış bir servis düşünün mesela.
Bir dakika — bununla bitmedi.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır (kendi tecrübem)
GHES’te de çalışıyor mu?
Tuhaf ama, şu an sadece GitHub.com (Cloud) üzerinde GA durumda. GHES takvimi henül açıklanmadı. 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?
Kısacası, ne yalan söyleyeyim, Şöyle söyleyeyim — GitHub Actions dışında bir CI/CD aracı kullanıyorsanız, deployment bilgisini GitHub API üzerinden manuel olarak beslemeniz gerekiyor (ben de ilk duyduğumda şaşırmıştım). GitHub’ın Deployments API’sını kullanarak deployment event’lerini bildirebilirsiniz. Siz ne dersiniz? 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â siz 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)
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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
İlginizi Çekebilir
Selin N.
Deployment context’i daha önce duymuştum ama deployable/deployed ayrımını tam anlamamıştım, şimdi oturdu. Özellikle çok servisi olan projelerde hangi alertin gerçekten kritik olduğunu bulmak ciddi zaman alıyordu, bu özellik o acıyı hafifletir gibi görünüyor. Bu arada farklı bir konuda olsa da şu yazınız da güzeldi: MSVC 14.51 ile C++23 Desteği: Sahadan Notlar — https://www.askinkilic.com.tr/msvc-1451-ile-c23-destegi-sahadan-notlar/
Merve Ş.
Deployment context ile güvenlik alertlerini önceliklendirme fikri çok mantıklı, özellikle onlarca servisi olan büyük organizasyonlarda hangi alertin gerçekten kritik olduğunu bulmak ciddi zaman kaybı oluyor. deployable/deployed property ayrımını pratikte nasıl yönetiyorsunuz, CI/CD pipeline’a entegrasyonu zor mu oluyor? Bu arada şu yazınız da güzeldi: Azure MCP Araçları Visual Studio 2022’de Yerleşik Geldi — https://www.askinkilic.com.tr/azure-mcp-araclari-visual-studio-2022de-yerlesik-geldi/
Yorumlar kapalı.
2 comments