GitGuardian: herkese açık GitHub commit'lerinde sızan secret sayısı %34 arttı, AI destekli commit'ler iki katı hızla sızdırıyor

Herkese açık GitHub commit'lerinde sızan secret sayısı 2025'te %34 arttı

GitGuardian'ın State of Secrets Sprawl 2026 raporu, 2025 boyunca herkese açık GitHub commit'lerinde 28.649.024 yeni secret tespit etti; bu, yıllık bazda %34'lük bir artış anlamına geliyor. dev.to'da yayımlanan bir yazıda dile getirilen bu rakamlar, kod commit etme hacmiyle birlikte ölçeklenen bir hijyen sorununu gözler önüne seriyor — hem insanlar hem de giderek artan ölçüde agent'lar tarafından yazılan kod söz konusu.

AI destekli commit'ler ortalamanın iki katından fazla sızdırıyor

Raporun en çarpıcı bulgusu, SC Media'nın haberinde ayrıntılarıyla ele alınan ve dev.to'da da değinilen, commit'i kimin yazdığına ilişkin. Claude Code'un ortak yazarı olduğu commit'lerin %3,2'sinde secret sızarken, bu oran tüm herkese açık commit'lerde %1,5 — yani taban oranın iki katından fazla.

Buradaki mekanizma gizemli değil. Bir config dosyasını yazması veya güncellemesi istenen agent, geliştiricinin ortamında, shell geçmişinde veya sohbette görebildiği gerçek token'ı olduğu gibi satır içine yerleştirir. Otomasyon için kullanışlı olan şey, herkese açık repository'lerde canlı kimlik bilgileri tarayan herkes için de aynı derecede kullanışlıdır.

MCP config'leri başlı başına bir sızıntı vektörü

GitGuardian ayrıca kodlama asistanları ve diğer agent araçlarının kullandığı sunucu tanımlarını içeren MCP yapılandırma dosyalarını da taradı ve herkese açık GitHub genelinde bunlarda 24.008 benzersiz secret buldu. Bunların 2.117'si hâlâ geçerli olarak doğrulandı: az kişinin secret barındırdığını düşündüğü dosyalarda duran canlı anahtarlar.

Sızan secret'lar nadiren ölür

Rapor, ciddi bir kalıcılık rakamı daha ekliyor: GitGuardian'ın ilk kez 2022'de tespit ettiği geçerli secret'ların %64'ü dört yıl sonra hâlâ aktifti. Herkese açık bir repository'ye kimlik bilgisi push etmek geri alınabilir bir hata gibi değil, daha çok yayımlama gibi davranıyor.

Secret'ları commit oluşmadan yakalayın

dev.to yazısının çaresi bir gitleaks pre-commit hook'u; yazar, kurulumun yaklaşık on dakika sürdüğünü tahmin ediyor. Üç kurulum yolu var: pre-commit framework kullanan ekipler için .pre-commit-config.yaml dosyasına bir kayıt, husky kullanıcıları için .husky/pre-commit dosyasına bir satır ya da hiçbir araç kullanmayan repository'ler için düz bir .git/hooks/pre-commit betiği — son seçenek geliştiriciye özeldir ve commit edilmez, bu yüzden dev.to ilk ikisini tercih ediyor.

Tarama komutu her durumda aynı: gitleaks git --pre-commit --redact --staged --verbose. --staged flag'i taramayı commit etmek üzere olduğunuz diff ile sınırlar ve büyük repository'lerde hızlı kalmasını sağlar, --redact ise eşleşen secret'ların terminal kaydına düşmesini engeller. Eski rehberlerde gitleaks protect --staged komutuna atıf vardır; bu alt komut v8.19.0 sürümünde kullanımdan kaldırıldı ve artık yardım çıktısında görünmüyor.

dev.to, hook'a güvenmeden önce sahte bir AWS tarzı anahtarla test etmeyi, yanlış pozitifleri ise ya ilgili satıra bir gitleaks:allow yorumu ekleyerek ya da bulguyu parmak iziyle bir .gitleaksignore dosyasına işleyerek ele almayı öneriyor.

Secret barındıran dosyaları git'ten tamamen uzak tutun

Hook'lar içeriği tarar; .gitignore ise dosyaların tamamını dışarıda bırakır. dev.to, .env ve türevlerini yok sayıp değişken adlarıyla örnek değerler içeren bir .env.example dosyasını commit etmeyi, agent yapılandırmalarına da aynı yaklaşımı uygulamayı öneriyor: .mcp.json ile editörlerin ve asistanların sunucu tanımlarını sakladığı dizinler sık sık API anahtarlarını satır içinde içeriyor ve bu dosyalar tam olarak GitGuardian'ın 24.008 MCP bulgusunun kaynağı. Bir config'in paylaşılması gerekiyorsa, gerçek token yerine ortam değişkenlerine başvurun — aracın bunu gerçekten desteklediğini doğruladıktan sonra.

Aynı taramayı CI'da çalıştırın

Yerel hook'ların iki zayıf noktası var: yeni bir clone hook olmadan gelir ve git commit --no-verify kurulu olanı ne olursa olsun atlar. dev.to bu yüzden her push ve pull request'te gitleaks'ı fetch-depth: 0 ile tam geçmişli checkout üzerinden gitleaks-action@v3 aracılığıyla yeniden çalıştırıyor. Kuruluşlara ait repository'ler ücretsiz bir gitleaks lisans anahtarı ister; kişisel repository'ler istemez. v3'te kalmak önemli — v2, GitHub tarafından barındırılan runner'ların Eylül 2026'da kaldırdığı Node 20 üzerinde çalışıyor.

Bir secret yine de sızmışsa

dev.to'nun önerisi önce rotate etmek: kimlik bilgisini sağlayıcısında geçersiz kılın, yenisini oluşturun ve git geçmişine dokunmadan önce dağıtın; çünkü fork'lar, clone'lar ve cache'ler, geçmiş yeniden yazılsa bile herkese açık commit'leri korumaya devam eder. Ancak ondan sonra, sağlayıcının audit log'unu kullanarak ve kendi API'nizi çağıran anahtarlar için çağıranın kimliğini kaydeden istek başına log'larla, ifşa edilen anahtarın gerçekte ne yaptığını araştırın.

Neden önemli

%34'lük artış tek başına bile kaygı verici olurdu, ama asıl sinyal yazarlık ayrımında: en hızlı büyüyen commit kaynağı — AI destekli commit'ler — ortalamanın iki katından fazla oranda sızdırıyor ve bu asistanların ürettiği MCP dosyaları başlı başına bir kimlik bilgisi deposuna dönüştü, binlerce hâlâ geçerli anahtar ifşa edilmiş durumda. Karşı önlemler ucuz ve iyi biliniyor: commit öncesi aşamalı tarama, gitignore disiplini, CI'da zorunlu kılma ve bir şey sızdığı anda rotate etme. Raporun kalıcılık rakamı — 2022'de tespit edilen secret'ların neredeyse üçte ikisinin dört yıl sonra hâlâ canlı olması — bu adımları isteğe bağlı görmesinin bedelini gösteriyor.