GitHub, sır sızdıran pull request’i durduruyor; AI tespitleri kapsam dışında

GitHub, 9 Eylül 2026’da sır taraması tamamlanmamış veya eklediği sırlar için açık uyarı bulunan pull request’lerin korunan dallarla birleştirilmesini durduran yeni ruleset kuralını genel önizlemeye açtı. GitHub’ın 9 Eylül değişiklik kaydı, kuralın GitHub Secret Protection veya GitHub Advanced Security kullanan müşterilere sunulduğunu ve otomatik olarak bütün depolarda etkinleşmediğini belirtiyor.

Yeni koruma, 9 Eylül 2026 itibarıyla genel önizlemede: hedef dalları kapsayan bir ruleset içinde ayrıca yapılandırılması gerekiyor. Bağımsız Releases Index kaydı da aynı tarih ve önizleme statüsüyle pull request katmanındaki engeli, ayrıca kullanıcı arayüzü, REST API ve GraphQL üzerinden yapılandırma seçeneklerini listeliyor.

Kural birleştirmeyi iki durumda engelliyor

Denetim önce pull request’in baş commit’i için secret scanning taramasının tamamlanmasını bekliyor. Tarama bittikten sonra pull request’teki bir commit’in eklediği, ruleset’te seçilmiş bir sır türüyle eşleşen açık uyarı varsa birleştirme yine engelleniyor.

Bu kapsam, depodaki bütün eski secret scanning uyarılarının her pull request’i kilitlediği anlamına gelmiyor. Engel, pull request’in commit’lerinin getirdiği açık uyarılarla ve ruleset’te seçilen sır kategorileriyle sınırlı. Uyarı nedeniyle durdurulan bir pull request’in açılması için eşleşen uyarıların GitHub’daki çözüm akışında kapatılması gerekiyor.

Varsayılan ayar sağlayıcı kalıplarıyla bulunan sırları kapsıyor. Yöneticiler buna kurumlarının tanımladığı özel kalıpları ve özel anahtarlar ya da bağlantı dizeleri gibi daha genel biçimleri arayan generic patterns kategorisini ekleyebiliyor.

Push protection daha erken, merge kuralı daha geç çalışıyor

Push protection sırrı depoya gönderilirken, yeni kural ise pull request korunan dalla birleştirilirken devreye giriyor. İlk kontrol sızıntıyı daha erken aşamada kesiyor; ikincisi, push protection’ın etkin olmadığı veya ilgili sır türünü engelleyecek biçimde yapılandırılmadığı durumlar için ayrı bir kapı oluşturuyor.

İki mekanizma bu nedenle birbirinin yerine geçmiyor. Örneğin bir ekip, generic patterns kategorisini push sırasında engellemeyip aynı kategorideki açık uyarıların korunan dala birleştirmeden önce çözülmesini zorunlu tutabilir. Commit depoya ulaşsa bile ruleset koşulu sağlanmadan hedef dala giremez.

Push aşamasındaki bir atlama da merge izni anlamına gelmiyor. Pull request, hedef dalın ruleset’i tarafından yeniden değerlendiriliyor; platform ekibinin her iki katmanda etkin kategorileri ve atlama yetkilerini ayrı ayrı yönetmesi gerekiyor.

Birleştirme koruması nasıl etkinleştiriliyor?

GitHub’ın yapılandırma belgesi, korunan depoda secret scanning ile GitHub Secret Protection veya GitHub Advanced Security’nin etkin olmasını ön koşul olarak gösteriyor. Kural, dalları hedefleyen depo veya kuruluş ruleset’lerinde yetkili yöneticiler tarafından yapılandırılabiliyor.

1. Depo ya da kuruluş ayarlarında Rulesets bölümünü açın ve bir branch ruleset oluşturun veya mevcut ruleset’i düzenleyin.
2. Korunacak depoları ve hedef dalları tanımlayın.
3. Require secret scanning alerts are resolved kuralını seçin.
4. Birleştirmeyi engelleyecek sağlayıcı, özel ve genel kalıp kategorilerini belirleyin.
5. Ruleset’in enforcement durumunu Active yapıp yapılandırmayı kaydedin.

Ruleset devre dışı bırakılırsa ya da pull request’in hedef dalını kapsamıyorsa engel uygulanmıyor. Otomasyon kullanan ekipler aynı kuralı REST API’de require_secret_scanning_alert_resolution türü ve secret_types parametresiyle, GraphQL’de ise REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION adıyla yönetebiliyor.

Bypass yetkisi uyarıyı çözmekle aynı şey değil

Bypass izni bulunmayan geliştiriciler, seçili kategorilerle eşleşen açık uyarıları çözmeden pull request’i birleştiremiyor. Ruleset için atlama yetkisi verilmiş aktörler ise genel bypass yapılandırmasına göre engeli geçebiliyor. Bu istisna, uyarının teknik olarak kapatıldığı veya açığa çıkan kimlik bilgisinin güvenli hale getirildiği anlamına gelmiyor.

Gerçek bir erişim anahtarı koddan çıkarıldığında bile sağlayıcı tarafında geçerli kalabilir; bu nedenle iptal edilmesi veya döndürülmesi gerekir. Yanlış pozitif ya da test verisi olan bulgular ise uygun gerekçeyle kapatılabilir. Merge kuralının baktığı ölçüt, seçilmiş sır türleri için açık uyarı kalıp kalmadığıdır.

Bu ayrım özellikle merkezi ruleset kullanan kuruluşlarda önemli. Bypass erişiminin geniş tutulması, merge kapısını fiilen isteğe bağlı hale getirebilir; erişimi açık sorumluluğu bulunan rol ve ekiplerle sınırlamak ise yeni kuralın beklenen davranışını korur.

AI ile tespit edilen sırlar merge kapısının dışında

Yeni kural sağlayıcı, özel ve genel kalıpları destekliyor; ancak AI-detected secrets kategorisindeki uyarıları desteklemiyor. Dolayısıyla AI ile saptanan açık bir sır uyarısı, diğer desteklenen kategorilerden birine de eşleşmediği sürece bu ruleset’i tek başına tetiklemiyor.

Bu sınır, özelliğin bütün secret scanning bulgularını kapsayan genel bir birleştirme garantisi vermediğini gösteriyor. Koruma yalnızca ruleset’te seçilebilen ve kural tarafından desteklenen algılayıcı kategorileri için geçerli.

AI bulgularının kapsama alınmasını bekleyen ekipler için tamamlayıcı seçenekler; biçimi tanımlanabilen kurum sırlarını özel kalıplarla yakalamak, AI uyarılarına zorunlu inceleme sahipliği atamak veya ayrı bir tarayıcının sonucunu gerekli durum denetimine bağlamak. Bunlar yeni GitHub kuralının parçası değil, kapsam dışındaki bulgular için ek politika kararları.

Mevcut durumda kural genel önizlemede ve değişikliğe açık. Sağlayıcı, özel ve genel kalıplar için pull request düzeyinde ikinci bir güvenlik kapısı sunuyor; AI ile tespit edilen sırlar desteklenmedikçe bütün uyarıları kapsayan tek bir merge kontrolü olarak kullanılamıyor.

Ayrıca okuyun:

• VS Code 1.136, pull request’i düzeltiyor: birleştirme yine otomatik değil
• YouTube’a Amazon etiketleri geldi, fakat Türkiye kapsam dışında
• Copilot CLI artık hariç tutulan dosyaları okumuyor; kapsam yine sınırlı