GitHub Push Protection’ı açın: Sızan anahtarı sonra silmek yetmez

GitHub deposunda gönderim öncesi engellemeyi açmak için Settings → Advanced Security yolunu izleyin; Secret Protection kapalıysa etkinleştirin, ardından Push protection için Enable seçeneğini kullanın. GitHub’ın depo ayarları yönergesi bu sırayı ve ayarı değiştirebilen rolleri gösterir.

Push Protection, algıladığı desteklenen gizli değeri yeni bir gönderim depoya ulaşmadan durdurur. Önceden depoya girmiş bir anahtarın yetkisini kaldırmaz: böyle bir sızıntıda anahtarı veren hizmette iptal ve yenileme işlemlerini ayrıca yapmanız gerekir. Korumanın kimleri kapsadığı ve engeli kimin aşabildiği de depo ayarına bağlıdır.

Depoda korumayı etkinleştirme

Ayarı depo sahibi, kuruluş sahibi, güvenlik yöneticisi veya depo yöneticisi açabilir. Deponun ana sayfasında Settings sekmesini seçin; sekme doğrudan görünmüyorsa açılır menüde arayın. Sol menüde Security and quality altındaki Advanced Security bölümüne girin.

1. Secret Protection kapalıysa yanındaki Enable seçeneğiyle etkinleştirin.
2. Secret Protection bölümünde Push protection satırını bulun ve Enable seçeneğini kullanın.
3. Aynı sayfaya dönüp hedef depoda her iki ayarın etkin göründüğünü doğrulayın.

Settings bölümüne erişemiyorsanız önce doğru depoda ve gerekli yönetim rolüne sahip hesapta olduğunuzu kontrol edin. Kuruluşun güvenlik yapılandırması ayarı merkezden yönetiyorsa kapsamı kuruluş yöneticisiyle belirleyin. Bir depoda korumayı açmış olmak, kuruluşun diğer depolarının da aynı ayarı kullandığı anlamına gelmez.

Açık, özel ve kuruluş depolarında kapsam

GitHub’ın Push Protection açıklaması kullanıcı hesabı korumasıyla depo korumasını ayırır: GitHub.com hesabı için varsayılan olarak açık olan koruma, kullanıcının açık depolara gönderimlerine yöneliktir; depo koruması ise Secret Protection gerektirir ve depo, kuruluş veya kurumsal hesap düzeyinde açılabilir. Bu nedenle özel bir depoda hesabınızın varsayılan ayarını yeterli saymayın; hedef deponun ayarını ve kuruluşun bu depoya sağladığı erişimi kontrol edin.

Depo koruması komut satırından yapılan gönderimleri, GitHub arayüzündeki commit işlemlerini, dosya yüklemelerini ve REST API isteklerini kapsar. GitHub MCP server ile belirli etkileşimlerdeki korumanın kapsamı açık depolarla sınırlıdır. Engelleme desteklenen sır örüntülerinin algılanmasına bağlı olduğundan başarılı bir gönderim, kodda hiçbir kimlik bilgisi bulunmadığını kanıtlamaz.

Kuruluşa özgü bir anahtar biçimi kullanıyorsanız özel örüntü tanımlama olanağını değerlendirin. Push Protection yeni gönderimi durdurmaya çalışırken depoda zaten bulunan sırlar için secret scanning uyarılarını ayrıca incelemek gerekir. Bu ayrım, mevcut bir sızıntıyı yalnızca yeni gönderim engeli açarak kapatamayacağınız anlamına gelir.

Engellemeyi gerçek anahtar kullanmadan doğrulama

Önce ayarın hedef depoda etkin göründüğünü doğrulayın. Gönderimin gerçekten durduğunu sınamak istiyorsanız kuruluşun ayrı bir deneme deposunda, hiçbir hizmette geçerli olmayan sentetik bir değer için özel örüntü oluşturun ve bu örüntünün Push Protection kapsamında etkin olduğundan emin olun. Ardından yalnızca bu değeri içeren deneme commit’ini göndermeyi deneyin; üretim anahtarını test malzemesi yapmayın.

