GitHub’ın Unuttuğu Depolar İçin Güvenlik Kontrolü: Bence Asıl Mesaj Bu

Küçük bir detay: Geçen ay bir müşteride, İstanbul’da küçük ama büyümeye açık bir yazılım ekibiyle konuşurken tam bu konuyu tartıştık: “Aktif olmayan repo’ya kim bakacak?” Hani şu herkesin biraz geriye yaslanıp unuttuğu, ama bir gün üretimle bağlantısı olan eski depo… İşin aslı şu ki, güvenlik ekipleri çoğu zaman canlı projelere odaklanıyor; eski repolar işe arka rafta tozlanıyor. GitHub’ın yeni adımı da tam oraya dokunuyor.

Yanı, Bu değişiklik, inactive repositories için her 30 günde bir otomatik code scanning çalıştırmayı açıyor (ben de ilk duyduğumda şaşırmıştım). Kâğıt üstünde basit görünüyor. Pratikte işe baya iş görüyor, hatta bazen insanın içini rahatlatıyor. Mesela enterprise tarafta yüzlerce depo varsa, “bu repo artık kullanılmıyor” cümlesi çoğu zaman “kimse bakmıyor” anlamına geliyor. Ve açık konuşayım, güvenlik açısından en sevmediğim cümlelerden biri de bu.

Neden şimdi konuşuyoruz?

Kendi deneyimimden konuşuyorum, Çünkü güvenlikte en büyük risk bazen hareket eden sistem değil, duran sistem oluyor. Çalışmayan ama erişilebilir kalan bir repo, tıpkı kapısı kilitli sanılan ama anahtarı ortada duran eski bir ofis dolabı gibi… İçinde ne olduğunu unutuyorsunuz, sonra biri gelip içinden işinize yarayacak dosyayı alırken sız fark etmiyorsunuz bile. Peki neden? Çünkü gözünüz canlı işlerde oluyor, ölü sandığınız alanlar işe sessizce yerinde dürüyor.

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

Ben bunu ilk kez 2019’da bir hosting firmasındaki taşınma projesinde gördüm. Onlarca Git deposu vardı; aktif olanlar belliydi ama bazı arşiv repolarına yıllardır kimse dokunmamıştı. Bir güvenlik taraması sırasında o eski repolardan birinde yanlışlıkla commit edilmiş bir token yakalandı. Sorun şuydu: Repo “ölü” sanılıyordu ama erişim hâlâ açıktı (ki bu çoğu kişinin gözünden kaçıyor). Evet, insan böyle durumlarda ister istemez durup düşünüyor… Biz neyi unutmuşuz? Sonra da insan biraz sinirleniyor tabiî (inanın bana)

GitHub’ın getirdiği mantık burada çok sade: Eğer son 6 aydır push ya da pull request yoksa ve depo inactive sayılıyorsa, yine de düzenli taransın. Her 30 günde bir. Bence doğru yönde atılmış bir adım; ama tek başına sihir değil. Çünkü tarama var diye süreç disiplini otomatik gelmiyor.

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

Özellik tam olarak ne yapıyor?

Bunu teknik jargonla boğmadan anlatayım: Organizasyon seviyesinde açtığınızda sistem tüm repolara aynı gözle bakıyor (en azından benim deneyimim böyle). Aktif olanları zaten takip ediyoruz; yeni kural şunu diyor: “Duranları da unutma.” Böylece geçmişte geliştirilmiş ama artık el değmeyen kod tabanları da security coverage dışında kalmıyor (şaşırtıcı ama gerçek). Şey gibi düşünün; kapıyı sürekli açıp kapanan yere alarm kuruyorsunuz da arka odadaki pencereyi boş bırakmıyorsunuz.

Bir dakika, şunu da ekleyeyim: Bu ayar tüm organizasyona uygulanıyor. Yanı tek tek repo gezip uğraşmak yerine merkezî politika gibi çalışıyor. Kurumsal yapılarda ben buna bayılıyorum çünkü operasyon yükünü ciddi azaltıyor. Küçük ekiplerde işe başka avantajı var; unuttum gitti dediğiniz şeyleri sizden önce sistem hatırlatıyor.

Eski depo diye rahatlamak kolaydır; esas sürprizler genelde o depolarda çıkar.

Kime hitap ediyor?

