GitHub Güvenliği: Küçük Repoda Büyük Açıkları Kapatmak
Bakın şimdi, GitHub güvenliği deyince çoğu kişinin aklına önce “bize bir şey olmaz” hissi geliyor. Hani repo daha yeni açılmıştır, birkaç klasör vardır, iki de bağımlılık eklenmiştir… Tam orada işler sarpa sarabiliyor. Çünkü açıkların çoğu sizin yazdığınız koddan değil, çekip aldığınız paketlerden, yanlışlıkla commit edilen sırlardan ya da gözden kaçan bir workflow dosyasından çıkıyor.
Ben bunu ilk kez 2018’de İstanbul’da bir e-ticaret projesinde çok net gördüm. Takım “bu sadece test ortamı” diyerek birkaç API anahtarını repoya gömmüştü. Sonra biri branch’i public fork’layınca iş büyüdü. O gün şunu kafama kazıdım: güvenlik, proje büyüyünce başlanan bir şey değil; en başta kuruluyor.
GitHub’ın son yıllarda bu işi bayağı kolaylaştırdığını söyleyebilirim. Secret scanning, Dependabot, code scanning, Copilot Autofix gibi araçlar sayesinde, özellikle küçük ekiplerde bile “gözden kaçtı gitti” türü riskleri erken yakalamak mümkün oluyor. Kağıt üstünde süper; pratikte işe bazen biraz ayar istiyor. Ama yine de iş görüyor.
Neden Güvenlik Meselesini Ertelememek Lazım?
İşin aslı şu ki, zafiyet dediğimiz şey sadece büyük kurumların derdi değil. Bir kütüphaneyi projeye dahil ettiğiniz anda onun riskini de az çok sırtlanıyorsunuz. Ben 2021’de Ankara’da bir fintech müşterisinde bunu birebir yaşadım: uygulama gayet temiz görünüyordu ama transitif bağımlılıklardan biri eski sürümde kalmıştı. CVE listesinde kırmızı yanıp sönüyordu. Kod sizinki değildi ama patlayan sız oluyordunuz.
Bu yüzden küçük startup ile enterprise arasında fark var ama temel mantık aynı. Startup tarafında genelde hız baskın oluyor; “önce ürün çıksın” deniyor. Enterprise tarafta işe süreçler ağır ilerliyor — ki bu tartışılır — ama en azından denetim var. Yine de her iki dünyada da ortak nokta şu: güvenlik kapıyı çalmıyor, içeri dalıyor.
GitHub Advanced Security burada devreye giriyor. Public repolarda bazı özellikler doğrudan kullanılabiliyor; private repolarda işe lisans konusu var. Bu ayrım önemli çünkü bazen ekipler ücretsiz olanla ücretli olanı karıştırıyor. Mesela secret scanning’i açıp bırakmak yetmiyor; uyarının nasıl ele alınacağını da önceden planlamak gerekiyor.
Açınca Ne Değişiyor? GHAS’ı Doğru Kurmak
GitHub repository ayarlarına girip Security bölümünden Advanced Security tarafını açtığınızda aslında oyunun kuralları değişiyor. Dependabot alerts ve security updates aktif olunca paket dünyasındaki riskleri daha erken görüyorsunuz. CodeQL analysis ile kodun içine gömülü riskler taranıyor. Secret Protection işe yanlışlıkla sızan anahtarları yakalamaya çalışıyor.
Ben AZ-500 çalışırken bu mantığı bulut tarafına çok benzetmiştim: ağda NSG neyse, repoda da security settings biraz o gibi davranıyor. Kapıyı açmazsanız hiçbir şey içeride dolaşamaz sanıyorsunuz ama gerçek hayat öyle değil; insanlar yine bir yol buluyor. Bu yüzden varsayılan ayarlarla yetinmemek lazım. Daha fazla bilgi için GitHub Issue Triage’ı Copilot SDK ile Akıllandırmak: Ben Olsam Böyle Kurardım yazımıza bakabilirsiniz.
| Özellik | Ne işe yarar? | Pratik not |
|---|---|---|
| Dependabot alerts | Zafiyetli paketleri bildirir | Küçük projelerde bile açıkları erken yakalar |
| Dependabot security updates | Düzeltme PR’ı açar | Tam otomatik değil; yine kontrol gerekir |
| CodeQL / code scanning | Kod desenlerini tarar | Bazen false positive verir, can sıkar |
| Secret scanning | Sızıntıları tespit eder | Asıl mesele revocation sürecidir |
Neyse uzatmayalım: bunları tek tek açmak teknik olarak kolay, zor olan taraf organizasyonel kısım. Kim bakacak? Uyarılar nereye düşecek? SLA ne olacak? Geçen yıl İzmir’de bir SaaS ekibiyle çalışırken tam bu noktada takıldık; araçlar açıktı ama uyarılar Slack’e düşmüyor, kimse düzenli bakmıyordu. Yanı araç vardı ama disiplin yoktu.
Küçük ekipte yaklaşım nasıl olmalı?
Küçük ekiplerde ben önce üç şeyi öneriyorum: secret scanning açık olsun, Dependabot PR’ları otomatik gelsin ve CodeQL temel seviyede çalışsın. Her şeyi aynı gün kusursuz yapmak zorunda değilsiniz. Önce görünürlük kazanın, sonra sertleştirin. Bu konuyla ilgili GitHub Copilot Kullanım Ölçümleri: CCA Artık Görünüyor yazımıza da göz atmanızı tavsiye ederim.
Büyük kurumda yaklaşım neden farklı?
Enterprise ortamda iş biraz daha bürokratik olur — kötü anlamda değil, kontrollü anlamda. Change management vardır, approval zinciri vardır, compliance baskısı vardır. O yüzden burada GHAS kurulumunu SOC/SecOps akışına bağlamak gerekir; yoksa uyarılar raf süsü olur. Visual Studio Aboneliğinde Gizli Güç: Syncfusion’ı Kaçırmayın yazımızda bu konuya da değinmiştik.
Sızan Sırların Peşinde: Secret Scanning ve Revocation
Açık konuşayım, secret scanning bana göre en kilit parçalardan biri. Çünkü hata yapılınca bedeli hızlı gelir. Bir API key’in repo içinde gezmesi bazen sessiz sedasız olur; ta ki biri önü kullanana kadar… İşte o an oyun biter.
Bir secret bulunduğunda ilk refleks “sil geç” olmamalı; asıl yapılacak iş o anahtarı iptal etmek ve nerelerde kullanıldığını takip etmek olmalı.
Bunu ben ilk kez Bursa’daki bir üretim firmasında yaşadım (2022 sonbaharıydı). Geliştirici arkadaş yanlışlıkla Azure erişim bilgilerini test branch’ine koymuştu. Secret scanning uyarısı geldiğinde herkes “tamam sileriz” dedi ama ben özellikle revocation’a bastırdım çünkü silmek tek başına yetmezdi — anahtar başka yerde kopyalanmış olabilir diye düşündüm ve haklı çıktık.
Revocation burada emniyet kemeri gibi düşünülmeli. Eski anahtarı iptal etmeden devam ederseniz saldırgan hâlâ içeride olabilir.
# Örnek akış
1) Alert'i aç
2) Secret'ın nerede bulunduğunu doğrula
3) İlgili token / key'i iptal et
4) Yeni secret üret
5) Uygulama konfigürasyonunu güncelle
6) Gerekirse geçmiş commit'leri temizle
7) Benzer sızıntılar için repo genelinde tarama yap
Kod Tarama ve Dependabot: Sessiz Riskleri Yakalamak
Dependabot’u sevmemin nedeni basit: sıkıcı işi alıyor ve masadan kaldırıyor. Paket sürümü eskimiş mi? Bildiriyor. Düzeltme PR’ı açıyor mu? Evet açıyor! Ama burada körü körüne merge etmek de ayrı bela olabilir.
Bir arkadaşım geçen martta Berlin’deki startup’ında Dependabot PR’larını otomatik merge etmeye başlamıştı; kulağa hoş geliyor biliyorum. Test suite yarıda kaldığı için prod’da minik bir regresyon çıktı (çok büyük değildi ama moral bozdu). O yüzden benim tavrım net: otomasyon güzel fakat kapalı kutu olmamalı.
- Kritik paketler: elle incelemeden merge etmeyin — ciddi fark yaratıyor.
- Düşük riskli güncellemeler: otomasyona daha uygun olabilir — bunu es geçmeyin.
- Büyük sürüm atlamaları: genelde test + review isteyin.
- Zincir bağımlılıklar: transitive dependency kontrolünü unutmayın.
Peki code scanning ne kadar güvenilir?
Kodu statik analizle taramak faydalı ama kusursuz değil. Bazen false positive çıkarıyor ve insanın canını sıkıyor; özellikle legacy kodlarda bu durum bayağı yorucu oluyor.
Ben AZ-305 hazırlığında mimarı tasarım düşünürken hep şunu hatırlıyorum: iyi analiz aracı size karar verdirmez, karar vermeyi kolaylaştırır. CodeQL de böyle çalışıyor aslında. Sinyal veriyor ama son sözü yine sız söylüyorsunuz.
Copilot Autofix gerçekten işe yarıyor mu?
Evet, bazı senaryolarda fena değil hatta bayağı işe yarıyor. Hele basit zafiyetlerde önerdiği düzeltmeler vakit kazandırabiliyor. Ama her öneriyi kutsal metin gibi görmek hata olur.
Geçen ay Logosoft’ta bir müşteride denedik; hızlıca çözülmüş görünen bir fix vardı ama edge-case testi yapılınca ek kontrol gerektiği ortaya çıktı. Yanı yardımcı evet, kurtarıcı bazen… ama tek başına yeterli değil.
Bölgeye Göre Değişen Gerçekler: Startup mı Enterprise mı?
Küçük startup ile kurumsal yapı arasında security kültürü aynı şekilde işlemiyor — zaten işlemesi de gerekmiyor belki de.
Startup tarafında hedef hızlı öğrenmek olduğu için minimum viable security yaklaşımı iyi sonuç verebilir. Mesela yalnızca public exposure azaltma ve dependency takibi bile büyük fark yaratır.
Ama enterprise tarafta işin içine governance girer; loglama, rol bazlı erişim ve onay mekanizmaları devreye girer. Burada mesele tool sayısı değil, uyumlu çalışma şekli.
Sahada Öğrendiklerim ve Pratik Tavsiyeler
Güvenlik aracını kurmak kolaydır, sürdürülebilir hâle getirmek zor kısmıdır. Ben kendi projelerimde genelde şöyle ilerliyorum: önce exposure alanlarını daraltıyorum, sonra alert sahiplerini belirliyorum, ardından da triage sürecini sadeleştiriyorum. Bu üçlü oturunca sistem rahatlıyor.
Buradaki asıl mesele şu: araçlar birbirine bağlı olsun, insanlar da ne yapacağını bilsin.
- Triage sahibi belirleyin: Uyarıya kim bakacak belli olsun.
- SLA tanımlayın: Kritik alert kaç saatte ele alınacak?
- Eğitim verin: Geliştirici secret ile config farkını bilmeli.
- Düzenli raporlayın: “Sadece araç” yaklaşımından kaçının.
Sıkça Sorulan Sorular
GitHub security features ücretsiz mi?
Evet, public repository’lerde bazı temel özellikler ücretsiz kullanılabiliyor. Private repo tarafında işe GitHub Advanced Security lisansı gerekebiliyor.
Secret scanning neyi yakalar?
API key’leri, token’ları, sertifikaları veya başka hassas bilgileri tespit etmeye çalışır. Yanlış pozitif çıkabilir ama ciddiye almak gerekir.
Copilot Autofix tek başına yeter mi?
Hayır. Bazı durumlarda hızlı yardım sağlar ama insan incelemesi hâlâ gerekli. Kritik sistemlerde önerilen düzeltmeleri test etmeden uygulamamak lazım.
Küçük ekipler önce hangi özelliği açmalı?
Başlangıç için secret scanning + Dependabot iyi bir ikili olur. Sonra code scanning’i eklemek mantıklı. Hepsini aynı anda kusursuz yapmak yerine aşamalı gitmek daha sağlıklı.
Kaynaklar ve İleri Okuma
GitHub Code Security Resmî Dokümantasyonu
GitHub Secret Scanning Rehberi
GitHub Code Scanning Rehberi
GitHub Security Bloğu
GitHub Actions’da Özel Runner İmajları: Kontrol Artık Sizde!
Açık Kaynak Güvenlik Açıkları: 2025’te Neler Değişti?
GitHub Credential Revocation API ile Sızıntılara Anında Fren: Yeni Destekler ve Gerçek Hayat Senaryoları
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.
Yorum gönder