GitHub’da Güvenlik Sekmesi Değişti: Kalite de Eklendi
Bakın, GitHub’da bir şey öldü ve ilk bakışta “e ne var bunda, işim değiştirmişler” diyeceksiniz. Ben de öyle düşündüm açıkçası. Ama sonra biraz kurcalayınca, arka planda dönen büyük resmî fark ettim. Repository, organization. Enterprise seviyesinde yıllardır gördüğümüz “Security” sekmesi artık “Security & quality” öldü. Sadece bir etiket değişikliği gibi görünüyor. Mantıklı değil mi? İşin aslı şu ki — GitHub, kod kalitesi ile güvenliği aynı çatı altında birleştirme yolunda ciddi bir adım attı.
Bakın, 2022’den beri GitHub’ın güvenlik tarafındaki iyileştirmelerini yakından takip ediyorum. Hani Dependabot, CodeQL, secret scanning derken ciddi bir ekosistem oluştu. Ama hep bir eksiklik vardı: kod kalitesi bulguları bambaşka bir yerde yaşıyordu, güvenlik alertleri bambaşka bir yerde. Şimdi bunlar tek noktada buluşuyor. Bence bu, düşündüğümüzden daha büyük bir hamle.
Tam Olarak Ne Değişti?
Lafı gevelemeden söyleyeyim: değişiklik görsel olarak küçük ama yapısal olarak önemli. Şu tabloya bir göz atın, ne değişip ne değişmediğini net göreceksiniz:
| Eski Hali | Yeni Hali | Açıklama |
|---|---|---|
| Security sekmesi | Security & quality sekmesi | Repo, org ve enterprise seviyesinde |
| Vulnerability alerts (sidebar) | Findings | Daha geniş detaylı bir isimlendirme |
| Yok | Code quality bölümü (sidebar) | Enablement status gösteriyor |
| Policy (sidebar) | Security policy | Daha açıklayıcı isimlendirme |
| URL’ler ve API’ler | Aynı kalıyor | Bookmark, script, entegrasyon bozulmuyor |
“Vulnerability alerts” ifadesinin “Findings” olması bence çok mantıklı bir adım. Çünkü artık sadece güvenlik açıkları değil, kod kalitesi ile ilgili bulgular da burada listelenecek. Mantıklı değil mi? Hani bir şemsiye terim lazımdı, “Findings” tam oturuyor.
Araya gireyim: Ha bir de sidebar’a eklenen “Code quality” bölümü var. Şu anda sadece enablement status — yanı aktif mi değil mi — gösteriyor. Ama bu, ileride çok daha fazla veri barındıracak bir bölümün ilk tohumları. Bunu görmezden gelmeyin.
Neden Bunu Önemsiyorum?
Yanı, Geçen ay Logosoft’ta bir e-ticaret müşterisi için güvenlik denetimi yapıyorduk. Şirketin GitHub’da 40’a yakın reposu var. Dependabot alertleri bir yerde, CodeQL bulguları bir yerde, kod kalitesiyle ilgili sorunlar SonarCloud’da ayrı bir dashboard’da… Ekip lideri “ben hangisine bakacağımı bile bilemiyorum” dedi (yanlış duymadınız). Mantıklı değil mi? Haklı da.
Şunu fark ettim: İşte GitHub’ın bu hamlesi tam olarak bu problemi çözmeye yönelik. Güvenlik ve kalite bulgularını tek bir yerden triaj edebilmek — bu küçük bir startup için belki “eh, zaten ben her şeyi biliyorum” denilebilir ama 20-30 kişilik ve üstü geliştirme ekiplerinde ciddi zaman kazandırıyor.
2024’te bir bankacılık projesinde benzer bir konsolidasyon ihtiyacı yaşamıştık. O zamanlar Azure DevOps tarafında güvenlik bulgularını tek bir panelde toplamak için özel dashboard’lar kurmuştuk. GitHub’ın bunu native olarak yapması… açık konuşayım, geç kaldılar ama doğru yapıyorlar.
Güvenlik ve kod kalitesi aynı madalyonun iki yüzü. Bunları ayrı ayrı yönetmeye çalışmak, bir evin kapısını kilitleeyip pencereyi açık bırakmaya benziyor.
GitHub Code Quality GA’sına Giden Yol
Dur bir saniye, asıl mevzuyu atlayacaktık neredeyse. Bu navigasyon değişikliği aslında tek başına bir olay değil. GitHub’ın yakında genel kullanıma açacağı “GitHub Code Quality” ürününün altyapısını hazırlıyor. Yanı biz şu anda sadece işim değişikliği görüyoruz ama arka planda çok daha büyük bir şey pişiyor (kendi tecrübem)
GitHub Code Quality — henüz GA olmadı. Beta’sından anlayabildiğim kadarıyla — SonarQube veya SonarCloud’un yaptığı işlerin bir kısmını GitHub native olarak yapacak. Code smell tespiti, duplicated code analizi, complexity metrikleri… Bu tarz şeyler. Şu an için sadece enablement status görüyoruz sidebar’da ama GA geldiğinde orada çok daha fazla veri olacak.
Araya gireyim: Hmm, bir düşüneyim… Bu SonarQube’ü tamamen bitirir mi? Sanmıyorum. Ama özellikle küçük-orta ölçekli takımlar için “bir tane daha araç entegre etme” derdini ortadan kaldırabilir. Zaten GitHub Advanced Security lisansı olan enterprise müşteriler için bu ekstra bir maliyet olmayacaksa — ki büyük ihtimalle GHAS paketinin parçası olacak — bayağı cazip bir teklif.
Çok konuştum, örnekle göstereyim.
Enterprise Server’da Henüz Yok
Bak bir de şunu söyleyeyim: bu değişiklik şu an sadece github.com’da aktif. GitHub Enterprise Server (GHES) kullanan kurumlarda henüz yok. Bu da şaşırtıcı değil aslında, GHES neredeyse her zaman birkaç ay geride kalıyor. Ama eğer on-prem GHES kullanıyorsanız — ki Türkiye’deki finans ve kamu sektöründe çok yaygın — bu özelliği görmek için biraz daha beklemeniz gerekecek (şaşırtıcı ama gerçek)
2025 başında bir telekom müşterimiz GHES 3.12’ye geçiş yapmıştı, o zaman bile bazı güvenlik özellikleri henüz gelmemişti. GHES kullanıcıları için bu artık alışılmış bir durum maalesef.
Pratik Olarak Ne Yapmanız Gerekiyor?
Kısa cevap: hiçbir şey. Evet, ciddi söylüyorum. Copilot Cloud Agent İçin Kurumsal Firewall: Kontrol Sizde yazımızda bu konuya da değinmiştik.
URL’ler değişmedi. API endpoint’leri aynı. Bookmark’larınız çalışıyor. CI/CD pipeline’larınızda GitHub Security API kullanan scriptleriniz varsa, onlar da sorunsuz devam edecek. GitHub bu konuda bayağı dikkatli davranmış, breaking change yok.
Ama — gel gelelim asıl meseleye — yapmanız gereken bir şey var: ekibinizi bilgilendirmek. Geçen hafta kendi takımımda bile “ya Security sekmesi nereye gitti?” diyen birisi öldü. İsim değişikliği küçük gibi görünse de, insanlar alışkanlık canlısı. Bilhassa GitHub’a yeni başlayan junior geliştiriciler için eski dokümantasyonlarla yeni arayüz arasında kafa karışıklığı olabilir. Daha fazla bilgi için GPT-5.1 Codex Modelleri Emekli Öldü: Ne Yapmalısınız? yazımıza bakabilirsiniz.
Otomasyon Kullananlar İçin Kontrol Listesi
Küçük bir detay: Yine de temkinli olmakta fayda var. Ben şu kontrolleri yaptım, sız de yapabilirsiniz:
- GitHub API çağrılarınızda
/security-advisoriesveya/code-scanning/alertsendpoint’lerini kontrol edin — bunlar değişmedi - Dependabot webhook’larınız aynen çalışmaya devam ediyor
- Eğer UI scraping yapan (kötü fikir ama yapanlar var) bir aracınız varsa, CSS selector’lar değişmiş olabilir — bunu test edin
- Actions" data-glossary-term="GitHub Actions">GitHub Actions workflow’larında güvenlik step’leri etkilenmemiş
Bir arkadaşım UI scraping ile güvenlik raporu çekiyordu — evet, API varken, evet biliyorum — geçen hafta “bozuldu” diye yazdı. Sebep tam olarak bu navigasyon değişikliği. API kullanın, kendinize eziyet etmeyin.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Daha fazla bilgi için değişti konusundaki yazımız yazımıza bakabilirsiniz.
Büyük Resim: GitHub’ın Güvenlik Stratejisi Nereye Gidiyor?
Son bir yılda GitHub güvenlik tarafında inanılmaz yoğun bir tempo tuttutdu. Secret scanning genişledi (GitHub Secret Scanning Büyüdü: Yeni Detektörler, Daha Az Sızıntı yazımda detaylı anlattım), CodeQL autofix geldi, Copilot güvenlik önerileri sunmaya başladı… Şimdi bir de kod kalitesini aynı şemsiye altına alıyorlar.
Bence GitHub’ın uzun vadeli hedefi şu: geliştiricinin IDE’den çıkmadan — hatta GitHub arayüzünden ayrılmadan — hem güvenlik hem kalite hem de compliance ihtiyaçlarını tek yerden yönetmesi. “Inner loop” dediğimiz geliştirici döngüsünü mümkün olduğunca kısa ve verimli tutmak istiyorlar.
Bu strateji SonarQube, Snyk, Checkmarx gibi üçüncü parti araçları doğrudan tehdit ediyor mu? Kısmen evet. Ama bu araçların yıllardır biriktirdiği rule set derinliği, custom rule yazabilme esnekliği ve özellikle enterprise compliance raporlama yetenekleri hâlâ çok güçlü. GitHub’ın native çözümü “yeterince iyi” olacak mı, yoksa “en iyi” mi olacak — bunu GA’dan sonra göreceğiz.
Az önce “SonarQube’ü bitirir mi” dedim ama aslında daha doğru soru şu: küçük ve orta ölçekli takımlar için SonarQube’e ihtiyaç kalır mı? Bence o tarafta ciddi bir erozyon olacak. Enterprise tarafında işe SonarQube ve benzerleri daha uzun süre yerini koruyacak.
CodeQL Autofix ile Birlikte Düşünmek
Şimdi gelelim benim en merak ettiğim noktaya. Bu “Security & quality” sekmesi, CodeQL Autofix Raporları Artık Daha Gerçekçi yazımda bahsettiğim autofix yetenekleriyle birleşince ortaya çok ilginç bir senaryo çıkıyor. Düşünün: hem güvenlik açığını hem kod kalitesi sorununu tespit et, ikisini aynı panelde göster,. İkisi için de otomatik fix öner. Bu tam bir “developer experience” hamlesi. Daha fazla bilgi için Gemini API’de Maliyet ve Hız Dengesi: Flex ile Priority yazımıza bakabilirsiniz.
2025 sonunda bir finans kuruluşunda CodeQL’i aktif etmiştik. İlk hafta 340 bulgu geldi. Ekip “bu kadar alertle ne yapacağız” dedi. Triaj süreci acayip uzun sürdü çünkü güvenlik ve kalite bulguları farklı yerlerdeydi. Burada, şimdi bunlar tek yerde olsa, o 340 bulguyu kategorize etmek çok daha kolay olurdu — itiraf edeyim, beklentimin üstündeydi —
Beklentilerim ve Hayal Kırıklıklarım
Şahsen, Açık konuşayım: bu güncelleme beklediğim kadar derin değil. Şu an sadece navigasyon değişti. Yanı gerçek anlamda “kod kalitesi” verisi henüz o sekmenin içinde yok — sadece enablement status var. Bu biraz “vitrin hazır ama mağaza henüz açılmadı” hissi veriyor. Bu konuyla ilgili Visual Studio’da Copilot Mart 2026: Ajan Devrimi yazımıza da göz atmanızı tavsiye ederim.
Şöyle ki, GitHub’dan beklentim şu: Code Quality GA olduğunda, o sidebar’daki “Code quality” bölümünde complexity metrikleri, code coverage oranları, duplicated code yüzdeleri gibi somut veriler görmek istiyorum. Sadece “aktif/pasif” göstermek yetmez. Eğer bu seviyeye ulaşırlarsa, gerçekten ciddi bir hamle olur. Yoksa sadece kozmetik bir düzenleme olarak kalır.
Bir dakika — bununla bitmedi.
Bir de GHES tarafı… Türkiye’deki kurumsal müşterilerin önemli bir kısmı GHES kullanıyor. Bu özelliğin GHES’e ne zaman geleceğine dair net bir tarih yok. Bu beni rahatsız ediyor çünkü müşterilerime “yakında gelecek” demekten yoruldum.
Sıkça Sorulan Sorular
Bu değişiklik mevcut scriptlerimi veya entegrasyonlarımı bozar mı?
Hayır. Tüm URL’ler ve API endpoint’leri aynı kalıyor. Bookmark’lar, CI/CD scriptleri ve webhook entegrasyonları aynen çalışmaya devam ediyor. Sadece arayüzdeki sekme ismi ve sidebar etiketleri değişti.
GitHub Enterprise Server’da bu değişiklik ne zaman gelecek?
Bence, Şu an sadece github.com’da aktif. GHES için henüz resmî bir tarih açıklanmadı. Genellikle GHES güncellemeleri 2-4 ay gecikmeyle geliyor, ama Code Quality GA’sına bağlı olarak bu süre değişebilir (en azından benim deneyimim böyle)
“Findings” ile “Vulnerability alerts” arasında ne fark var?
İşin garibi, “Findings” daha geniş etraflı bir terim (ben de ilk duyduğumda şaşırmıştım). Eskiden sadece güvenlik açıklarını kapsayan “Vulnerability alerts” yerine artık hem güvenlik hem kod kalitesi bulgularını içeren bir şemsiye kavram kullanılıyor (yanlış duymadınız). Veri içeriği şimdilik aynı ama Code Quality GA’sıyla genişleyecek.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bu değişiklik GitHub Advanced Security lisansı gerektirir mi?
Size bir şey söyleyeyim, Navigasyon değişikliğinin kendisi pek çok kullanıcılara açık (inanın bana). Ama Code Quality’nın GA olduğunda hangi lisans paketine dahil olacağı henüz netleşmedi. Büyük ihtimalle GHAS paketi içinde olacak ama ücretsiz bir katman da sunulabilir.
SonarQube veya benzeri araçları bırakmalı mıyım?
Bakın, şu an için neredeyse kesinlikle hayır. Neyse, gitHub Code Quality henüz GA bile olmadı. Mevcut araçlarınızı kullanmaya devam edin, GA olduktan sonra karşılaştırma yapıp karar verin. Mesela custom rule ihtiyacı olan enterprise ekipler için üçüncü parti araçlar hâlâ daha güçlü.
Kaynaklar ve İleri Okuma
GitHub Blog: The Security tab is now Security & quality
Şöyle söyleyeyim, GitHub Docs: GitHub Security Features
GitHub Docs: About Code Scanning
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