# Secret, API Key ve Hassas Veri Sızıntıları: Kod Depolarında Görünmeyen Tehlike

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/secret-api-key-hassas-veri-sizintilari

![Secret, API Key ve Hassas Veri Sızıntıları: Kod Depolarında Görünmeyen Tehlike](/images/bilgi-merkezi/covers/cover-kod-06.webp)

Modern yazılım geliştirme süreçlerinde kaynak kod yalnızca uygulama mantığını içermez.

Çoğu zaman uygulamanın diğer sistemlerle nasıl haberleştiğini, hangi servisleri kullandığını ve hangi kimlik bilgileriyle erişim sağladığını da dolaylı veya doğrudan ortaya koyar.

Bu nedenle kaynak kod güvenliğinin en kritik konularından biri yalnızca klasik güvenlik açıkları değildir.

Bir başka kritik risk alanı şudur:

**Secret Exposure.**

Yani;

- parola,
- API key,
- access token,
- private key,
- database credential,
- cloud credential,
- servis hesabı bilgisi

gibi hassas verilerin kaynak kod içerisinde veya kod repository'sinde açığa çıkması.

Bu problem ilk bakışta basit görünebilir.

Bir geliştirici test için bir API anahtarını geçici olarak kod içerisine yazar.

Sonra unutulur.

Kod Git repository'sine gönderilir.

Aylar sonra ilgili API key silinir.

Ekip problemin çözüldüğünü düşünür.

Ancak aslında risk devam ediyor olabilir.

Çünkü Git yalnızca mevcut dosya durumunu değil, geçmiş commit'leri de tutar.

Bu nedenle bir secret kaynak koda bir kez girdiyse yalnızca dosyadan silinmesi yeterli olmayabilir.

Asıl soru şudur:

#### Bu bilgi daha önce kimlerin erişebildiği bir repository içerisinde bulundu?

Ve daha da önemlisi:

#### Bu credential hâlâ geçerli mi?

Modern Application Security programlarında bu nedenle Secret Scanning, Credential Rotation, Secrets Management ve Repository Security ayrı bir güvenlik katmanı olarak ele alınır.

### \1. Secret Nedir?

Yazılım güvenliği bağlamında “secret”, yetkisiz kişiler tarafından görülmemesi gereken kimlik doğrulama veya erişim bilgisidir.

Secret örnekleri şunlardır:

- kullanıcı parolaları,
- veritabanı kullanıcı adı ve parolaları,
- API key,
- OAuth client secret,
- access token,
- refresh token,
- SSH private key,
- TLS private key,
- cloud access key,
- service account credential,
- webhook secret,
- encryption key,
- signing key.

Bu bilgilerden herhangi biri saldırganın eline geçtiğinde ilgili servis veya sistem üzerinde yetkisiz erişim sağlanabilir.

Dolayısıyla secret güvenliği yalnızca yazılım geliştiricinin konusu değildir.

Aynı zamanda;

#### Identity Security, Cloud Security, DevSecOps ve Application Security

alanlarının kesişim noktasındadır.

### \2. Hard-Coded Credential Nedir?

Hard-coded credential, parola, token veya benzeri hassas bir bilginin doğrudan kaynak kod içerisine yazılmasıdır.

Örneğin şu yapı ciddi risk oluşturabilir:

db_password = "CompanyProdDb123"

veya:

api_key = "sk_live_xxxxxxxxx"

Bu yaklaşım geliştirici açısından kolaydır.

Uygulama ilgili credential'ı doğrudan kullanabilir.

Ancak güvenlik açısından büyük problem oluşturur.

Çünkü kaynak kodu görebilen herkes credential'a da erişebilir.

Bu kişiler arasında:

- geliştiriciler,
- dış kaynak yazılım ekipleri,
- repository yöneticileri,
- eski çalışanlar,
- CI/CD servisleri,
- saldırganlar

bulunabilir.

Dolayısıyla kod içerisinde credential tutmak güven sınırını gereksiz şekilde genişletir.

### \3. Geliştiriciler Neden Secret'ları Koda Yazar?

Hard-coded credential probleminin çoğu zaman kötü niyetli bir nedeni yoktur.

Genellikle geliştirme kolaylığı nedeniyle oluşur.

Örneğin geliştirici yeni bir servis entegrasyonu yapmaktadır.

Servis sağlayıcı bir API key vermiştir.

Geliştirici hızlı test yapmak için anahtarı doğrudan kod içerisine yazar.

Test başarılı olur.

Sonra başka bir task'e geçilir.

Credential kod içerisinde kalır.

Başka bir yaygın senaryo ise config dosyalarıdır.

Örneğin:

.env

config.json

application.properties

settings.py

gibi dosyalarda hassas bilgiler bulunabilir.

Bu dosyalar yanlışlıkla repository'ye gönderildiğinde secret exposure oluşabilir.

### \4. “Ama Repository Private” Yaklaşımı Güvenli midir?

Private repository public repository'ye göre daha güvenlidir.

Ancak bu, secret'ların burada güvenli şekilde tutulabileceği anlamına gelmez.

Çünkü private repository'ye birçok kişi veya servis erişebilir.

Örneğin:

- yazılım geliştiriciler,
- DevOps ekipleri,
- QA ekipleri,
- danışman firmalar,
- dış kaynak geliştiriciler,
- CI/CD robot hesapları.

Ayrıca repository hesabı ele geçirilebilir.

Yetkisiz kullanıcı organizasyona davet edilebilir.

Access token sızabilir.

Eski çalışanın erişimi kapatılmamış olabilir.

Dolayısıyla temel prensip şu olmalıdır:

**Secret, kaynak kod içerisinde bulunmamalıdır.**

