API anahtarını koda gömmek neden tehlikeli? Sır (secret) yönetimi rehberi

API anahtarını, veritabanı parolasını ya da erişim token'ını doğrudan kaynak koduna yazmak, yazılım geliştirmede en sık yapılan ve en pahalıya patlayan hatalardan biridir. Sorun şu: bir sır bir kez depoya girdiğinde onu geri almak neredeyse imkânsızdır. GitGuardian'ın 2026 raporuna göre yalnızca 2025 yılında herkese açık GitHub depolarında yaklaşık 29 milyon yeni sır tespit edildi; bu, bir önceki yıla göre %34'lük bir artış. Çözüm, sırları bir metin satırı gibi değil; üretilen, dağıtılan ve düzenli olarak değiştirilen bir yaşam döngüsü gibi yönetmektir.

"Sır" dediğimiz şey nedir

Sır (secret), bir sisteme erişim sağlayan her türlü kimlik bilgisidir. API anahtarları, veritabanı bağlantı dizeleri, bulut erişim anahtarları (örneğin bir AWS access key), OAuth token'ları, özel şifreleme anahtarları, SSH anahtarları ve üçüncü taraf servis parolaları bu kapsama girer. Bunların ortak özelliği tek başlarına kimlik doğrulaması yapmalarıdır: anahtarı ele geçiren kişi, o anahtarın açtığı kapının arkasına parola sorulmadan girer.

Bir kez sızan sır neden geri alınamaz

Geliştiriciler çoğu zaman şöyle düşünür: anahtarı koddan silerim, sorun biter. Oysa Git bir versiyon sistemidir ve her şeyi hatırlar. Anahtarı silip yeni bir commit atsanız bile eski değer geçmişte (git history) kalır; deponun her kopyasında, her fork'ta, her klonda yaşamaya devam eder. Tek gerçek çözüm, anahtarın kendisini iptal edip yenisiyle değiştirmektir (rotasyon). Bu adımın ne kadar ihmal edildiğini rakamlar gösteriyor: 2022'de sızmış ve hâlâ geçerli olan sırların %64'ü, 2026 itibarıyla hâlâ iptal edilmemiş durumdaydı.

Gerçek bir örnek: beş yıl açıkta kalan anahtar

Toyota'nın başına gelen olay bu riski somutlaştırıyor. Aralık 2017'de bir alt yüklenici, T-Connect uygulamasının kaynak kodunun bir bölümünü yanlışlıkla herkese açık bir GitHub deposuna yükledi. Kodun içinde, müşteri veritabanına erişim sağlayan sabit kodlanmış bir anahtar vardı. Bu anahtar ancak Eylül 2022'de, yani yaklaşık beş yıl sonra fark edildi. Bu süre boyunca yaklaşık 296 bin müşterinin e-posta adresi ve müşteri numarası açığa çıkma riski taşıdı. Toyota olayı Ekim 2022'de duyurdu, anahtarı geçersiz kıldı ve depoyu özele çevirdi; ama beş yıllık erişim kayıtlarını tek tek incelemek zorunda kaldı.

Sırlar en çok nereden sızar

Akla ilk gelen herkese açık depolar olsa da tablo daha geniştir. GitGuardian verilerine göre kurum içi (private) depolar, sabit kodlanmış sır barındırma açısından herkese açık depolardan yaklaşık 6 kat daha risklidir; çünkü geliştiriciler "nasılsa dışarıya kapalı" diye rahat davranır. Sırlar ayrıca depoya yanlışlıkla eklenen .env dosyalarından, CI/CD yapılandırmalarından, log kayıtlarından, hata ekranlarından, hatta ekran görüntülerinden sızar. Son dönemde tabloya yapay zeka da eklendi: yapay zeka servislerine ait kimlik bilgilerinin sızması tek yılda %81 arttı ve yapay zeka destekli kod yazımının sır sızdırma oranını yükselttiği görülüyor.

