Bir API anahtarının pull request içinde görünmesi, yalnız dikkatsiz bir satır hatası değildir. Anahtar birkaç saniye içinde günlüklerde, çatallarda veya üçüncü taraf entegrasyonlarda çoğalabilir. GitHub, 9 Eylül 2026’da repository ruleset’lere yeni bir merge kuralı ekledi: Pull request yeni bir secret scanning alarmı getiriyorsa birleştirme engellenebiliyor.

“Require secret scanning alerts are resolved” adlı kural iki koşulu denetliyor. Önce PR’ın head commit’i için sır taramasının tamamlanmış olması gerekiyor. Ardından PR commit’lerinin getirdiği sırlar için açık alarm bulunmamalı. Bypass yetkisi olmayan geliştirici, alarmı çözmeden merge yapamıyor. Özellik bugün public preview durumunda ve GitHub Secret Protection veya GitHub Advanced Security müşterilerine sunuluyor.

Bu kural push protection’dan farklı mı?

Evet. Push protection, bilinen bir sırrı uzak depoya gönderme anında durdurmaya çalışır. Yeni ruleset kuralı ise pull request katmanında ikinci bir kapı kurar. GitHub’ın verdiği örnekte ekip, genel desenler için push protection’ı kapalı tutarken aynı sır türlerinin PR ile ana dala girmesini engelleyebilir. Başka bir deyişle yeni özellik, push protection’ın yerini almıyor; kapsamadığı veya yapılandırılmadığı durumları tamamlıyor.

Bu ayrım operasyonel olarak önemli. Geliştirici yerel çalışırken yanlışlıkla anahtar eklemiş ve push engelini aşmak için gerekçe belirtmiş olabilir. Bir PR kontrolü, kod inceleme ve birleştirme noktasında yeniden değerlendirme fırsatı verir. Ancak anahtar depoya ulaştıysa yalnız satırı silmek yeterli değildir. Sır geçersiz kılınmalı, yenisi üretilmeli ve kullanım günlükleri incelenmelidir.

Varsayılan kapsam neyi yakalar?

GitHub’a göre kural varsayılan olarak açık pull request’lerde çalışıyor ve hizmet sağlayıcı desenleriyle bulunan sırları engelliyor. Bulut anahtarı, ödeme hizmeti belirteci veya belirli bir sağlayıcıya ait erişim kodu bu sınıfa girebilir. İstenirse özel desenler ve genel desen kategorileri de kapsama eklenebiliyor.

Genel desenleri doğrudan tüm depolarda zorlamak, yanlış pozitifleri artırabilir. Örnek yapılandırma dosyasındaki sahte belirteç, eğitim dokümanındaki maskelenmiş değer veya test fixture’ı alarm üretebilir. Bu yüzden kuralı önce bir pilot repository’de açıp hangi desenlerin gerçekten sır olduğunu ölçmek daha güvenli.

Merge kapısı nasıl kurulur?

Repository, organization veya enterprise ayarlarında Repository > Rulesets bölümüne gidin. Korunacak dalları hedefleyen yeni bir ruleset oluşturun ya da var olanı düzenleyin. Ardından “Require secret scanning alerts are resolved” kuralını seçin. GitHub ayrıca REST API’de require_secret_scanning_alert_resolution kural türünü ve secret_types parametresini; GraphQL’de ise ilgili enum değerini desteklediğini belirtiyor.

Kuralı açmadan önce bypass listesini gözden geçirin. Yönetici olmak otomatik ve sınırsız istisna anlamına gelmemeli. Acil durum bypass’ı gerekiyorsa gerekçe, süre ve sonradan inceleme kaydı zorunlu olsun. Daha önce Copilot content exclusion rehberinde hassas dosyaları model bağlamından çıkarmayı ele almıştık; merge kapısı bunun kod deposuna giren sırlar için ayrı bir savunma katmanıdır.

10 dakikalık güvenli test planı

1. Gerçek anahtar kullanmayın

Yalnız sağlayıcının yayımladığı, hiçbir hesaba erişim sağlamayan test örneğini veya GitHub’ın belgelenmiş özel desen test yöntemini kullanın. Test için çalışan bir anahtar oluşturup commit etmeyin. Seçtiğiniz örneğin kullanılan tarama kuralıyla eşleştiğini önceden doğrulayın.

2. Ayrı dal ve kapalı depo seçin

Pilot repository’de korunan dala giden küçük bir PR açın. Taramanın tamamlanmasını bekleyin ve kontrolün merge’i durdurduğunu doğrulayın. Alarm ayrıntısında sır türü, dosya ve commit doğru görünüyor mu bakın.

3. Çözüm akışını sınayın

Test değerini geçmişten kaldırın veya GitHub’ın yönlendirdiği çözüm adımını uygulayın. Alarm kapandıktan sonra merge kontrolünün yeniden değerlendirildiğini doğrulayın. Yalnız “dismiss” seçeneğinin geliştiriciler tarafından kolayca kullanılmasına izin vermeyin; kapatma gerekçesini denetim kaydına dahil edin.

4. Bildirim ve süre ölçün

  • Alarm güvenlik ekibine ulaşıyor mu?
  • PR ekranında engel nedeni açık mı?
  • Yanlış pozitif için sorumlu ve hedef çözüm süresi belli mi?
  • Sır gerçekse iptal ve yenileme işlemi kimin görevi?
  • Bypass kullanımı audit log’da izlenebiliyor mu?

5. Eski açık pull request’leri kontrol edin

GitHub, kuralın varsayılan olarak açık pull request’lerde çalıştığını belirtiyor. Bu nedenle pilotu açtığınız gün yalnız yeni PR’lara değil, haftalardır bekleyen dallara da bakın. Daha önce sessiz kalan bir alarm birleştirmeyi durdurabilir. Bu davranış arıza değil, kuralın mevcut kuyruğa uygulanmasının sonucudur; ekip içi duyuruda özellikle belirtin.

Kritik depolarda kuralı doğrudan tüm dallara yaymak yerine, önce ana dal ve sürüm dallarını hedefleyin. Bir haftalık yanlış pozitif ve çözüm süresi verisini topladıktan sonra kapsamı genişletin. Public preview özelliğinde arayüz veya API davranışı değişebileceği için yapılandırmayı kodla yönetiyorsanız şema değişikliklerini de sürüm notlarıyla izleyin.

Türkiye’deki ekipler için asgari politika

Küçük ekipte güvenlik rolü ayrı bir kişi olmayabilir. Bu durumda kural sahipliğini belirsiz bırakmayın: Repository yöneticisi, DevOps sorumlusu ve ürün sahibi arasından birincil ve yedek sorumlu belirleyin. Bulut, SMS, ödeme ve e-posta servislerine ait anahtarlar özellikle yüksek öncelikli olsun. Türkiye’de dövizle faturalandırılan bir hizmet anahtarının sızması, teknik hasarın yanında kısa sürede ciddi maliyete dönüşebilir.

Bu özellik kusursuz sır yönetimi sağlamaz; tarayıcının tanımadığı değerleri, çalışma zamanı sızıntılarını veya daha önce ele geçirilmiş anahtarları tek başına çözmez. Yine de birleştirme yetkisini otomatik tarama sonucuna bağlamak, “incelemede gözden kaçtı” sınıfındaki hataları azaltan uygulanabilir bir güvenlik kapısıdır.

Kaynak: GitHub Changelog, “Block pull requests with exposed secrets from merging”, 9 Eylül 2026.

İlgili rehber: Copilot kod incelemesinde otomatik kapanan yorumların doğrulanması.