Repository'nin private olması bu prensibi değiştirmez.

### \5. Git Geçmişi Neden Kritiktir?

Git sistemlerinin en güçlü özelliklerinden biri versiyon geçmişidir.

Bir geliştirici kod üzerinde değişiklik yaptığında önceki versiyonlar kaybolmaz.

Commit geçmişinde saklanır.

Bu özellik yazılım geliştirme için son derece değerlidir.

Ancak secret güvenliği açısından önemli bir risk oluşturur.

Örneğin geliştirici şu satırı repository'ye göndermiş olsun:

password = "ProdSecret123"

Bir gün sonra hatayı fark eder ve satırı siler.

Mevcut kod içerisinde parola artık görünmemektedir.

Ancak önceki commit açıldığında parola hâlâ görülebilir.

Bu nedenle:

**“Secret'ı koddan sildik.”**

ifadesi çoğu zaman yeterli değildir.

Gerçek soru:

**“Credential değiştirildi mi?”**

olmalıdır.

### \6. Bir Secret Repository'ye Girdiyse Ne Yapılmalıdır?

En güvenli yaklaşım secret'ı compromised, yani ele geçirilmiş kabul etmektir.

Örneğin bir production API key Git repository'ye gönderildiyse şu işlemler yapılmalıdır:

- Credential derhal iptal edilmeli veya devre dışı bırakılmalıdır.
- Yeni credential oluşturulmalıdır.
- Uygulama yeni credential ile güncellenmelidir.
- Secret repository'den temizlenmelidir.
- Git geçmişi gerekiyorsa temizlenmelidir.
- İlgili credential'ın kullanım logları incelenmelidir.
- Yetkisiz kullanım olup olmadığı araştırılmalıdır.

Sadece satırı silmek yeterli değildir.

Çünkü bir saldırgan daha önce repository'ye erişmiş olabilir.

### \7. Credential Rotation Nedir?

Credential Rotation, kullanılan parola, API key, token veya benzeri bilgilerin belirli aralıklarla ya da bir güvenlik olayı sonrasında değiştirilmesidir.

Secret exposure tespit edildiğinde rotation kritik önem taşır.

Örneğin eski API key:

KEY-001

iptal edilir.

Yeni API key:

KEY-002

oluşturulur.

Uygulama yeni anahtarı kullanmaya başlar.

Böylece eski credential saldırganın elinde olsa bile artık kullanılamaz.

Kurumsal ortamlarda credential rotation mümkün olduğunca otomatik hale getirilmelidir.

### \8. Secret Scanning Nedir?

Secret Scanning, kaynak kod, repository veya commit geçmişi içerisinde hassas credential bilgilerini otomatik olarak tespit etmeye çalışan güvenlik yöntemidir.

Secret scanning sistemleri farklı yöntemler kullanabilir.

Örneğin:

- pattern matching,
- regular expression,
- entropy analysis,
- known token format detection,
- provider-specific signature detection

yöntemleri kullanılabilir.

Örneğin belirli cloud sağlayıcılarının API key formatları biliniyorsa sistem bu yapıları otomatik olarak tespit edebilir.

Benzer şekilde private key header'ları veya yüksek entropy değerine sahip tokenlar analiz edilebilir.

### \9. Entropy Analysis Nedir?

Birçok secret rastgele ve karmaşık karakterlerden oluşur.

Örneğin:

h7sK92mDxT5pQ1zL

gibi bir string normal metinden farklı görünür.

Entropy analysis, bir değerin ne kadar rastgele ve tahmin edilemez olduğunu ölçmeye çalışır.

Yüksek entropy değerine sahip uzun string'ler potansiyel secret olarak işaretlenebilir.

Ancak bu yöntem tek başına yeterli değildir.

Çünkü hash değerleri, UUID'ler veya test verileri de yüksek entropy gösterebilir.

Bu nedenle gelişmiş secret scanning sistemleri farklı yöntemleri birlikte kullanır.

### \10. Secret Scanning SAST'tan Farklı mıdır?

Evet.

SAST kaynak kod içerisindeki güvenlik zayıflıklarını ve veri akışlarını analiz eder.

Secret Scanning ise özellikle hassas credential bilgilerini tespit etmeye odaklanır.

Örneğin SAST şu problemi bulabilir:

**Kullanıcı girdisi SQL sorgusuna güvenli olmayan şekilde ulaşıyor.**

Secret Scanning ise şunu bulabilir:

**Kaynak kod içerisinde production API key bulunuyor.**

Bu nedenle modern AppSec programlarında ikisi birlikte kullanılır:

#### SAST + Secret Scanning

Ancak bunun yanında SCA da önemlidir.

Sonuçta temel üçlü şu hale gelir:

**SAST + SCA + Secret Scanning**

### \11. Secret Scanning Hangi Aşamalarda Yapılmalıdır?

Secret scanning yalnızca repository üzerinde periyodik tarama olarak kullanılmamalıdır.

Mümkün olduğunca erken aşamada çalışmalıdır.

Örneğin:

#### Developer Workstation

Geliştirici commit oluşturmadan önce local scanning yapılabilir.

#### Pre-Commit Hook

Commit oluşturulmadan önce secret kontrolü yapılabilir.

#### Push

Kod remote repository'ye gönderildiğinde tarama çalıştırılabilir.

#### Pull Request

Merge öncesinde kontrol yapılabilir.

#### CI/CD Pipeline

Build sırasında secret scanning gerçekleştirilebilir.

#### Repository History

Mevcut ve eski commit'ler periyodik olarak taranabilir.

Amaç secret'ın mümkün olduğunca repository'ye hiç ulaşmamasıdır.

