GitHub Dependabot Uyarıları 25 Eylül’de Arşivleniyor: Güvenlik Raporlaması İçin Hazırlık Planı
İki yıldan eski kapalı Dependabot uyarılarının arşive taşınmasından önce API sorguları, denetim kanıtları, CSV dışa aktarma ve raporlama süreçleri nasıl güncellenmeli?
Yeni saklama politikası ne getiriyor?
GitHub, kapatılmış güvenlik uyarıları için yeni bulut veri saklama politikasını 25 Eylül 2026 tarihinde Dependabot ile başlatacağını açıkladı. İki yıl veya daha uzun süre önce kapatılmış Dependabot uyarıları arşiv depolamasına taşınacak.
Açık uyarılar ile son iki yıl içinde kapatılan uyarılar kullanıcı arayüzü ve API üzerinden erişilebilir kalacak. Arşivlenen eski kayıtlar ise normal arama ve API sonuçlarında görünmeyecek; yetkili yöneticiler bunları güvenlik uyarıları sayfasından CSV olarak indirebilecek.
Kimler etkilenir?
Değişiklik github.com üzerindeki Dependabot güvenlik uyarılarını ve GitHub Enterprise Cloud ortamlarını kapsıyor. GitHub Enterprise Server kurulumları bu politikaya dahil değil.
İki yıldan eski kapalı bulguları API ile çeken denetim panoları, uyumluluk raporları ve kurum içi veri ambarları etkilenebilir. Sorun kayıtların silinmesi değil, günlük UI ve API yolundan arşiv erişim modeline geçmesidir.
- Dependabot API kullanan rapor ve entegrasyonları listeleyin.
- İki yıldan eski kapalı kayıt sorgularını belirleyin.
- Denetçi ve güvenlik yöneticisi erişimlerini doğrulayın.
- CSV arşivlerinin güvenli saklama yerini kararlaştırın.
API sorgularını şimdi test edin
Kuruluşlar 25 Eylül’den önce kapalı Dependabot uyarılarını REST API üzerinden sorgulayıp hangi raporların eski kayıtlara dayandığını ölçmelidir. Tarih filtresi veya yerel veri eşitlemesi bulunmayan entegrasyonlarda sonuç sayısı değişebilir.
Raporlama süreci yalnızca toplam uyarı sayısına dayanıyorsa arşivleme sonrası yanıltıcı düşüş görülebilir. Gösterge panolarında açık, yakın dönemde kapalı ve arşivlenmiş kayıtlar ayrı veri kümeleri olarak tanımlanmalıdır.
- Mevcut API sonuçlarının tarih dağılımını kaydedin.
- İki yıldan eski kapalı uyarıları ayrı sayın.
- Arşiv sonrası beklenen sonuçları test ortamında modelleyin.
- Eksik görünen kayıtlar için rapor açıklaması ekleyin.
CSV arşivi nasıl yönetilmeli?
GitHub, arşivlenen uyarıların kuruluş, depo ve kurumsal düzeyde yetkili kullanıcılar tarafından CSV olarak indirilebileceğini belirtiyor. Dışa aktarılan dosyalar güvenlik bulguları ve depo bilgileri içerdiği için sıradan paylaşım klasörlerine bırakılmamalıdır.
Dosyalar erişim kontrollü, şifreli ve sürümlemeli bir depoda saklanmalıdır. Dosyanın alındığı tarih, kapsam, kaynak kuruluş ve bütünlük özeti kayda eklenerek denetim zinciri korunmalıdır.
Uyumluluk ve metrik etkisi
Kapalı uyarıların geçmişi, düzeltme süresi ve risk kabul kararlarının kanıtı olabilir. Arşivleme başlamadan önce yasal saklama süreleri ile GitHub’ın erişim modeli karşılaştırılmalı ve gerekirse kurumsal kopya oluşturulmalıdır.
Arşivlenen kayıtları “artık yok” olarak yorumlamayın. Güvenlik metrikleri zaman aralığını açıkça göstermeli ve iki yıllık çevrimi aşan karşılaştırmalarda arşiv verisini hesaba katmalıdır.
Yetki ve sorumluluklar
Enterprise, organization ve repository yöneticileri ile security manager rollerinin arşiv indirme yetkileri önceden doğrulanmalıdır. Gereksiz geniş yönetici yetkisi vermek yerine en az ayrıcalık ilkesi uygulanmalıdır.
Arşiv alma görevinin sahibi, periyodu ve başarısızlık bildirimi belirlenmelidir. Tek kişiye bağlı manuel süreç yerine onaylı bir işletim prosedürü ve yedek sorumlu tanımlanması sürdürülebilirlik sağlar.
25 Eylül öncesi kapanış listesi
API bağımlılıkları güncellenmeli, eski kapalı kayıtların gerekli kopyaları alınmalı ve raporların yeni veri kapsamıyla doğru çalıştığı doğrulanmalıdır. Arşiv dosyasına erişim ve geri yükleme denemesi de yapılmalıdır.
Kapanış kaydı etkilenen raporları, alınan arşivleri, yetki doğrulamasını ve açık istisnaları içermelidir. GitHub diğer güvenlik uyarı türleri için takvimi daha sonra duyuracağından ilgili changelog düzenli izlenmelidir.