Sırları Korumak (Secrets Detection) Neden Önemlidir?
“Secrets Detection”, yazılım geliştirme sürecinde yanlışlıkla kod içerisine, Git geçmişine, CI/CD pipeline’larına, konteyner imajlarına, “ticket” sistemlerine veya ekip içi mesajlaşma araçlarına bırakılan hassas bilgilerin bulunması, önceliklendirilmesi ve temizlenmesi sürecidir. “Secret” güvenliği yalnızca “secret manager kullanıyoruz” demekle çözülmez. “Secret manager”, gizli bilgileri güvenli saklamak için gereklidir; ancak geliştiricinin bir API key’i yanlışlıkla koda, Slack mesajına veya Jira ticket’ına yapıştırmasını tek başına engellemez. Bu nedenle kurumların ayrıca sürekli çalışan, çok kaynağı tarayan ve “remediation” sürecini yönetebilen bir “Secrets Detection Platformuna” ihtiyacı vardır.
Bir “secret” bir kez açığa çıktıysa, saldırgan için artık o bilgi bir parola, anahtar veya geçiş bileti gibi çalışabilir. Bu nedenle sırları sadece bulmak değil, hızlıca geçersiz kılmak ve tekrarını önlemek gerekir.
Öncelikle kavramların üzerinden birlikte kısaca geçelim.
| Konu | Yeni başlayanlar için anlamı | Kurumsal risk |
| Secret | Parola, token, API key, sertifika, private key, database connection string gibi sistemlere erişim sağlayan hassas bilgi. | Ele geçirilirse yetkisiz erişim, veri sızıntısı, lateral movement ve tedarik zinciri saldırısı doğurabilir. |
| Hardcoded secret | Bu hassas bilginin doğrudan kaynak kodun, config dosyasının veya script’in içine yazılması. | Git geçmişinde yıllarca kalabilir; silinse bile eski commit’lerden bulunabilir. |
| Secrets sprawl | Secrets bilgisinin kontrolsüz şekilde birçok yere yayılması. | Kimin nerede hangi secret’ı kullandığı bilinmediği için yönetişim ve denetim zayıflar. |
| Detection | Açığa çıkmış veya riskli secret’ları tarayıp bulma. | Yanlış pozitif çoksa ekipler alarm yorgunluğu yaşar; eksik tarama varsa gerçek risk kaçabilir. |
| Remediation | Bulunan secret’ı geçersiz kılma, rotate etme, koddaki kalıntıları temizleme ve tekrarını önleme. | Sadece alarm üretmek yeterli değildir; olay kapatılana kadar takip gerekir. |
Seçilecek çözüm yalnızca “kaç secret tipi buluyor?” sorusuyla değerlendirilmemeli; görünürlük kapsamı, false positive kontrolü, developer deneyimi, remediation workflow’u, SIEM/SOAR/Jira entegrasyonu, raporlama, ölçeklenebilirlik ve deployment modeli birlikte değerlendirilmelidir. Örneğin, tüm repository geçmişi, tüm branch’ler, CI/CD, container imajları, package registry’ler ve developer productivity araçları dahil edilmezse resim eksik kalır. Özellikle validity check, presence check, severity scoring, incident assignment ve otomatik kapanış gibi özellikler olmadan secret detection işi manuel ve sürdürülemez hale gelir.
“Secret”, bir sistemin başka bir sisteme kendini tanıtmasını, yetki almasını veya güvenli iletişim kurmasını sağlayan hassas bilgidir. İnsan kullanıcıların parolaları gibi düşünülebilir; ancak modern yazılım dünyasında çoğu erişim artık uygulama, servis, pipeline, bot, container veya makine kimliği üzerinden gerçekleşir. Bu yüzden “secret” güvenliği, machine identity ve access management konularının merkezindedir. “Secret” örneklerine bakalım.
| Secret türü | Basit açıklama | Yanlışlıkla nerede sızabilir? |
| API key / token | Bir servisin başka bir servisi kullanmasına izin veren anahtar. | Kaynak kod, .env dosyası, README, CI/CD değişkenleri, log dosyaları. |
| Database URL / connection string | Uygulamanın veritabanına bağlanmasını sağlayan adres, kullanıcı adı ve parola bilgisi. | Config dosyası, test script’i, Docker Compose dosyası, ticket açıklaması. |
| Cloud access key | AWS, Azure, GCP gibi bulut platformlarında API çağrısı yapmaya yarayan kimlik bilgisi. | Terraform dosyası, pipeline log’u, geliştiricinin kişisel GitHub reposu. |
| Private key / SSH key | Sunucuya, Git deposuna veya şifreli kanala erişim sağlayan özel anahtar. | Repo, backup klasörü, Slack mesajı, yanlışlıkla paylaşılan arşiv dosyası. |
| Certificate / client secret | Sistemler arası güvenli kimlik doğrulamada kullanılan bilgi. | Kubernetes secret export’u, Helm values dosyası, test ortamı konfigürasyonu. |
| Webhook URL | Dış sistemlerin belirli bir endpoint’e olay göndermesini sağlayan özel URL. | Jira ticket, dokümantasyon, log veya örnek kod. |
“Secret” ile hassas veri aynı şey değildir. Kredi kartı numarası veya kişisel veri hassas veridir; API key veya private key ise sisteme erişim sağlayan anahtardır. Secret sızıntısı çoğu zaman saldırgana başka hassas verilere ulaşmanın yolunu açar.
“Hardcoded secret”, “secret” bilgisinin kod veya konfigürasyon içine doğrudan yazılmasıdır. Geliştirici bunu çoğu zaman hız kazanmak, test yapmak veya pipeline’ı çalışır hale getirmek için yapar. Ancak kod Git’e push edildiğinde “secret” yalnızca o anki dosyada değil, Git geçmişinde de kalır. Dosyadan silmek çoğu zaman yeterli değildir; çünkü eski commit’lerde aynı bilgi bulunabilir.
- Saldırgan secret’ı kullanarak ilk erişim elde edebilir.
- Erişim elde edildikten sonra başka sistemlere yatay hareket yapılabilir.
- Secret geçerli kalmaya devam ederse saldırgan uzun süre fark edilmeden sistemde kalabilir.
- Güvenlik ekibi olayın nereden başladığını geç fark edebilir veya hiç anlayamayabilir.
“Secret” yaşam döngüsünü aşağıdaki şekilde tarifleyebiliriz.
| Aşama | Ne olur? | Kontrol noktası |
| Provisioning | Secret oluşturulur veya bir sistem tarafından üretilir. | Secret manager, IAM politikası, onay süreci. |
| Distribution | Secret uygulamaya, pipeline’a veya runtime ortamına ulaştırılır. | Erişim kontrolü, least privilege, audit log. |
| Use | Uygulama veya pipeline secret’ı kullanır. | Runtime izleme, log masking, kullanım denetimi. |
| Exposure | Secret yanlışlıkla koda, log’a, ticket’a veya mesajlaşma aracına girer. | Secrets detection, pre-commit, PR scanning, CI/CD scanning. |
| Rotation / revocation | Secret geçersiz kılınır veya yenisiyle değiştirilir. | Otomatik playbook, secrets manager entegrasyonu, doğrulama. |
| Retirement | Secret artık kullanılmıyorsa kapatılır. | Periyodik temizlik, sahiplik kontrolü. |
Modern yazılım geliştirme süreci yalnızca kod yazmaktan ibaret değildir. Planlama, kodlama, test, build, deployment, runtime monitoring, incident management ve dokümantasyon gibi birçok adım vardır. Secret bilgileri de bu adımların hemen hepsinde kullanılabilir. Bu nedenle risk sadece kaynak kod deposuyla sınırlı değildir. Geliştiriciler yazılım teslimatının merkezindedir. Hızlı teslimat beklentisi arttıkça geliştiriciler aynı gün içinde kod, test, pipeline, deployment, log, ticket ve dokümantasyon arasında sürekli bağlam değiştirir. Bu hız ve yoğunluk, güvenlik hatalarının istemeden yapılmasını kolaylaştırır. CWE-798 zafiyetinden sakınmak son derece elzemdir. CWE-798 , “Use of Hard-coded Credentials” yani kimlik bilgilerinin doğrudan kod içine yazılması zafiyetidir. SQL Injection veya XSS gibi klasik uygulama zafiyetlerinden farklıdır; çünkü yalnızca kod satırında değil, geliştirme ve operasyon araçlarının tamamında ortaya çıkabilir.
Bir kurum açık kaynak katkısı yapmıyor olsa bile çalışanları kişisel GitHub hesaplarında proje paylaşabilir. Bu kişisel depolar, gists, issue yorumları veya deneme projeleri kurumun kontrolünde değildir. Buna rağmen kurumsal API key veya test ortamı credential’ı yanlışlıkla bu alanlara girebilir.
- Riskin özeti: Kurum içi bir secret, kurum dışındaki kişisel bir GitHub/GitLab reposunda görünebilir.
- Görünürlük problemi: Security ekibi yalnızca kurumsal GitHub/GitLab organizasyonunu tarıyorsa bu sızıntıyı hiç görmeyebilir.
- Aksiyon ihtiyacı: Public leakage detection, kişisel repo, gist, issue ve comment alanlarını da kapsayabilmelidir.
Bir XSS veya runtime exploit geliştirmek teknik bilgi ve deneme gerektirebilir. Ancak geçerli bir cloud access key veya database credential bulunduğunda saldırgan doğrudan API çağrısı yapabilir, sisteme bağlanabilir veya başka sistemlere geçiş yapabilir. Bu yüzden secret sızıntıları düşük eforlu ama yüksek etkili saldırı kapısıdır. Kurumlarda secret yönetimi çoğu zaman birden fazla aracın arasında dağılır: cloud provider secret store, Kubernetes secrets, CI/CD değişkenleri, HashiCorp Vault veya benzeri secret manager’lar, on-prem çözümler ve geliştirici araçları. Bu parçalı yapı; standardizasyon, sahiplik, denetim ve operasyon sorumluluğu problemleri doğurur. Aşağıda, her bir sorunun neden kritik olduğunu görüyoruz.
| Soru | Neden kritik? |
| Secret güvenliğinden kim sorumlu? | Development, infrastructure ve security ekipleri arasında net sahiplik yoksa olaylar sahipsiz kalır. |
| Hangi secret nerede tutuluyor? | Birden fazla secret store kullanılıyorsa merkezi görünürlük zorlaşır. |
| Secret açığa çıktığında kim rotate edecek? | Sahiplik belirsizse remediation süresi uzar. |
| Politika tüm ekiplere nasıl uygulanacak? | Sadece merkezi karar yeterli değildir; IDE, Git, CI/CD ve ticket akışlarına da inmek gerekir. |
SAST, CSPM, secrets manager ve open-source scanner araçları güvenlik mimarisinin önemli parçalarıdır. Bu araçların her biri belirli bir problemi çözer; secret sızıntısı problemini uçtan uca çözmek için tek başına yeterli değildir.
| Yaklaşım | Ne için iyidir? | Secret güvenliği açısından eksik tarafı | Nasıl tamamlanmalı? |
| SAST | Kaynak kodda güvenlik zafiyetleri ve yanlış konfigürasyonları bulmak. | Genellikle son kod revizyonuna odaklanır; tüm Git geçmişi ve tüm branch’ler taranmayabilir. Dil bağımlılığı olabilir; generic secret tespitinde zayıf kalabilir. | Git geçmişi, branch’ler, generic secret algoritmaları, validity/presence check ve remediation workflow’u olan secret detection ile tamamlanmalı. |
| CSPM | Cloud ortamındaki yanlış konfigürasyonları ve runtime risklerini görmek. | Development ortamında, source code ve build sistemlerinde oluşan secret sızıntılarını göremeyebilir. | Cloud posture görünürlüğü, development pipeline görünürlüğü ile birleştirilmeli. |
| Secrets manager / vault | Secret’ları merkezi, güvenli ve kontrollü saklamak. | Secret bir kez vault dışına çıktıktan sonra, örneğin koda veya Slack’e yapıştırıldığında bunu tek başına engellemez. | Secret manager ile detection/remediation platformu entegre edilmeli; sızıntı olduğunda revoke/rotate tetiklenmeli. |
| Open-source scanner | Basit regex veya entropy temelli hızlı tarama yapmak. | False positive/false negative dengesi zayıf olabilir; incident lifecycle, atama, feedback, raporlama ve önceliklendirme sunmayabilir. | Kurumsal ölçekte yönetim, analytics, workflow ve entegrasyon sunan platformla desteklenmeli. |
“Bizde SAST var, secret detection’a gerek var mı?” sorusu eksiktir. Daha doğru soru şudur: SAST aracımız tüm Git geçmişini, tüm branch’leri, generic secret pattern’larını, public leakage durumunu ve remediation kapanışını yönetebiliyor mu?
“Dedicated secrets detection” ve “remediation” platformunun amacı yalnızca sızıntıları yakalamak değildir. Amaç, kurumun secret güvenliği duruşunu sürekli ölçmek, zayıflıkları azaltmak, geliştirici ekipleriyle güvenlik ekipleri arasında işbirliği kurmak ve olayları kapatana kadar takip etmektir. Platformun uçtan uca aşağıda olan akışı kapsaması önemlidir.
| Aşama | Platformdan beklenen kabiliyet | Başarı göstergesi |
| Keşif | Repository, Git history, CI/CD, container image, package registry, Jira, Confluence, Slack gibi kaynakları tarama. | Kurumun gerçek attack surface’i görünür hale gelir. |
| Tespit | Specific, generic ve custom pattern’ları yakalama; regex, entropy ve ML gibi teknikleri birlikte kullanma. | Kaçırılan gerçek secret oranı düşer. |
| Doğrulama | Validity ve presence check ile secret’ın gerçekten kullanılabilir olup olmadığını kontrol etme. | False positive azalır; kritik incident’lar öne çıkar. |
| Önceliklendirme | Severity scoring, kaynak kritikliği ve public leakage bilgisiyle risk sıralaması yapma. | Ekipler önce en riskli olaylara odaklanır. |
| Atama | İlgili geliştirici, repo sahibi veya ekip ile olayı ilişkilendirme. | Incident sahipsiz kalmaz. |
| Remediation | Revoke/rotate/replace adımlarını yönlendirme; Jira/SOAR/SIEM entegrasyonu. | Olaylar ölçülebilir şekilde kapanır. |
| Öğrenme | False positive feedback, ignore reason, policy update ve developer eğitimi. | Aynı hataların tekrarı azalır. |
Bir AWS Access Key Git geçmişinde bulunursa platform önce bunun geçerli olup olmadığını kontrol etmeli, secret’ın production ile ilişkili olup olmadığını anlamalı, ilgili repo sahibine görev açmalı, rotation yapıldığını doğrulamalı ve aynı secret’ın başka repository’lerde tekrar edip etmediğini tek incident altında gruplayabilmelidir.
Böyle bir platform seçerken nelere dikkat etmeliyiz? Yazılım tedarik zincirinin tamamında görünürlük önemlidir. Platform, yalnızca tek bir Git reposunu değil, yazılımın üretildiği ve çalıştırıldığı tüm kaynakları izleyebilmelidir. Version Control System, CI/CD, container image registry, package registry ve developer productivity araçları birlikte düşünülmelidir. Secret sızıntısı sadece kodda olmaz. Slack mesajında, Jira ticket’ında, Confluence sayfasında, Docker image layer’ında veya eski bir Git branch’inde kalabilir. Görünmeyen kaynak güvenli değildir. Birinci sınıf detection yeteneği diğer önemli kriterlerden birisidir. Detection motoru secret’ları yüksek doğrulukla bulabilmelidir. Secret tipleri sabit formatlı olabilir; ancak çok sayıda secret generic yapıda olduğu için yalnızca bilinen prefix’lere bakmak yeterli değildir. Kaçırılan bir “secret” saldırgana doğrudan erişim sağlayabilir. Öte yandan çok fazla false positive üretmek ekiplerin araca güvenini azaltır. False positive kontrolünü unutmamak gerekir. False positive, aslında risk olmayan bir şeyi risk gibi göstermektir. Security ve development ekipleri sürekli yanlış alarm görürse uyarıları önemsememeye başlar. Secrets detection’da hedef hem yüksek recall hem de yüksek precision’dır. Yani gerçek secret’ları kaçırmamak, ama ekiplere gereksiz alarm yüklememek gerekir. Remediation yani detection’ı aksiyona çevirmek gözden kaçırılmamalıdır. Bir secret bulunduğunda iş bitmez; asıl değer olayın kapanmasındadır. Remediation, secret’ın revoke/rotate edilmesi, kodun temizlenmesi, sahibinin bulunması ve kapanışın doğrulanmasıdır. Developer experience, eğitim ve erken geri bildirim son derece önemlidir. Güvenlik aracı geliştiricinin işini zorlaştırırsa benimsenmez. İyi bir platform, geliştiriciye hatayı en erken noktada, mümkünse IDE, pre-commit veya pull request aşamasında gösterir. Secret henüz shared repository’ye push edilmeden yakalanırsa incident maliyeti çok düşer. Bu “shift left” yaklaşımının secrets güvenliği tarafındaki karşılığıdır. Reporting ve analytics gücünü değerlendirmeyi sakın göz ardı etmeyin. Raporlama, kurumun secret güvenliği duruşunu ölçmek için gereklidir. Kaç secret bulundu, ne kadarı geçerliydi, ne kadar sürede kapandı, hangi ekiplerde tekrar ediyor gibi sorulara yanıt verilmelidir. Ölçemediğiniz şeyi iyileştiremezsiniz. Yönetim, AppSec, DevOps ve compliance ekipleri farklı görünüm ve metriklere ihtiyaç duyar. Kullanıcı dostu arayüz ve kullanım kolaylığı yine önemli bir değerlendirme kriteridir. Platform güçlü olsa bile kullanımı zor ise operasyonel değer üretmesi gecikir. Security ekibi merkezi dashboard isterken, developer yalnızca kendi scope’undaki incident’ları görmek ister. Farklı kullanıcı profillerinin farklı ihtiyaçları vardır. Tek bir karmaşık ekran herkese aynı anda hitap etmeyebilir. Ölçeklenebilirlik asla unutulmamalıdır. Kurum büyüdükçe repository sayısı, branch sayısı, geliştirici sayısı, pipeline sayısı ve taranacak veri hacmi artar. Platform bu büyümeyi kaldırabilmelidir. Başlangıçta 20 repository taramak kolay olabilir; ancak enterprise ortamda binlerce repository, büyük monorepo’lar, yüksek commit hacmi ve farklı VCS sunucuları olabilir. Deployment model seçenekleri kritiktir. Bazı kurumlar SaaS modelini tercih ederken, bazıları regülasyon, veri güvenliği veya altyapı kontrolü nedeniyle self-hosted model ister. Platformun deployment seçenekleri kurumun güvenlik ve uyum ihtiyaçlarına uymalıdır. Secrets detection aracı kaynak kodu ve potansiyel hassas bilgileri göreceği için deployment modeli kritik bir güvenlik kararıdır. Support ve uzmanlık ihmal edilmemelidir. Secrets detection programı yalnızca ürün kurulumu değildir; rollout, ekiplerin ikna edilmesi, policy tasarımı, remediation workflow’u ve metrik takibi gerektirir. Bu nedenle vendor uzmanlığı önemlidir. Enterprise ölçekte başarılı olmak için teknik destek kadar danışmanlık yaklaşımı da gerekir. İlk historical scan sonrası binlerce incident çıkabilir; kurum nereden başlayacağını bilmelidir.
Secrets manager, secret’ları güvenli saklamak, erişimi kontrol etmek ve dağıtımı yönetmek için kullanılan temel çözümdür. Ancak secret bir kez vault dışına çıktığında, örneğin kod içine yapıştırıldığında veya bir ticket açıklamasına yazıldığında, secrets manager bunu otomatik olarak göremeyebilir. Bu nedenle secrets manager ile secrets detection platformunun birlikte çalışması daha güçlü bir model oluşturur.
Secrets manager ile detection entegrasyonunu aşağıdaki tabloda olduğu gibi detaylandırabiliriz.
| Entegrasyon noktası | Beklenen fayda |
| Rogue / out-of-band secret keşfi | Vault dışında oluşturulan veya kullanılan secret’lar bulunur; kurum politikalarına geri kazandırılır. |
| Sızıntı bildirimi | Detection platformu, secret’ın açığa çıktığını secrets manager’a veya ilgili otomasyon katmanına bildirir. |
| Rotation / revocation tetikleme | Geçerli secret açığa çıktıysa otomatik rotate veya revoke süreci başlatılır. |
| Kapanış doğrulama | Secret invalid hale geldiğinde incident otomatik kapanabilir. |
| Lifecycle görünürlüğü | Secret’ın oluşturulmasından kullanımına ve emekliliğine kadar daha bütüncül görünüm sağlanır. |
Secrets manager “doğru saklama yeri”, secrets detection platformu ise “yanlış yerde duran secret’ları bulma ve temizleme mekanizması” olarak düşünülmelidir. İkisi rakip değil, birbirini tamamlayan katmanlardır. Secrets detection programı tek seferlik tarama projesi gibi ele alınmamalıdır. En sağlıklı yaklaşım, görünürlük kazanma, riskleri önceliklendirme, geliştirici süreçlerine entegrasyon ve sürekli iyileştirme adımlarını kapsayan bir program oluşturmaktır. Büyük kurumlarda ilk tarama sonucunda çok sayıda eski secret bulunabilir. Panik yerine risk bazlı yaklaşılmalıdır: geçerli secret mı, production erişimi var mı, public’e sızmış mı, kaç yerde geçiyor, sahibi kim? Önceliklendirme bu sorularla yapılmalıdır.
Sarav Asiye Yiğit * 11 Temmuz 2026 Cumartesi
Kaynakça:
GitGuardian Enterprise Buyer’s Guide for Secrets Detection, 10 Keys Considerations when Choosing a Secrets Detection Platform