### \12. Pre-Commit Secret Scanning Neden Önemlidir?

En iyi güvenlik kontrolü problemi en erken aşamada engelleyendir.

Secret remote repository'ye gönderilmeden local ortamda tespit edilirse risk ciddi ölçüde azalır.

Örneğin geliştirici yanlışlıkla .env dosyasını commit etmeye çalışır.

Pre-commit scanner şu uyarıyı verebilir:

#### Potential API Secret Detected

Commit engellenir.

Geliştirici ilgili bilgiyi kaldırır.

Bu durumda secret repository geçmişine hiç girmez.

Bu, incident sonrasında Git geçmişi temizlemekten çok daha kolaydır.

### \13. .gitignore Yeterli midir?

.gitignore, Git repository'ye gönderilmemesi gereken dosyaları tanımlamak için oldukça faydalıdır.

Örneğin:

.env

secrets.json

private.key

gibi dosyalar ignore listesine eklenebilir.

Ancak .gitignore tek başına güvenlik kontrolü değildir.

Çünkü dosya daha önce commit edilmişse sonradan .gitignore eklemek onu repository geçmişinden kaldırmaz.

Ayrıca geliştirici yanlış konfigürasyon yapabilir.

Bu nedenle .gitignore iyi bir koruma katmanıdır ancak Secret Scanning'in yerine geçmez.

### \14. Environment Variable Kullanmak Güvenli midir?

Environment Variable, secret'ların doğrudan kaynak kod içerisinde tutulmasını engellemek için yaygın kullanılan yöntemlerden biridir.

Örneğin uygulama:

DATABASE_PASSWORD

değerini environment üzerinden okuyabilir.

Bu yöntem hard-coded credential'a göre daha güvenlidir.

Ancak environment variables da her durumda ideal secret management çözümü değildir.

Çünkü;

- process environment içerisinden görülebilir,
- debug output'a düşebilir,
- container configuration içerisinde açığa çıkabilir,
- yanlış CI/CD logging nedeniyle leak olabilir.

Dolayısıyla daha kritik ortamlarda merkezi Secrets Management sistemleri tercih edilebilir.

### \15. Secrets Manager Nedir?

Secrets Manager, credential bilgilerini merkezi ve kontrollü şekilde saklamayı sağlayan sistemdir.

Bu sistemler genellikle:

- access control,
- encryption,
- audit logging,
- versioning,
- credential rotation

özellikleri sağlar.

Uygulama secret'ı kaynak koddan okumak yerine çalışma anında merkezi sistemden alır.

Bu yaklaşımın önemli avantajlarından biri erişim kontrolüdür.

Örneğin yalnızca belirli production servisinin ilgili database credential'a erişmesine izin verilebilir.

Geliştiricinin credential'ı doğrudan görmesi gerekmeyebilir.

### \16. Vault Yaklaşımı

Vault mantığı merkezi secret yönetiminin en güçlü örneklerinden biridir.

Bu yapıda secret'lar şifreli şekilde saklanır.

Uygulamalar kimlik doğrulandıktan sonra ihtiyaç duydukları credential'a erişebilir.

Daha gelişmiş sistemlerde statik parolalar yerine dinamik credential oluşturulabilir.

Örneğin uygulama veritabanına bağlanmak istediğinde vault geçici kullanıcı adı ve parola üretebilir.

Credential yalnızca belirli süre geçerli olur.

Bu model saldırı yüzeyini önemli ölçüde azaltabilir.

### \17. Dynamic Secrets Nedir?

Dynamic Secret, önceden oluşturulup aylarca kullanılan sabit credential yerine ihtiyaç anında otomatik oluşturulan kısa ömürlü credential'dır.

Örneğin:

Uygulama database erişimi ister.

Secrets platformu geçici database hesabı oluşturur.

Credential 30 dakika geçerli olur.

Süre sonunda otomatik iptal edilir.

Bu yaklaşım şu probleme cevap verir:

#### Bir credential ele geçirilirse ne kadar süre kullanılabilir?

Statik parola aylarca geçerli olabilir.

Dynamic secret ise dakikalar içerisinde geçersiz hale gelebilir.

### \18. Least Privilege Secret Management

Secret güvenliğinde yalnızca credential'ın nerede saklandığı değil, hangi yetkiye sahip olduğu da önemlidir.

Örneğin uygulama yalnızca belirli database tablolarını okumaya ihtiyaç duyuyorsa kullanılan hesap database administrator yetkisine sahip olmamalıdır.

Temel prensip:

**Her credential yalnızca ihtiyaç duyduğu minimum yetkiye sahip olmalıdır.**

Bu Least Privilege yaklaşımı sayesinde credential çalınsa bile saldırganın erişimi sınırlandırılabilir.

### \19. Cloud Credential Sızıntıları Neden Kritiktir?

Cloud ortamlarında access key ve service account credential'ları son derece kritik olabilir.

Bir cloud credential saldırganın eline geçtiğinde;

- yeni kaynak oluşturma,
- storage erişimi,
- secret okuma,
- compute instance oluşturma,
- IAM yapılandırmasını değiştirme

gibi işlemler mümkün olabilir.

Yetki seviyesine bağlı olarak bütün cloud hesabı risk altına girebilir.

Bu nedenle cloud credential'ları kaynak kod içerisinde kesinlikle tutulmamalıdır.

### \20. Cloud Access Key Yerine Ne Kullanılmalıdır?

Modern cloud mimarilerinde mümkün olduğunca statik access key yerine workload identity veya role tabanlı erişim kullanılmalıdır.

Örneğin bir compute instance'ın storage servisine erişmesi gerekiyorsa uygulamaya hard-coded cloud access key vermek yerine instance role atanabilir.

