GitHub’da Gizli Bilgi İçeren Pull Request’ler Artık Birleştirmeden Önce Engellenebiliyor
GitHub’ın yeni ruleset kuralı, açık secret scanning uyarısı bulunan pull request’lerin birleştirilmesini engelliyor. Kurulum ve yönetişim rehberi.
Yeni koruma ne sağlıyor?
GitHub, 9 Eylül 2026 tarihinde repository ruleset yapısına gizli bilgi uyarıları çözülmeden pull request birleştirmeyi engelleyen yeni bir kural ekledi. Özellik, erişim anahtarı veya belirteç gibi hassas bir değerin kod incelemesinden kaçıp ana dala ulaşmasını önleyen ek bir güvenlik kapısı oluşturuyor.
Kural, birleştirme öncesinde iki koşulu denetliyor: pull request’in son commit’i için gizli bilgi taramasının tamamlanmış olması ve ilgili commit’lerin oluşturduğu açık bir uyarı bulunmaması. Bypass yetkisi olmayan geliştiriciler uyarıyı çözmeden işlemi tamamlayamıyor.
Push protection ile farkı
Push protection, desteklenen gizli bilgi kalıplarını depoya gönderilmeden önce durdurmaya çalışır. Yeni ruleset kuralı ise pull request aşamasında ikinci bir kontrol noktası sunarak push protection’ın kapalı olduğu veya ilgili kalıbı kapsamadığı durumlarda savunmayı tamamlar.
İki mekanizma birbirinin alternatifi olarak görülmemelidir. En güçlü yaklaşım, geliştiriciye erken geri bildirim veren push protection ile ana dala geçişi denetleyen birleştirme kuralını birlikte kullanmaktır.
Kural nasıl etkinleştirilir?
Depo, kuruluş veya enterprise ayarlarında Repository bölümündeki Rulesets alanından yeni ya da mevcut bir kural seti açılır. Hedef dallar belirlendikten sonra secret scanning uyarılarının çözülmesini zorunlu tutan seçenek etkinleştirilir.
- Kritik üretim dallarını açıkça hedefleyin.
- Önce pilot depolarda davranışı doğrulayın.
- Bypass yetkisini küçük ve denetlenebilir bir grupla sınırlayın.
- Özel ve genel kalıpların hangilerinin engel oluşturacağını belgeleyin.
Yanlış pozitifler nasıl yönetilmeli?
Her uyarıyı gerçek sızıntı kabul etmek operasyonu yavaşlatabilir; ancak yalnızca birleştirme engelini kaldırmak için uyarıları topluca kapatmak da korumayı anlamsızlaştırır. Ekip, doğrulanmış test verisi ve iptal edilmiş kimlik bilgisi gibi kapanış nedenlerini ayıran bir inceleme süreci kullanmalıdır.
Gerçek bir sır tespit edildiğinde yalnızca koddan silmek yeterli değildir. Değer iptal edilmeli veya döndürülmeli, geçmiş commit’lerdeki yayılım incelenmeli ve erişim günlükleri olası kötüye kullanım açısından kontrol edilmelidir.
Kimler kullanabilir ve ne izlenmeli?
GitHub’a göre özellik, GitHub Secret Protection veya GitHub Advanced Security müşterileri için genel önizleme aşamasında sunuluyor. Önizleme özelliklerinde davranış değişebileceği için kuralın kritik iş akışlarına etkisi ve bypass olayları düzenli izlenmelidir.
Başarı ölçümü yalnız engellenen pull request sayısı değildir. Açık uyarıların çözülme süresi, yanlış pozitif oranı, döndürülen kimlik bilgileri ve bypass kullanımının gerekçeleri birlikte değerlendirilmelidir.
Uygulanabilir geçiş planı
İlk hafta birkaç aktif depoda gözlem yapın, engellenen örnekleri güvenlik ve geliştirme ekipleriyle değerlendirin. Sonuçlar netleştiğinde kuralı kuruluş düzeyinde standartlaştırıp istisnaları süreli ve kayıtlı hale getirin.
- Mevcut secret scanning kapsamını doğrulayın.
- Pilot ruleset oluşturun.
- Olay müdahale adımlarını geliştirici rehberine ekleyin.
- Denetim kayıtlarını ve bypass yetkilerini periyodik inceleyin.