Engel çıkarsa iletide gösterilen dosya ve commit’i belirleyin. Değer son commit’teyse dosyadan çıkardıktan sonra aynı commit’i düzeltin; daha eski gönderilmemiş commit’lerdeyse değerin geçtiği her commit’i temizleyin. Çalışma kopyasına yeni, temiz bir commit eklemek, önceki commit’teki değeri gönderim geçmişinden çıkarmaz.

Deneme tamamlandığında sentetik değeri yerel geçmişten ve deneme dosyasından kaldırıp temiz gönderimi yeniden deneyin. Rastgele uydurulmuş bir dizgenin engellenmemesi tek başına korumanın kapalı olduğunu göstermez; dizge etkin örüntülerden hiçbirine uymuyor olabilir. Özel örüntü oluşturma olanağınız yoksa ayarın etkinliğini depo yapılandırmasından doğrulayın ve sırf sonuç görmek için geçerli bir belirteç üretmeyin.

Atlama yetkisi ve kayıtlar

Depo düzeyindeki varsayılan ayarda yazma yetkisi olan katkıcı, bir gerekçe seçerek engeli aşabilir. İstisnaların onaylanmasını istiyorsanız delegated bypass yapılandırıp bu yetkiyi belirli rol veya ekiplere verin; diğer katkıcıların talepleri yetkili inceleyicilere gider. Tam muafiyet daha geniş bir izindir, çünkü ilgili aktörün gönderimleri koruma engeline takılmaz.

Depo korumasındaki bir atlama Security and quality bölümünde uyarı ve denetim kaydı oluşturur. “Testte kullanılıyor” veya “yanlış pozitif” gerekçesiyle kapatılan uyarıda değerin gerçekten yetkisiz olup olmadığını inceleyin. “Sonra düzelteceğim” gerekçesi açık bir uyarı bırakır; geçerli bir anahtar söz konusuysa sorumlu kişiyi ve iptal işlemini belirleyin.

Yalnızca kullanıcı hesabının açık depolar için sağladığı koruma aşılmışsa, depo koruması da açık olmadığı sürece aynı depo uyarısı oluşmaz. Bu yüzden olay takibinde ilgili deponun koruma durumunu da kaydedin. Bir istisnayı onaylamadan önce değerin geçerliliğini, sağladığı erişimi ve gönderimde bulunmasının neden gerekli olduğunu değerlendirin; seçilmiş atlama gerekçesi tek başına güvenlik incelemesi değildir.

Anahtar önceden sızdıysa müdahale sırası

Açığa çıkan anahtarı veren hizmette eski anahtarı gecikmeden iptal edin ve en az gerekli yetkiyle yenisini oluşturun. OWASP’ın sır yönetimi rehberi müdahaleyi iptal, döndürme, açığa çıkan kopyaları temizleme ve kullanım kayıtlarını inceleme adımlarıyla açıklar. Koddan satırı silmek, anahtarın sağlayıcıdaki yetkisini sona erdirmez.

Yeni değeri onu kullanan CI/CD işleri, dağıtım ortamları ve diğer sistemlere güvenli biçimde dağıtın; çalışmalarını doğrulayın. Sonra eski değeri güncel koddan, yapılandırmalardan ve erişilebilir diğer kopyalardan çıkarın. Commit geçmişini yeniden yazmak gerekiyorsa ekipteki klonları ve eski commit bağlantılarını etkileyebileceğini hesaba katın; bu temizlik tamamlanana kadar iptali ertelemeyin.

Son olarak anahtarı veren hizmetin erişim kayıtlarıyla depodaki ilgili uyarı ve atlama kayıtlarını birlikte inceleyin. Anahtarın hangi yetkilere sahip olduğunu, ne zaman açığa çıktığını ve şüpheli kullanım bulunup bulunmadığını belirleyin. Eski anahtarın artık çalışmadığını ve yeni anahtarın yalnızca gereken erişimi verdiğini doğrulamak, dosyayı temizlemenin ötesindeki müdahaleyi tamamlar.

Ayrıca okuyun:

• GitHub fatura otomasyonu artık kişisel erişim anahtarına bağlı değil
• My Activity’yi silmek yetmez; tarayıcı geçmişi ayrı kalabilir
• Buffer mı Later mı? Üç kanaldan sonra fiyat modeli seçimi değiştiriyor