Bu durumda uygulamanın kaynak kodunda secret bulunmaz.

Cloud platformu geçici credential üretir.

Bu yaklaşım secret management ihtiyacını önemli ölçüde azaltır.

### \21. Service Account Güvenliği

Modern mikroservis mimarilerinde servisler birbirleriyle iletişim kurar.

Bu nedenle service account kullanımı yaygındır.

Ancak service account credential'larının kod içerisine yazılması ciddi güvenlik riski yaratır.

Service account'lar için:

- minimum yetki,
- kısa ömürlü token,
- düzenli rotation,
- kullanım loglama,
- environment isolation

uygulanmalıdır.

Ayrıca development ve production servis hesapları birbirinden ayrılmalıdır.

### \22. Development ve Production Credential Ayrımı

Geliştirme ortamında kullanılan credential'ların production ile aynı olması büyük güvenlik problemidir.

Development ortamına daha fazla geliştirici erişebilir.

Test script'leri bulunabilir.

Debug logları daha detaylı olabilir.

Dolayısıyla development credential sızarsa production sistemine erişim sağlanmamalıdır.

İdeal yapı:

#### Development Credential

#### Test Credential

#### Staging Credential

#### Production Credential

olarak ayrılmalıdır.

Her environment farklı güvenlik sınırına sahip olmalıdır.

### \23. Private Key Sızıntıları

Private key'ler en kritik secret türlerinden biridir.

Örneğin:

- SSH private key,
- TLS private key,
- JWT signing private key,
- code signing key

kaynak kod repository'sine girerse ciddi risk oluşabilir.

Private key'in türüne göre saldırgan;

- sisteme SSH bağlantısı,
- sahte token üretme,
- başka sunucu gibi davranma,
- sahte yazılım imzalama

gibi saldırılar gerçekleştirebilir.

Bu nedenle private key exposure kritik güvenlik olayı olarak değerlendirilmelidir.

### \24. JWT Signing Key Sızarsa Ne Olur?

JWT tabanlı authentication sistemlerinde token'lar bir secret veya private key ile imzalanabilir.

Eğer signing key saldırganın eline geçerse saldırgan geçerli görünen sahte token'lar üretebilir.

Örneğin kendi token'ına:

role: admin

ekleyebilir.

Eğer backend yalnızca imzayı doğruluyorsa token geçerli kabul edilebilir.

Bu nedenle signing key güvenliği authentication sisteminin temel güvenlik sınırlarından biridir.

### \25. Encryption Key Kaynak Kod İçerisinde Olabilir mi?

Olmamalıdır.

Şifrelenmiş verinin güvenliği büyük ölçüde encryption key'in güvenliğine bağlıdır.

Eğer uygulama verileri güçlü algoritma ile şifreliyor ancak key'i aynı kaynak kod içerisinde tutuyorsa saldırgan hem şifreli veriyi hem anahtarı ele geçirebilir.

Bu durum gerçek güvenlik sağlamaz.

Encryption key'ler mümkün olduğunca:

- HSM,
- KMS,
- Vault,
- Secrets Manager

gibi güvenli sistemlerde tutulmalıdır.

### \26. CI/CD Sistemleri Secret Açısından Neden Kritiktir?

CI/CD pipeline'ları birçok farklı production sistemine erişebilir.

Örneğin:

- container registry,
- cloud platformu,
- deployment server,
- package repository,
- code signing service.

Bu nedenle CI/CD sistemlerinde çok sayıda secret bulunabilir.

Eğer pipeline logları veya config dosyaları doğru yönetilmezse bu credential'lar açığa çıkabilir.

CI/CD sistemi saldırgan için yüksek değerli bir hedeftir.

### \27. Pipeline Loglarında Secret Sızıntısı

En yaygın DevSecOps problemlerinden biri secret'ın pipeline loguna yazılmasıdır.

Örneğin debug amacıyla environment variable ekrana basılabilir.

echo $API_KEY

komutu çalıştırılır.

Bu durumda secret build loglarında kalabilir.

Loglara erişimi olan herkes credential'ı görebilir.

Bu nedenle CI/CD sistemlerinde **secret masking** mekanizması kullanılmalıdır.

Hassas değerler log çıktısında maskelenmelidir.

### \28. Build Artifact İçerisinde Secret Olabilir mi?

Evet.

Bazen secret kaynak kod repository'sinde bulunmaz ancak build artifact içerisine yanlışlıkla eklenir.

Örneğin frontend uygulamasının build sürecinde environment configuration JavaScript bundle içerisine eklenebilir.

Sonuç olarak kullanıcı tarayıcı üzerinden secret'ı görebilir.

Özellikle frontend uygulamalarında şu prensip önemlidir:

**Kullanıcının tarayıcısına gönderilen hiçbir bilgi gerçek anlamda secret kabul edilemez.**

Frontend içerisinde bulunan API key'lerin yetkileri buna göre tasarlanmalıdır.

### \29. Frontend Kodunda Secret Saklanabilir mi?

Hayır.

JavaScript, mobil uygulama veya desktop client içerisine gömülen secret sonuçta kullanıcıya dağıtılmış olur.

Kod obfuscation uygulanabilir.

Binary paketlenebilir.

Ancak yeterince kararlı saldırgan credential'ı çıkarabilir.

Bu nedenle frontend tarafında kritik secret bulunmamalıdır.

Secret gerektiren işlemler backend üzerinden gerçekleştirilmelidir.

### \30. Mobil Uygulama İçerisindeki API Key'ler

Mobil uygulamalar da benzer risk taşır.

APK veya IPA dosyaları analiz edilebilir.

String'ler çıkarılabilir.