Açık konuşayım, en çok kurumsal ortamlara hitap ediyor. Çünkü orada repository sayısı artınca görünürlük azalıyor, görünürlük azalınca risk yönetimi gevşiyor. Ama startup tarafında da işe yarar; özellikle hızlı büyüyen ekiplerde “geçici” açılan depolar hiç de geçici kalmıyor. Sız ne dersiniz? Geçici açılan kaç repo gerçekten kapanmış oluyor?

Ben Logosoft tarafında bir finans kuruluşu projesinde buna benzer bir tablo gördüm (evet, doğru duydunuz). Ekipler feature branch ve proof-of-concept repolarını ayrı ayrı yönetiyordu; iki ay sonra kimsenin sahiplenmediği birkaç depo kaldı ortada. Security scan devredeydi ama aktif olmayanlara düzenli çalışma yapılmadığı için boşluk oluşuyordu. Sonradan politikayı merkezileştirince işler toparlandı.

Türkiye’de bunun karşılığı ne?

Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo biraz farklılaşıyor. Burada hâlâ birçok kurumda “repo yaşam döngüsü” konusu yeterince oturmuş değil. Yanı yeni proje açılıyor, PoC yapılıyor, teslim ediliyor… sonra arşive kaldırılıyor ya da öyle sanılıyor. Halbuki regülasyon baskısı artarken pasif kod tabanlarını da izlemek gerekiyor.

Şimdi gelelim işin can alıcı noktasına. Bu konuyla ilgili Discovery to Execution: Foundry’de Ajanları Toolbox ile Ölçeklemek yazımıza da göz atmanızı tavsiye ederim.

Maliyet tarafına da bakalım mesela. Azure ve GitHub dünyasında güvenlik araçlarının fiyatını TL bazında düşündüğünüzde, yönetimsiz bırakılan küçük açıklıkların faturası daha ağır çıkabiliyor. Bir lisans maliyetinden kaçayım derken olayın remediation kısmı katlanabiliyor — hem para hem itibar açısından hemen can sıkıcı hâle geliyor.

E tabi burada enterprise vs startup ayrımı önemli. Küçük ekipseniz bu özelliği açıp geçersiniz; işinizi görür, kafanız rahat eder. Büyük kurumsal yapıdaysanız işe bunu policy + audit + ownership modeliyle birlikte düşünmek lazım (şaşırtıcı ama gerçek). Yoksa sadece tarama yapmak yetmez; bulduğunuzu kimin düzelteceği de belli olmalı. Daha fazla bilgi için Teams’te Çalışan Ajanlar: İşin Olduğu Yerde Başlamak yazımıza bakabilirsiniz.

Bunu biraz açayım.

Bende bıraktığı his: iyi fikir ama eksik pişmiş tarafları var

Bu servis ilk duyulduğunda beklediğim kadar çarpıcı gelmedi doğrusu; hani öyle sahne ışığı altında parlayan bir yenilik değil gibi dürüyor olabilir. Ama pratikte çok kıymetli olduğunu kabul etmek lazım! Hele bir de security ekipleri için sessiz. Faydalı bir güncelleme bu.

Bununla birlikte bazı sınırlamalar gözüme çarpıyor. Bu konuyla ilgili .NET 11 ve Build 2026: Kaçırmamanız Gereken Oturumlar yazımıza da göz atmanızı tavsiye ederim.

• İlki şu: Sadece default setup ile çalışan repolara uygulanması bazı senaryolarda dışarıda kalan alanlar yaratabilir.

• İkincisi de organizasyon çapında her şeyi aynı fırçayla boyamak bazen fazla kaba kaçabilir.

İnanın, Kurumsalda her depo aynı önemde olmuyor sonuçta; bazıları prod’a yakın kilit kod taşıyor, bazıları sadece deneysel not defteri gibi dürüyor.

Kendi sahadan notum

2024’ün Kasım ayında Ankara’daki bir teknoloji şirketinde yaptığımız değerlendirmede eski mikroservis repolarından biri üzerinde zafiyet bulunduğunu hatırlıyorum. Tarama haftalık çalışıyordu. Bu ne anlama geliyor? Ilgili repo uzun süre hareketsiz kaldığı için gözden kaçmıştı deneme aşamasında bozuldu diyebilirim — işin aslı biraz can sıkıcıydı! Sonrasında periyodik kontrol mekanizmasını genişletince aynı sorun tekrar etmedi.

Zaten AZ-500 ve AZ-305 hazırlıkları sırasında öğrendiğim şeylerden biri şu öldü: Güvenlik sadece mevcut sistemi korumak değildir, bırakılmış alanları da kollamaktır.

