GitHub, sızan sırlar çözülmeden pull request birleştirmeyi durduruyor
GitHub, 9 Eylül 2026’da genel önizlemeye açılan yeni repository ruleset kuralıyla, secret scanning taraması tamamlanmamış veya seçili türde açık secret uyarısı bulunan pull request’lerin birleştirilmesini durdurabiliyor. Changes.Watch’ın GitHub kaydı, aynı tarihte repository ruleset’lerine açığa çıkmış sırlar getiren pull request’leri engelleme yeteneğinin eklendiğini gösteriyor.
9 Eylül 2026 tarihli genel önizleme tüm depolarda otomatik olarak etkinleşmiyor. GitHub’ın resmî duyurusuna göre GitHub Secret Protection veya GitHub Advanced Security müşterileri, hedef dallara uygulanan ruleset içinde Require secret scanning alerts are resolved kuralını açabiliyor; kontrol, head commit taramasının bitmesini ve pull request commit’lerinin oluşturduğu ilgili uyarıların kapanmasını bekliyor.
Yeni kural, push protection’dan sonra ikinci bir kapı kuruyor
Push protection ile yeni birleştirme kuralı aynı işlemi tekrarlamıyor. Push protection, desteklediği bir sır desenini push sırasında yakalayarak içeriğin repository’ye ulaşmasını önlemeye çalışıyor. Yeni ruleset kuralı ise kod pull request’e ulaştıktan sonra, değişikliğin korunan dala birleştirilip birleştirilemeyeceğine karar veriyor.
İki katman arasındaki fark özellikle kapsam ayarlarında ortaya çıkıyor. Örneğin bir ekip generic desenler için push protection kullanmıyor ancak aynı desenleri PR ruleset’inde seçiyorsa, değişiklik repository’ye ulaşabilir fakat korunan dala birleştirilemez. Push aşamasında atlanan veya o kontrolde kapsanmayan bir bulgu için PR katmanı ikinci bir denetim noktası oluşturur.
Birleştirme engelinin iki ayrı nedeni bulunuyor. Head commit henüz taranmamışsa sistem sonuç gelene kadar birleşime izin vermiyor; tarama bittiyse bu kez pull request commit’lerinin oluşturduğu, yapılandırmada seçilmiş bir secret türüyle eşleşen açık uyarılar kontrol ediliyor. Bypass izni olmayan geliştiricinin birleşim koşulunu karşılayabilmesi için bu uyarıların her birini çözmesi gerekiyor.
Kapsam, seçilen desenler ve güvenlik lisansıyla sınırlı
GitHub’ın yapılandırma belgesi, kuralın provider, custom ve generic desenlerini desteklediğini, AI ile tespit edilen sırları ise kapsamadığını belirtiyor. Aynı belge, hedef repository’de GitHub Secret Protection veya GitHub Advanced Security ile secret scanning’in etkin olmasını ön koşul olarak gösteriyor.
Provider desenleri varsayılan kapsamı oluşturuyor; custom ve generic kategorileri ruleset içinde ayrıca seçilebiliyor. Bu nedenle bir pull request’te herhangi bir güvenlik bulgusunun bulunması tek başına yeni birleştirme engelini tetiklemiyor. Uyarının pull request commit’lerinden kaynaklanması, açık durumda kalması ve ruleset’te seçilmiş bir secret türüyle eşleşmesi gerekiyor.
Kural yalnızca branch hedefleyen repository ruleset’lerinde ve ruleset’in kapsadığı repository ile dallarda uygulanıyor. Başlıktaki “sırlar çözülmeden” ifadesinin teknik sınırı da burada: GitHub bütün olası hassas verileri değil, secret scanning’in desteklediği ve yöneticinin bu kural için seçtiği türlerdeki açık uyarıları birleşim koşuluna bağlıyor. AI tabanlı tespitler genel önizlemenin mevcut kapsamının dışında kalıyor.
Genel önizleme dar bir kapsamla etkinleştirilebilir
Repository düzeyinde yetkili kullanıcılar Settings altındaki Rulesets bölümünden yeni bir branch ruleset oluşturabiliyor veya mevcut bir ruleset’i düzenleyebiliyor. Kuruluş düzeyinde ise hedef repository’ler ve dallar ayrı ayrı sınırlandırılabiliyor. Ruleset’in durumu Active yapıldığında seçilen hedeflerde uygulanmaya başlıyor.
Önizlemeyi kontrollü biçimde devreye almak için kısa kurulum sırası şöyle:
- Hedef repository’lerde Secret Protection veya Advanced Security ile secret scanning’in etkin olduğunu doğrulayın.
- Repository ya da organization ayarlarında bir branch ruleset oluşturun veya mevcut ruleset’i düzenleyin.
- Korunacak repository ve dalları açıkça hedefleyin.
- Require secret scanning alerts are resolved kuralını seçin.
- Birleşimi durduracak provider, custom ve generic secret türlerini belirleyin.
- Bypass izni verilecek rolleri gözden geçirip ruleset’i Active duruma alın.
Buradaki güvenli önizleme yaklaşımı, önce dar bir repository ve dal kümesi seçmek, sonuçları izlemek ve ardından kapsamı genişletmektir. Bu bir GitHub zorunluluğu değil, yeni bir engelleme politikasının beklenmeyen iş akışı etkilerini sınırlamaya yönelik operasyonel bir tercihtir. Özellikle custom ve generic desenler etkinleştirilecekse, hangi uyarıların birleşimi durdurduğunu küçük bir kapsamda görmek yanlış yapılandırmaların etkisini azaltabilir.
Bypass yetkisi de kuralın etkisini doğrudan belirliyor. İzni olmayan geliştiriciler eşleşen uyarıları çözmek zorundayken, ruleset’te istisna tanınmış aktörler engeli aşabiliyor. Bu nedenle ekiplerin yalnızca kuralı açması değil, istisna listesini acil operasyon ihtiyacıyla sınırlaması da gerekiyor.
REST ve GraphQL aynı politikayı otomasyona taşıyor
Çok sayıda repository yöneten kuruluşlar ayarı yalnızca web arayüzünden dağıtmak zorunda değil. REST API’de kural türü require_secret_scanning_alert_resolution, seçilecek kapsam ise secret_types parametresiyle tanımlanıyor. GraphQL tarafında kuralın karşılığı REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION.
API üzerinden kurulum, aynı secret türü ve dal politikasını farklı repository’lere tutarlı biçimde uygulamayı kolaylaştırabilir; ancak lisans, etkin secret scanning ve doğru hedef kapsamı ön koşullarını kaldırmıyor. Otomasyon, bypass yetkilerini geniş tutmanın doğuracağı politika boşluğunu da kendiliğinden kapatmıyor.
Özellik şu anda genel önizlemede ve değişikliğe açık. Doğrulanmış mevcut kapsam; head commit taramasının tamamlanmasını, seçilen desenlerde pull request’in oluşturduğu açık uyarı kalmamasını ve bypass izinlerinin ruleset üzerinden yönetilmesini içeriyor. GitHub henüz genel kullanıma geçiş tarihi açıklamadı; desteklenen bulgu türlerinin veya erişim koşullarının önizleme sonrasında değişip değişmeyeceği de bilinmiyor.
Ayrıca okuyun:
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.