Configuration dosyaları incelenebilir.

Dolayısıyla mobil uygulama içerisine gömülen API credential'ları saldırgan tarafından bulunabilir.

Mobil uygulamanın backend API'si yalnızca “secret key uygulama içinde gizli” varsayımına güvenmemelidir.

Authentication ve authorization server-side uygulanmalıdır.

### \31. Docker Image İçerisinde Secret Sızıntısı

Container teknolojilerinde başka bir kritik risk ortaya çıkar.

Dockerfile içerisinde secret kullanılabilir.

Örneğin build sırasında private package repository'ye erişmek için credential eklenebilir.

Daha sonra dosya silinse bile önceki image layer içerisinde secret kalabilir.

Bu nedenle container build süreçlerinde secret güvenliği dikkatli tasarlanmalıdır.

BuildKit secret mount veya benzeri güvenli yöntemler kullanılabilir.

### \32. Container Image Katmanları Neden Önemlidir?

Container image'lar katmanlardan oluşur.

Bir layer'da dosya eklenir.

Sonraki layer'da silinebilir.

Ancak önceki layer içerisinde dosya bulunmaya devam edebilir.

Dolayısıyla şu yaklaşım güvenli olmayabilir:

- Secret dosyasını image'a kopyala.
- Build işlemini gerçekleştir.
- Secret dosyasını sil.

Dosya son görüntüde görünmese bile image history içerisinden çıkarılabilir.

Bu nedenle secret mümkün olduğunca image layer'a hiç yazılmamalıdır.

### \33. Kubernetes Secret Güvenli midir?

Kubernetes Secret mekanizması hassas bilgileri configuration'dan ayırmak açısından faydalıdır.

Ancak Kubernetes Secret değerlerinin yalnızca Base64 ile encode edilmesi şifreleme değildir.

Cluster'ın güvenlik yapılandırması önemlidir.

Örneğin:

- etcd encryption,
- RBAC,
- namespace isolation,
- audit logging,
- external secrets management

gibi kontroller uygulanmalıdır.

Kubernetes Secret tek başına bütün secret security problemini çözmez.

### \34. Infrastructure as Code ve Secret Riski

Modern DevOps süreçlerinde altyapı da kod olarak yönetilmektedir.

Terraform, Ansible ve benzeri sistemlerin configuration dosyalarında credential bulunabilir.

Bu nedenle Secret Scanning yalnızca uygulama kaynak kodunu değil:

#### Infrastructure as Code

repository'lerini de kapsamalıdır.

Örneğin:

- cloud access key,
- database password,
- certificate private key

IaC repository'sinde yanlışlıkla tutulabilir.

### \35. API Key ile Password Aynı Şey midir?

İkisi farklı mekanizmalar olabilir ancak güvenlik açısından ikisi de secret olarak değerlendirilmelidir.

API key çoğunlukla uygulamanın başka bir servise erişmesini sağlar.

Password ise kullanıcı veya servis kimlik doğrulamasında kullanılabilir.

Ancak temel prensip aynıdır:

**Yetkisiz kişi görmemelidir.**

API key bazen geliştiriciler tarafından daha az kritik görülür.

Bu hatalıdır.

Bazı API key'ler yüksek yetkiye sahip olabilir.

### \36. Secret'ın Yetkisi Neden Önemlidir?

Bütün secret'lar aynı risk seviyesinde değildir.

Örneğin yalnızca read-only test API'sine erişim sağlayan key ile production cloud administrator key aynı riskte değildir.

Bu nedenle secret exposure tespit edildiğinde risk değerlendirmesinde şu sorular sorulmalıdır:

- Secret hangi sisteme ait?
- Production mı?
- Hangi yetkilere sahip?
- Internet üzerinden kullanılabilir mi?
- Ne kadar süredir geçerli?
- Rotation yapılmış mı?
- Kullanım logları mevcut mu?

Bu sorular gerçek iş riskini belirler.

### \37. Secret Inventory Nedir?

Büyük organizasyonlarda binlerce credential olabilir.

Hangi secret'ın nerede kullanıldığının bilinmemesi ciddi risk oluşturur.

Bu nedenle secret inventory oluşturulması faydalıdır.

Örneğin her secret için şu bilgiler tutulabilir:

- Owner
- Kullanıldığı uygulama
- Environment
- Yetki seviyesi
- Oluşturulma tarihi
- Son rotation tarihi
- Expiration
- Secret type

Bu envanter credential yaşam döngüsünün yönetilmesini kolaylaştırır.

### \38. Secret Lifecycle Management

Secret güvenliği yalnızca saklamaktan ibaret değildir.

Bir secret'ın bütün yaşam döngüsü yönetilmelidir.

Bu süreç:

**Create → Store → Distribute → Use → Rotate → Revoke → Audit**

şeklinde düşünülebilir.

Her aşamada farklı güvenlik kontrolleri gerekir.

Örneğin secret güvenli oluşturulmuş olabilir ancak Slack üzerinden paylaşılıyorsa güvenlik modeli bozulur.

### \39. Secret'lar E-posta veya Mesajlaşma ile Paylaşılmalı mı?

Mümkün olduğunca hayır.

E-posta ve kurumsal mesajlaşma sistemleri secret management platformu değildir.

Mesaj geçmişleri uzun süre saklanabilir.

Search özelliği ile credential bulunabilir.

Forward edilebilir.

Ekran görüntüsü alınabilir.

Bu nedenle credential paylaşımı kontrollü secret sharing mekanizmaları üzerinden yapılmalıdır.

### \40. Secret Exposure Incident Response

Bir credential sızıntısı normal kod hatası gibi değerlendirilmemelidir.

Özellikle production secret ise olay müdahale süreci gerekebilir.