Ortam değişkenleri (.env) yeterli mi

Sırları koddan çıkarıp ortam değişkenlerine ya da .gitignore ile hariç tutulan bir .env dosyasına taşımak, sabit kodlamaya göre büyük bir ilerlemedir ve geliştirme ortamı için makul bir başlangıçtır. Ama tam çözüm değildir. Ortam değişkenleri süreçler arasında görece kolay okunur, log'lara ve çökme dökümlerine sızabilir; bir .env dosyası yanlışlıkla commit'lenirse yine baştaki soruna dönersiniz. Üretim ortamı daha kontrollü bir yapı ister.

Doğru yaklaşım: sır yöneticisi

OWASP'ın önerisi nettir: sırlar için özel bir sır yöneticisi (secret manager) kullanın. HashiCorp Vault, AWS Secrets Manager, Google Secret Manager ve Azure Key Vault bu işi yapar. Bu araçlar sırları tek bir merkezde tutar, kimin hangi sırra eriştiğini kaydeder, erişimi yetkiyle sınırlar ve sırları çalışma anında (runtime) uygulamaya enjekte eder. Böylece sır ne kaynak kodunda ne de imaj içinde sabit olarak durur; uygulama ihtiyaç duyduğunda merkezî depodan çeker.

Kodu ve geçmişi taramak

Bir sırrın depoya hiç girmemesi, girdikten sonra temizlenmesinden çok daha ucuzdur. Bunu sağlamak için otomatik tarama şarttır. gitleaks, TruffleHog veya git-secrets gibi araçları commit öncesi (pre-commit) devreye alın; böylece bir anahtar depoya ulaşmadan yakalanır. GitHub'ın push protection özelliği, tanıdığı bir anahtar formatını push anında engeller. Bu kontrolleri CI/CD hattınıza da ekleyin ve mevcut geçmişi bir kez baştan sona tarayın; büyük olasılıkla unutulmuş birkaç sır çıkacaktır.

Rotasyon ve en az yetki

Sızmayı tamamen engelleyemezsiniz ama etkisini küçültebilirsiniz. Burada iki ilke belirleyicidir. Birincisi rotasyon: sırları düzenli aralıklarla ve bir şüphe anında hemen değiştirin, mümkünse kısa ömürlü ve otomatik yenilenen kimlik bilgileri kullanın. İkincisi en az yetki: her servis yalnızca ihtiyaç duyduğu sırra, yalnızca ihtiyaç duyduğu izinle erişsin. Bir anahtar sızsa bile açtığı kapı ne kadar darsa hasar o kadar sınırlı olur. Bu mantık, sıfır güven mimarisinin de temelidir.

Bir sır sızdıysa ne yapmalı

Panikle koddan satırı silmek en yanlış ilk adımdır. Doğru sıra şudur: önce sızan kimlik bilgisini iptal edip yenisiyle değiştirin, çünkü asıl riski taşıyan şey kod değil, hâlâ geçerli olan anahtardır. Ardından erişim kayıtlarını inceleyip anahtarın kötüye kullanılıp kullanılmadığını belirleyin, etkilenen sistemleri ve verileri kapsam olarak çıkarın, gerekiyorsa KVKK bildirim yükümlülüğünüzü değerlendirin. Kod geçmişini temizlemek en son ve en düşük öncelikli adımdır.

Atılacak adımlar bellidir: kaynak kodunuzu ve geçmişinizi bir kez tarayın, çıkan tüm sırları rotasyona sokun, üretim için ortam değişkenlerinden bir sır yöneticisine geçin ve commit öncesi taramayı zorunlu kılın. Wedevit olarak kod tabanınızı ve depolarınızı sır sızıntısına karşı tarıyor, bir sır yönetimi altyapısı kuruyor ve bunu yazılım tedarik zinciri güvenliği süreçlerinizle birlikte tasarlıyoruz.