Bir şey aktif görünmüyor diye risksiz olmuyor.

Tam tersine… bazen en sessiz alan en yüksek riski taşıyor.

Nasıl açılır? Nereden başlanır?

Düz anlatayım: Organizasyon ayarlarına giriyorsunuz, Advanced Security altındaki Global Settings bölümünden ilgili seçeneği etkinleştiriyorsunuz ve bitti sanıyorsunuz… ama aslında orada bitmiyor.Tabii ki hemen ardından raporlamayı ve sahipliği de netleştirmek gerekiyor.

# Mantık olarak yapılacaklar
1) Organization settings > Advanced Security > Global Settings
2) "Keep scheduled scans running every 30 days for inactive repositories" seçeneğini aç
3) Bildirimleri ilgili security ekibine yönlendir
4) Eski reposu olan takımlar için ownership ata
5) İlk ay çıkan uyarıları sınıflandır

• Sahipsiz repo listesini çıkarın.
• Kritik olanlarla arşiv olanları ayırın.
• Scan sonuçlarını doğrudan ticket akışına bağlayın. (bu kritik)
• Dört hafta içinde tekrarlayan bulguları ölçün.
• Kullanılmayan repoyu gerçekten kapatın veya arşivleyin.

Neyse uzatmayalım: İlk adım olarak önce repo envanterini temizleyin ardından politikayı açın derim ben.

Çünkü kirli envanterle güvenlik politikası kurmaya çalışmak — boş tenekeyi tokmaklamak gibi oluyor biraz.

Küçük ekip mi büyük kurum mu?

Küçük ekiplerde genelde hız önemli olduğu için basit çözüm daha iyi çalışır.

Ayarı açarsınız,
bildirım gelir,
gerekirse düzeltirsiniz.

Ama enterprise tarafta rol bazlı erişimle beraber exception yönetimi şart olur.

Mesela geçen sene İzmir’de görüştüğüm büyük bir üretim firmasında onlarca team vardı. Hepsi farklı standartta repo kullanıyordu.
Orada çözüm sadece security setting değildi;
yanına governance katmanı koyduk.
O katman olmasa system yine güzel görünürdü ama sürdürülebilir olmazdı.
Aynen öyle! Bu konuyla ilgili Azure Cosmos DB’de Vektörler Kendini Güncelliyor: AI Uygulamalarda Yeni Dönem yazımıza da göz atmanızı tavsiye ederim.

Hayır. Yalnızca code scanning default setup kullanan depolarda geçerli. Özel kurulmuş senaryolarda davranış farklı olabiliyor, yanı bunu göz önünde bulundurmakta fayda var.

Taramalar ne sıklıkla yapılır?

Ayar etkinleştirildiğinde inactive repository’ler her 30 günde bir taranıyor. Aslında bu oldukça makul bir süre; hani uzun süredir kimsenin dokunmadığı kod tabanları da böylece korunmuş oluyor.

Bunu açmak zor mu?

Açıkçası pek zor değil. Organization settings içindeki Advanced Security > Global Settings bölümünden kolayca etkinleştirebilirsin.
Bence asıl mesele teknik kısım değil, süreç kısmı; yanı sahiplik. Takip düzenini oturtmak oluyor.

Küçük ekipler için gerçekten gerekli mi?

Evet, kesinlikle. Çünkü küçük ekiplerde bile zamanla sahipsiz repo oluşabiliyor, tecrübeme göre bu çok daha sık yaşanıyor.
Hızlı büyüyen takımlarda mesela bu özellik düşük maliyetli bir güvenlik ağı gibi çalışıyor.

Kaynaklar ve İleri Okuma

GitHub Changelog — Periodic code scanning of inactive repositories

GitHub Docs — Code scanning default setup hakkında resmî dokümantasyon

GitHub Docs — Organization için global security settings yapılandırması

İlgili Yazılar

Bir şey dikkatimi çekti: Azure DevOps’tan GitHub’a Kesintisiz Geçiş: ELM ile Yeni Dönem

GitHub Copilot app: Ajanlarla Çalışmanın Yeni Düzeni

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

VS Code’da Kurumsal Eklenti Dönemi: Kontrol, Hız, Düzen6 Haz 2026

PowerToys 0.98: Yeni Düzen, Daha Hızlı Akış1 Haz 2026

Microsoft Agent Framework ile .NET’te Ajan Kurmanın İncelikleri4 May 2026

Teams Agent Kurulumu Artık Tek Komutla Tamam30 Nis 2026