Temel yaklaşım:

**Revoke → Rotate → Investigate → Monitor**

olmalıdır.

Önce eski credential devre dışı bırakılır.

Yeni credential oluşturulur.

Loglar incelenir.

Şüpheli erişimler araştırılır.

Gerekirse ilgili sistemlerde ek güvenlik kontrolleri uygulanır.

### \41. Git History Temizlemek Yeterli midir?

Hayır.

Git history temizliği yalnızca repository içerisindeki izi azaltır.

Secret daha önce:

- clone edilmiş,
- fork edilmiş,
- CI/CD cache'e alınmış,
- backup'a girmiş,
- başka biri tarafından kopyalanmış

olabilir.

Bu nedenle history temizliği rotation'ın yerine geçmez.

Doğru sıra:

**Credential'ı iptal et → Yenile → Sonra repository'yi temizle.**

### \42. Public Repository Secret Sızıntısı

Public repository'ye credential gönderilmesi özellikle kritiktir.

İnternet üzerinde otomatik botlar GitHub ve benzeri platformları sürekli tarayabilir.

Yeni commit edilen cloud key veya token dakikalar hatta saniyeler içerisinde tespit edilebilir.

Dolayısıyla:

**“Kimse repository'yi fark etmez.”**

varsayımı son derece risklidir.

Public secret exposure tespit edildiğinde credential derhal compromised kabul edilmelidir.

### \43. Eski Çalışan ve Secret Riski

Credential paylaşımlı kullanılıyorsa eski çalışanların erişiminin tamamen kapatılması zorlaşabilir.

Örneğin bütün ekip aynı database parolasını kullanıyorsa bir kişi kurumdan ayrıldığında parolanın değiştirilmesi gerekir.

Bu nedenle mümkün olduğunca kişisel identity kullanılmalıdır.

Paylaşımlı secret sayısı azaltılmalıdır.

Böylece çalışan ayrıldığında yalnızca ilgili kullanıcı hesabı kapatılabilir.

### \44. Third-Party Developer Riski

Dış kaynak yazılım geliştirme ekipleri birçok projede kaynak koda erişebilir.

Eğer kaynak kod içerisinde production credential bulunuyorsa üçüncü taraf ekipler de production sistemlerine dolaylı olarak erişebilir.

Bu durum yetki yönetimini zorlaştırır.

Daha güvenli modelde dış kaynak ekipler:

- kaynak koda ihtiyaçları kadar erişir,
- development credential kullanır,
- production secret'ı görmez.

Bu yaklaşım supply chain riskini azaltır.

### \45. Repository Access Control

Secret güvenliğinin bir diğer parçası repository erişimidir.

Her geliştiricinin bütün repository'lere erişmesi gerekmeyebilir.

Least Privilege yaklaşımı burada da uygulanmalıdır.

Örneğin:

- ekip bazlı repository access,
- branch protection,
- MFA,
- SSO,
- audit log,
- token expiration

gibi kontroller kullanılabilir.

Repository modern yazılım organizasyonunun en kritik varlıklarından biridir.

### \46. Personal Access Token Güvenliği

Git platformlarında Personal Access Token kullanımı yaygındır.

Ancak bu tokenlar geniş yetkiye sahip olabilir.

Örneğin token:

- repository okuma,
- kod değiştirme,
- workflow çalıştırma,
- package erişimi

gibi haklar sağlayabilir.

Token oluştururken minimum scope seçilmelidir.

Mümkünse expiration süresi belirlenmelidir.

Kullanılmayan tokenlar iptal edilmelidir.

### \47. CI/CD Token Ele Geçirilirse Ne Olur?

CI/CD token yüksek yetkiye sahipse saldırgan yazılım tedarik zincirini etkileyebilir.

Örneğin:

- kaynak kod değiştirebilir,
- zararlı build üretebilir,
- production deployment yapabilir,
- package repository'ye zararlı paket gönderebilir.

Bu nedenle CI/CD credential'ları kurumun en kritik secret'ları arasında değerlendirilmelidir.

### \48. Supply Chain Security ile Secret Security İlişkisi

Yazılım tedarik zinciri saldırılarında saldırgan her zaman kod zafiyeti kullanmak zorunda değildir.

Ele geçirilmiş bir developer token veya CI/CD credential da yeterli olabilir.

Bu nedenle Secret Security, Software Supply Chain Security'nin ayrılmaz parçasıdır.

Bir sonraki güvenlik katmanı burada ortaya çıkar:

#### Kim yazılımı değiştirebilir?

#### Kim build üretebilir?

#### Kim release yayınlayabilir?

Bu sorular kaynak kod güvenliği kadar önemlidir.

### \49. Secret Scanning Sonuçları Nasıl Önceliklendirilmelidir?

Secret scanner yüzlerce bulgu üretebilir.

Bazıları test credential olabilir.

Bazıları uzun süredir geçersiz olabilir.

Bazıları ise aktif production key olabilir.

Bu nedenle bulgular şu kriterlere göre önceliklendirilebilir:

#### Active mı?

Credential hâlâ çalışıyor mu?

#### Production mı?

Canlı sisteme erişiyor mu?

#### Privilege Seviyesi

Hangi yetkilere sahip?

#### Public Exposure

Public repository'de mi bulundu?

#### Age

Ne kadar süredir repository içerisinde?

Aktif production administrator credential her zaman en yüksek önceliğe sahip olmalıdır.

### \50. Validity Check Yapılmalı mı?

Bazı secret scanning sistemleri bulunan credential'ın gerçekten aktif olup olmadığını doğrulayabilir.

Bu yaklaşım False Positive sayısını azaltabilir.

