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.
📋 İçindekiler
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.
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ı.
Bunu biraz açayım.
| Senaryo | Ne Yapmalı? | Neden? |
|---|---|---|
| Küçük startup | Ayarı açın, temel bildirimleri kurun | Düşük operasyon yüküyle hızlı kazanım sağlar |
| Büyük enterprise | Ayar + ownership + raporlama süreci kurun | Sahipsiz riskleri görünür kılar |
| Düzenlemeye tabi sektör | Ayrı denetim kaydı tutun | Uyumluluk ve izlenebilirlik için gerekli olur |
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.
- İ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!
Bende neden önemli yere oturdu?
Cevabı basit aslında: çünkü güvenlik olgunluğu çoğu zaman parlak dashboard’lardan değil, unutulan kenar köşelerden anlaşılır. GitHub’ın bu hamlesi bana tam da bunu hatırlattı. Biraz mütevazı,
biraz sessiz,
ama iş görüyor. Bence iyi yanı şu:
sizi sürekli manuel kontrol yükünden kurtarıyor. Eksik yanı şu:
organizasyonel disiplin yoksa tek başına yetmiyor. Yanı teknolojiyi aldınız diye problem çözülmüş olmuyor;
insan tarafını da düzeltmek gerekiyor. Bu konuda %100 doğru olmayabilir. Sanırım birçok kurumun tökezlediği yer tam burasıdır..
Eğer bugün uygulamaya başlamak istiyorsanız ilk işi küçük yapın:
önce hangi repolar hareketsiz önü görün,
sonra default setup durumunu kontrol edin,
ardından global policy’yi açıp çıktıları takip edin.
Gerisi gelir.
Hem de sandığınızdan hızlı gelir…
Sıkça Sorulan Sorular
Peki inactive repository tam olarak ne demek?
Son 6 aydır hiç push veya pull request almayan depolar inactive sayılıyor. GitHub bu depolar için periyodik code scanning’i otomatik olarak yeniden devreye sokuyor.
Bu özellik tüm repolarda mı çalışır?
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
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.
2 comments