Organizasyon düzeyinde çalıştırılan iki değerlendirme aracı, yani code security risk assessment ve secret risk assessment, artık bulguların korumalı mı yoksa korumasız repository’lerde mi yer aldığını raporluyor. Güvenlik ekipleri böylece tespit edilen riskin hangi kısmının halihazırda güvenlik özellikleriyle kapsandığını, hangi kısmının kapsam dışında kaldığını tek bakışta görebiliyor. Güvenlik kapsamını genişletirken nereden başlanacağını belirlemek için ayrı bir envanter çalışması yapmak da gerekmiyor, bilgi doğrudan değerlendirme çıktısının içinde geliyor.
Değişiklik tam olarak ne getiriyor?
Risk değerlendirmeleri daha önce de organizasyon genelinde hangi repository’lerde potansiyel kod güvenliği sorunu veya sır (secret) sızıntısı sinyali bulunduğunu gösteriyordu. Yeni eklenen bilgi bu bulguların bağlamını tamamlıyor; ilgili repository koruma altında mı, değil mi?
Ayrım, aynı sayıda bulgunun birbirinden çok farklı iki anlama geldiği durumlarda işe yarıyor. Korumalı bir repository’de çıkan bulgu, zaten işleyen bir güvenlik akışının parçası olarak ele alınabilir. Korumasız bir repository’deki bulgu ise hem tespit edilmemiş hem de akışa dahil edilmemiş bir riski işaret eder, bu yüzden kapsam genişletme çalışmasının doğal önceliği ikinci gruptur.
GitHub’ın duyurusu geliştirmenin amacını açıkça “güvenlik kapsamınızı nerede genişletmeniz gerektiğini belirlemenize yardımcı olmak” şeklinde tanımlıyor. Ortada yeni bir tarama motoru ya da yeni bir bulgu tipi yok; mevcut bulguları önceliklendirmeyi kolaylaştıran bir bağlam katmanı eklenmiş.
Değerlendirme nereden başlatılıyor?
Değerlendirmeyi başlatma yetkisi organizasyon yöneticilerinde (organization admins) ve security manager rolüne sahip kullanıcılarda. Akış şöyle ilerliyor:
- Organizasyonun Security sekmesine gidin.
- Buradaki Assessments bölümünü açın.
- Code security risk assessment veya secret risk assessment değerlendirmesini başlatın.
Değerlendirme sonuçlarında bulguların korumalı ve korumasız repository dağılımı artık görünür durumda. Kaynak duyuru arayüzdeki görünümün ayrıntılı yerleşimini tarif etmediği için burada ekran düzeyinde adım adım bir anlatıma girmiyoruz; akışın doğru noktası Security sekmesi altındaki Assessments girişidir.
Hangi platformlarda kullanılabilir?
Duyuruya göre geliştirme GitHub Enterprise Cloud ve GitHub Team planlarında kullanılabilir durumda. Self-hosted tarafta kapsam daha dar tanımlanmış: GitHub Enterprise Server 3.24 sürümünde yalnızca secret risk assessment için sunulacağı belirtiliyor.
Bu ayrımın altını çizmekte fayda var, çünkü Enterprise Server kullanan ekipler için code security risk assessment tarafındaki koruma durumu bilgisine dair bir taahhüt kaynakta yer almıyor. “GHES 3.24 ile her iki değerlendirmede de bu bilgi gelecek” çıkarımı dolayısıyla doğru olmaz, duyurunun kapsadığı tek şey secret risk assessment.
| Ortam | Durum |
|---|---|
| GitHub Enterprise Cloud | Kullanılabilir |
| GitHub Team | Kullanılabilir |
| GitHub Enterprise Server 3.24 | Secret risk assessment için gelecek |
Güvenlik ekipleri bu bilgiyi nasıl değerlendirebilir?
Koruma durumu bilgisinin en doğrudan kullanımı kapsam boşluklarını görünür kılmak. Büyük organizasyonlarda repository sayısı arttıkça güvenlik özelliklerinin hangi depolarda etkin olduğunu elle takip etmek zorlaşır. Risk değerlendirmesi zaten organizasyon genelinde bir fotoğraf çektiği için, koruma durumunun o fotoğrafa eklenmesi iki soruyu aynı anda yanıtlanır hale getiriyor: “Risk nerede?” ve “Bu riskin üzerinde halihazırda bir koruma var mı?”
İki sorunun kesişimi pratikte bir önceliklendirme listesi üretir. Korumasız repository’lerdeki bulgular hem tespit hem de önleme tarafında eksik olduğu için listenin üst sırasına yerleşir, korumalı repository’lerdeki bulgularsa mevcut süreç içinde takip edilebilir.
Değerlendirmelerin kavramsal arka planını ve bulguların nasıl yorumlanması gerektiğini anlamak için GitHub’ın code security risk assessment dokümantasyonu ile secret security dokümantasyonu başvurulacak ilk kaynaklar. Bu belgeler değerlendirmenin neyi kapsadığını ve bulguların hangi sinyallere dayandığını tanımlıyor.
Kapsam dışı bırakılması gereken varsayımlar
Duyurunun sınırlarını net tutmakta fayda var. Kaynak metin, bulguların koruma durumuna göre filtrelenip filtrelenemediğine, bu bilginin API üzerinden dışa aktarılıp aktarılamadığına veya raporun hangi formatlarda indirilebildiğine girmiyor; bu yüzden söz konusu yeteneklerin varlığına dair bir çıkarımda bulunmuyoruz. “Korumalı repository” tanımının hangi özelliklerin etkin olmasına bağlandığı da duyuruda açıkça tarif edilmemiş, tanımın kesin karşılığı için dokümantasyona bakmak gerekiyor.
Değişiklik küçük ama operasyonel olarak işlevsel. Risk değerlendirmesi çıktısı artık “ne bulundu” sorusunun yanında “bulunduğu yer korunuyor mu” sorusunu da yanıtlıyor.
Kaynaklar ve İleri Okuma
- GitHub Changelog: Security risk assessments include repository protection status
- GitHub Docs: Code security risk assessment
- GitHub Docs: Secret security with GitHub
- GitHub Advanced Security Zorunlu Kılma: Ne Değişti?
- GitHub Push Protection ve yapısız sır tespiti
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.