Ancak validation mekanizması dikkatli uygulanmalıdır.

Özellikle kritik sistemlerde otomatik doğrulamanın yetkisiz veya zararlı işlem gerçekleştirmemesi gerekir.

Amaç yalnızca credential'ın geçerli olup olmadığını güvenli şekilde anlamaktır.

### \51. False Positive Secret Bulguları

Her yüksek entropy string secret değildir.

Örneğin:

- test UUID,
- hash,
- fixture data,
- örnek dokümantasyon

scanner tarafından yanlışlıkla secret olarak algılanabilir.

Bu nedenle Secret Scanning sonuçlarında triage süreci gereklidir.

Ancak bir bulgunun test verisi olduğuna karar verilmeden önce gerçekten aktif credential olmadığı doğrulanmalıdır.

### \52. Secret Scanner'a Güvenip Başka Kontrol Yapmamak Doğru mu?

Hayır.

Secret Scanning güçlü bir güvenlik katmanıdır ancak bütün secret risklerini göremez.

Örneğin credential:

- binary dosyada,
- encrypted archive içerisinde,
- image metadata'da,
- dokümantasyon sisteminde,
- CI/CD variable store'da

bulunabilir.

Bu nedenle daha geniş **Secrets Management Programı** gerekir.

### \53. Secure SDLC İçerisinde Secret Security

Secret güvenliği Secure SDLC'nin birçok aşamasında bulunmalıdır.

Örneğin:

#### Development

Hard-coded secret yasaklanır.

#### Commit

Pre-commit Secret Scanning yapılır.

#### Repository

Push Protection uygulanır.

#### CI/CD

Secret masking ve güvenli variable yönetimi yapılır.

#### Deployment

Secrets Manager üzerinden runtime erişim sağlanır.

#### Production

Rotation ve audit uygulanır.

Bu yapı secret güvenliğini tek bir araçtan çıkararak yaşam döngüsüne yayar.

### \54. Push Protection Nedir?

Push Protection, geliştiricinin secret içeren kodu remote repository'ye göndermesini otomatik olarak engelleyen güvenlik mekanizmasıdır.

Örneğin sistem Git push sırasında API key tespit eder.

Push işlemi durdurulur.

Geliştiriciye hangi dosyada potansiyel secret bulunduğu gösterilir.

Bu yöntem olay olduktan sonra rapor üretmekten daha güçlüdür.

Çünkü problem daha oluşmadan engellenir.

### \55. Developer'a Güvenlik Uyarısı Nasıl Verilmelidir?

Secret Scanning geliştiriciyi gereksiz şekilde zorlamamalıdır.

Uyarı açık ve uygulanabilir olmalıdır.

Örneğin sadece:

**Secret detected.**

demek yerine:

- hangi dosyada bulunduğu,
- hangi secret türü olduğu,
- nasıl kaldırılacağı,
- Secrets Manager kullanım yöntemi

gösterilebilir.

Bu yaklaşım geliştiricinin problemi daha hızlı çözmesini sağlar.

### \56. Koddan Secret Temizlemek Secure Coding'in Bir Parçası mıdır?

Evet.

Secure Coding yalnızca Injection veya XSS önlemek değildir.

Credential yönetimi de güvenli yazılım geliştirmenin temel bileşenidir.

Geliştirici şu prensibi benimsemelidir:

**Kod çalışmak için secret'a ihtiyaç duyabilir; ancak secret kodun parçası olmamalıdır.**

Bu ayrım modern kod güvenliğinin temel prensiplerinden biridir.

### \57. Secret Management İçin Temel Kontrol Listesi

Kurumsal bir secret güvenliği yaklaşımında en az şu kontroller değerlendirilmelidir:

- Hard-coded credential kullanılmamalı.
- Production ve development secret ayrılmalı.
- Secret scanning etkin olmalı.
- Pre-commit kontrolü uygulanmalı.
- Repository history taranmalı.
- Merkezi secrets manager kullanılmalı.
- Rotation politikası bulunmalı.
- Least Privilege uygulanmalı.
- CI/CD loglarında secret masking olmalı.
- Secret erişimleri audit edilmelidir.

Bu kontroller birlikte kullanıldığında risk önemli ölçüde azaltılabilir.

### \58. Secret Güvenliği Nasıl Ölçülür?

Application Security programında secret güvenliği de ölçülebilir.

Örneğin:

- repository başına secret bulgu sayısı,
- active secret sayısı,
- production secret exposure sayısı,
- ortalama rotation süresi,
- push protection engelleme sayısı,
- secrets manager kullanım oranı

gibi metrikler takip edilebilir.

Amaç geliştiricileri cezalandırmak değildir.

Amaç tekrar eden problemleri görerek süreçleri iyileştirmektir.

### \59. “Zero Secret in Code” Hedefi

Kurumsal kod güvenliği programlarında güçlü hedeflerden biri:

#### Zero Secret in Code

yaklaşımı olabilir.

Bu ifade pratikte hiçbir credential'ın kaynak kod içerisinde tutulmaması hedefini temsil eder.

Tam anlamıyla sıfıra ulaşmak zor olabilir.

Ancak hedef önemlidir.

Secret bulunduğunda sistem otomatik olarak engellemeli veya hızlı şekilde müdahale edilmesini sağlamalıdır.

### \60. Secret Güvenliğinde İnsan Faktörü

Teknoloji ne kadar gelişirse gelişsin insan faktörü önemini korur.

Geliştirici secret'ı yanlışlıkla:

- kaynak koda,
- ticket'a,
- e-postaya,
- chat kanalına,
- dokümana

yazabilir.

Bu nedenle geliştirici farkındalığı önemlidir.

