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ı.
📋 İçindekiler
-
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.
💡 Pratik İpucu: Eğer kurumsal bir GitHub org yönetiyorsanız, bu değişikliği internal wiki veya Slack kanalınızda kısa bir duyuruyla paylaşın. “Security sekmesi artık Security & quality öldü, URL’ler aynı, panik yok” — bu kadar yeter.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
- 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.
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.
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.
Şö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
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz. - GitHub API çağrılarınızda
Deniz R.
Tam da geçen hafta bir projenin security sekmesini karıştırıyordum, değişikliği fark etmemiştim. Güvenlik ve kalite bulgularının aynı yerde olması gerçekten mantıklı bir karar, ikisi zaten birbirinden ayrılamaz. Bu arada şu yazınız da güzeldi: Gemini API’de Maliyet ve Hız Dengesi: Flex ile Priority — https://www.askinkilic.com.tr/gemini-apide-maliyet-ve-hiz-dengesi-flex-ile-priority/
Yasemin İ.
Aslında bu tür küçük görünen UI değişikliklerinin arkasında büyük bir felsefi dönüşüm var. GitHub’un güvenliği ve kaliteyi aynı çatı altında toplaması, “güvenli kod = kaliteli kod” anlayışının artık araç seviyesinde de karşılık bulduğunu gösteriyor. Bakalım ilerleyen sürümlerde bu sekmeye neler daha eklenecek.
Yorumlar kapalı.








2 comments