Secure Coding eğitimlerinde secret management mutlaka ayrı konu olarak ele alınmalıdır.

### SecureSys Secret Scanning ve Kod Güvenliği Yaklaşımı

SecureSys olarak kaynak kod güvenliğini yalnızca klasik SAST zafiyetleri üzerinden değerlendirmiyoruz.

Modern yazılım ekosisteminde credential ve secret güvenliği de Application Security'nin temel parçalarından biridir.

Bu nedenle proje kapsamına göre;

#### SAST, Secret Scanning, Repository Security, SCA, manuel kaynak kod analizi ve DevSecOps güvenlik kontrolleri

birlikte değerlendirilebilir.

Özellikle;

- production API key'leri,
- database credential'ları,
- cloud access key'leri,
- private key'ler,
- signing key'ler,
- service account bilgileri

gibi kritik secret'ların kaynak kod ve repository geçmişi içerisinde bulunup bulunmadığı analiz edilebilir.

Ancak amaç yalnızca secret'ı tespit etmek değildir.

Tespit edilen credential'ın;

**aktif olup olmadığı, hangi sisteme eriştiği, hangi yetkiye sahip olduğu ve rotation gerektirip gerektirmediği**

değerlendirilmelidir.

Çünkü kaynak kod içerisinde görülen tek bir API key bazen basit bir kod hatası değildir.

**Doğrudan bir güvenlik ihlali başlangıcı olabilir.**

Bu nedenle güçlü secret yönetimi:

**Detect → Revoke → Rotate → Investigate → Prevent**

yaklaşımıyla ele alınmalıdır.

### Sık Sorulan Sorular

#### Secret Scanning nedir?

Secret Scanning, kaynak kod ve repository içerisinde parola, API key, token, private key ve benzeri hassas bilgileri otomatik olarak tespit etmeye çalışan güvenlik yöntemidir.

#### API key kaynak kodda tutulabilir mi?

Özellikle kritik ve gizli API key'ler kaynak kod içerisinde tutulmamalıdır. Merkezi secret yönetimi veya runtime identity mekanizmaları tercih edilmelidir.

#### Secret koddan silinirse problem çözülür mü?

Her zaman değil. Secret daha önce Git repository'ye gönderildiyse eski commit geçmişinde bulunabilir. Credential'ın değiştirilmesi veya iptal edilmesi gerekir.

#### Credential Rotation nedir?

Mevcut parola, API key veya token'ın iptal edilerek yeni bir credential oluşturulması işlemidir.

#### .gitignore secret güvenliği için yeterli midir?

Hayır. Faydalı bir kontroldür ancak daha önce commit edilmiş dosyaları temizlemez ve insan hatasını tamamen engellemez. Secret Scanning ile desteklenmelidir.

#### Environment Variable güvenli midir?

Hard-coded credential kullanımından daha güvenlidir ancak kritik sistemlerde merkezi Secrets Manager veya Vault çözümleri daha güçlü kontrol sağlayabilir.

#### Git geçmişindeki secret nasıl ele alınmalıdır?

Credential compromised kabul edilmeli, önce revoke veya rotate edilmeli, ardından gerekirse Git geçmişi temizlenmelidir.

#### Secret Scanning ile SAST aynı şey midir?

Hayır. SAST kod güvenlik zayıflıklarını analiz ederken Secret Scanning credential ve hassas erişim bilgilerini tespit etmeye odaklanır.

#### Frontend içerisinde API secret saklanabilir mi?

Gerçek anlamda gizli kalması gereken secret'lar frontend veya mobil uygulama içerisinde tutulmamalıdır. Kullanıcıya dağıtılan kod analiz edilebilir.

#### Secret'lar ne sıklıkla değiştirilmelidir?

Kurumun risk ve erişim modeline göre rotation politikası belirlenmelidir. Bir secret sızdığı düşünüldüğünde periyodik süre beklenmeden derhal değiştirilmelidir.

### Sonuç: Kaynak Kod İçindeki En Tehlikeli Satır Bazen Bir Güvenlik Açığı Değil, Bir Anahtardır

Kaynak kod güvenliği konuşulduğunda ilk akla gelen konular çoğunlukla SQL Injection, XSS veya Command Injection gibi klasik güvenlik açıklarıdır.

Ancak modern yazılım ekosisteminde tek bir satır bazen bunlardan çok daha büyük etkiye sahip olabilir.

Örneğin:

AWS_SECRET_ACCESS_KEY = "..."

veya:

PROD_DATABASE_PASSWORD = "..."

gibi bir değer doğrudan kritik sistemlerin kapısını açabilir.

Saldırganın sofistike exploit geliştirmesine gerek kalmayabilir.

Kod zafiyetini araştırması gerekmeyebilir.

Sadece geçerli credential'ı kullanması yeterli olabilir.

Bu nedenle kod güvenliği yalnızca:

**“Kod saldırıya açık mı?”**

sorusundan ibaret değildir.

Aynı zamanda:

**“Kod içerisinde saldırgana doğrudan erişim sağlayabilecek bir anahtar bırakılmış mı?”**

sorusunu da kapsar.

Modern Application Security programında Secret Scanning bu nedenle lüks bir güvenlik özelliği değildir.

SAST ve SCA ile birlikte temel kod güvenliği katmanlarından biridir.

Ancak en güçlü yaklaşım secret'ı bulmak değildir.

**Secret'ın daha repository'ye girmeden engellenmesidir.**

Ve ideal noktada uygulamalar uzun ömürlü statik credential'lara mümkün olduğunca az ihtiyaç duymalıdır.

Çünkü saklamak zorunda olmadığınız bir secret;

**sızdırabileceğiniz bir secret değildir.**