Güvenli Yazılım Geliştirme Yaşam Döngüsü (Secure SDLC) Rehberi [2026]

Güvenlik Tekniklerle Kapatılmaz, Tasarlanmaz

Yazılım geliştirmenin tarihinde en yaygın hata şu olmuştur: önce işlevsellik geliştir, sonra güvenlik ekle. Bu yaklaşım, bir evin duvarlarını yapıp daha sonra kilitler takması gibidir. Ancak yazılımda durum daha vahimdir - kilit sonradan takılsa bile, ev yapısının temelleri zayıf kalır.

Secure SDLC (Güvenli Yazılım Geliştirme Yaşam Döngüsü), güvenliği geliştirme döngüsünün her aşamasına entegre eden bir yaklaşımdır. Bu rehber, yöneticilerin neden Secure SDLC önemli olduğunu ve nasıl uygulanacağını anlamalarına yardımcı olmak için yazılmıştır.

Neden Secure SDLC Önemli?

Maliyet Açısından

Açıklar, ne zaman bulunursa bulunup kapatılırsa bulunursun, bir maliyeti vardır. Ancak bu maliyet, zamanlamaya göre katlanmış biçimde artar:

Aşama	Zafiyet Bulunma Maliyeti	Düzeltme Maliyeti
Gereksinimler	5 dolar	10 dolar
Tasarım	10 dolar	50 dolar
Geliştirme	20 dolar	200 dolar
Test	50 dolar	500 dolar
Üretim	500 dolar	5.000 dolar

Geliştirme aşamasında tespit edilen bir güvenlik açığı, üretimde 25 kat daha pahalı olmaktadır.

Kalite Açısından

Güvenlik, işlevsellik kadar önemlidir. Bir banka uygulaması para transferi yapıyor olabilir (işlevsellik), ama bunu yapabilecek parası olmayan birisi de yapabiliyorsa (güvenlik), bu uygulamayı kabul edebilir misiniz?

Yasal Açısından

KVKK, GDPR, PCI-DSS gibi standartlar, güvenlik gereksinimlerini tasarım aşamasından itibaren ele almayı talep etmektedir. "Tasarıma güvenliği sonradan ekledik" savunması yasal olarak kabul edilmemektedir.

İtibar Açısından

Bir güvenlik ihlalinden sonra yapılan açıklamalar:

• "Bilmiyorduk" → Yeterli şekilde test etmedik
• "Sonradan kapatıldı" → Tasarımda öngörmemiş olduk
• "Önemsiz bulmuştuk" → Risk yönetimi yapamadık

Tüm bu ifadeler, işletmenin itibar hasarına yol açmaktadır.

Secure SDLC'nin Tanımı

Secure SDLC, yazılım geliştirme yaşam döngüsünün her aşamasına güvenlik uygulamalarının entegre edilmesidir. Normal SDLC'den farklı olarak:

Normal SDLC: Gereksinimler tanımlanır, tasarım yapılır, kod yazılır, test edilir, canlıya alınır ve bakımı yapılır.

Secure SDLC: Her aşamaya güvenlik kontrolleri eklenir. Gereksinimlerde güvenlik neler olabilir sorusu sorulur, tasarımda tehdit analiziyle zayıflıklar belirlenir, geliştirmede güvenli kodlama uygulanır, testte güvenlik açıkları için taranır, dağıtımda yapılandırma doğrulanır ve bakımda açık yamalar uygulanır.

Secure SDLC'nin Aşamaları

Aşama 1: Gereksinimler (Requirements)

Güvenlik Gereksinimlerini Tanımlama

Normal gereksinimler işlevselliği tanımlar. Güvenlik gereksinimlerinin ise "Ne kötü şey olabilir?" sorusuna cevap vermesidir.

Örnek:

Normal Gereksinim: "Müşteri para transfer edebilmeli"

Güvenlik Gereksinimleri:

• Sadece kendi hesabından transfer edebilmeli
• Günde en fazla 10.000 lira transfer edebilmeli
• Transfer başarılı olunca onay e-postası gönderilmeli
• Transfer geçmişi 7 yıl saklanmalı
• Transfer işlemleri log'a yazılmalı

Uyumluluk Gereksinimlerini Kontrol Etme

Hangi standartlar uygulanmaya başlayacak?

• KVKK: Kişisel veri işleme (evet ise, veri minimizasyonu, amaç sınırlaması)
• GDPR: Avrupa'da müşteri varsa (evet ise, GDPR'ye uyum)
• PCI-DSS: Kredi kartı işleme (evet ise, şifreleme, log tutma)
• ISO 27001: Sertifikasyon hedefi (evet ise, bilgi sınıflandırması)
• Sektörel: Finans, sağlık vb. (sektör yönetmeliklerini kontrol etme)

Tehdit Kategorileri

• Kimlik doğrulama saldırıları
• Yetkisiz erişim
• Veri sızması
• Hizmet kesintisi
• Veri manipülasyonu

Çıktılar

• Güvenlik gereksinimi belgesi
• Uyumluluk listesi
• Risk değerlendirme matriksi

Aşama 2: Tasarım (Design)

Tehdit Modelleme (Threat Modeling)

Tehdit modelleme, "Sistem nasıl saldırılabilir?" sorusunu sistematik olarak cevaplamanın yoludur.

Yaygın Tehdit Modelleme Yöntemleri:

STRIDE:

• Spoofing (kimlik sahteciliği)
• Tampering (veri değiştirilmesi)
• Repudiation (inkar)
• Information Disclosure (bilgi ifşası)
• Denial of Service (hizmet kesintisi)
• Elevation of Privilege (yetki yükselme)

Her bileşen için, bu 6 kategori sorunlanır. Örneğin:

API Uç Noktası (Authentication):

• Spoofing: Kimlik doğrulama atlayabilir misin? (Evet, eğer token doğrulanmıyorsa)
• Tampering: Token değiştirebilir misin? (Evet, eğer imzalı değilse)
• Repudiation: İşlemi inkar edebilir misin? (Evet, eğer log tutulmuyorsa)
• Information Disclosure: Hassas veri görüntüleyebilir misin? (Evet, eğer şifreli değilse)
• Denial of Service: Hizmeti kesintiye uğratabilir misin? (Evet, rate limit yoksa)
• Elevation of Privilege: İdari işlem yapabilir misin? (Evet, erişim kontrol yoksa)

PASTA (Process for Attack Simulation and Threat Analysis):

Daha kapsamlı, 7 aşamalı bir metodoloji.

Attack Trees:

Grafiksel olarak "Saldırgan hedefine nasıl ulaşabilir?" gösterir.

Mimarideki Zayıflıkları Belirleme

• Servisler arası iletişim (service-to-service) güvenliği
• Veri depolama (at rest) güvenliği
• Veri iletimi (in transit) güvenliği
• Kimlik doğrulama ve yetkilendirme mimarisi
• Loglama ve izleme mimarisi
• Kurtarma (disaster recovery) mimarisi

Tasarım Kalıpları (Security Patterns)

Bilinen güvenlik sorunlarına karşı, kanıtlanmış tasarım kalıpları vardır:

• Defense in Depth: Birden çok güvenlik katmanı
• Zero Trust: Hiçkimseye iç ağda olmasa da güven duyma
• Least Privilege: Sadece gerekli izinleri ver
• Separation of Duties: Sorumlulukları böl
• Secure by Default: Açıktan ziyade kapıdan başla

Çıktılar

• Tehdit modeli raporu
• Mimaridiyagram (güvenlik kontrolleri ile)
• Tasarım gözden geçirme checklisti
• Güvenlik mimarı tarafından onay

Aşama 3: Geliştirme (Implementation)

Güvenli Kodlama Standartları

Her programlama dilinin güvenli kodlama standartları vardır. Örneğin:

Genel Kurallar: Kullanıcı girdisine hiç güven duyulmamalı, her giriş doğrulanmalı ve temizlenmelidir. Parolalar asla düz metinde saklanmamalı, hata mesajları hassas bilgi içermemelidir ve tüm önemli işlemler kayıt altına alınmalıdır.

Dile Özgü Uygulamalar: Java'da veritabanı sorgularında parametre bağlamaya dayalı kütüphaneler kullanarak injeksiyon saldırılarına karşı korunur. Python'da sistem komutlarında yönetimli kütüphaneler ve subprocess modülü tercih edilir. JavaScript'te kötü amaçlı kod çalıştırabilen eval() ve similar fonksiyonlar kesinlikle kullanılmamalıdır. PHP'de HTML çıktısı htmlspecialchars() fonksiyonu ile escaped edilmelidir. Tüm dillerde, giriş doğrulama (input validation) ve çıktı kodlama (output encoding) temel prensipleridir.

SAST (Statik Uygulama Güvenlik Testi) Araçları

Kodlar yazılırken, otomatik olarak zafiyetleri bulan araçlar:

• SonarQube
• Checkmarx
• Fortify Static Code Analyzer
• Veracode

Bu araçlar, kod yazıldığı anda geliştiriciyi uyarır: "Bu satırda SQL injection riski var."

Şifreleme ve Parola Yönetimi

• Parola hash'i: bcrypt, Argon2 (MD5 ve SHA1 değil)
• Veri şifreleme: AES-256
• TLS/SSL: HTTPS kullan, HTTP değil
• Sertifika yönetimi: Self-signed değil, CA imzalı

Bağımlılık Yönetimi

Harici kütüphaneler, bir yazılımın çoğunluğunu oluşturur. Bu kütüphanelerin güvenli olması kritiktir.

• Bağımlılık envanteri tutma
• Bilinen zafiyetleri tarama (npm audit, OWASP Dependency Check)
• EOL (End of Life) kütüphanelerini güncelleme
• Ek kütüphaneler eklenmeden önce güvenlik taraması

Çıktılar

• Güvenli kodlanmış yazılım
• SAST raporu (0 kritik zafiyet hedefi)
• Bağımlılık envanteri ve zafiyet raporu
• Kod inceleme (peer review) kayıtları

Aşama 4: Test (Testing)

DAST (Dinamik Uygulama Güvenlik Testi)

Çalışan uygulamayı saldırganın perspektifinden test etme:

• Burp Suite
• OWASP ZAP
• Fortify WebInspect

Bu araçlar, HTTP istekleri gönderip, açı bulunmuş olan yanıtları inceleyerek zafiyet bulur.

Manuel Penetrasyon Testi

Otomatik araçlar her şeyi bulamaz. İnsan keşfi gerekebilir.

Bkz. Penetrasyon Testi (Pentest) Hizmeti

İşlevsel Güvenlik Testleri

İşlevselliği test ederken, güvenliği de kontrol etme:

• Yetkisiz erişim testi: Admin olmadan admin işlemi yapılabilir mi?
• Veri doğrulaması: 0 yaşında kullanıcı kaydı açılabilir mi?
• Oturum kapatma: Logout sonrası, cookie ile erişim mümkün müdür?
• Şifre sıfırlama: Başka kullanıcının parolasını sıfırlayabilir misin?

API Güvenlik Testleri

Bkz. API Güvenliği: OAuth 2.0, JWT ve Zero Trust Yaklaşımı

Regresyon Testi

Önceki hataların tekrar meydana gelmediğini kontrol etme. Güvenlik testleri de regresyon sırasında yapılmalı.

Çıktılar

• DAST raporu (zafiyetler)
• Penetrasyon test raporu
• Test etkinliği raporları
• Açıklar kapatılmadan canlıya almama (kritik zafiyet varsa)

Aşama 5: Dağıtım (Deployment)

Yapılandırma Güvenliği

Yazılım kodlanmış olsa da, sunucu yanlış yapılandırılırsa, güvenlik bozulabilir:

• Varsayılan parolaları değiştirme
• Hata ayıklama modunu kapatma
• Gerekli olmayan servisleri durdurmak
• CORS yapılandırması
• Security Headers (HSTS, CSP, X-Frame-Options)
• WAF (Web Application Firewall) kuralları

Sızır Kontrol (Secrets Management)

Veritabanı parolaları, API anahtarları gibi sızırlar (secrets) hiçbir zaman kaynak kodda bulunmamalı. Bunlar, güvenli bir vault'ta saklanmalı:

• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault

Dağıtım Güvenliği

• Dağıtım öncesi kontrol listesi (deployment checklist)
• Bilinen zafiyetler için CVSS puanı kontrol
• Bir önceki versiyona dönüş planı (rollback)
• Dağıtım sonrası log kontrol

Çıktılar

• Yapılandırma kontrol listesi (tüm öğeler Evet)
• Dağıtım sonrası güvenlik doğrulaması raporu
• Monitoring ve alerting sistemi kurulu

Aşama 6: Bakım (Maintenance)

Patch Yönetimi

Yazılım yayımlandıktan sonra, yeni güvenlik açıkları keşfediliyor. Bunlara patch (yamalar) yayımlanması gerekiyor.

• Zafiyet haberleri takip etme (NVD, CVE)
• Patch uygulanmasının planlandırılması
• Patch'i test ortamında test etme
• Canlı ortamda uygulama
• Patch sonrası doğrulama

Türkiye'de BDDK, finansal kurumların kritik yamalar için 24-48 saat içinde uygulanması talep etmektedir.

Günlüğe Kaydedilme ve İzleme

Üretimde, güvenlik olaylarını fark etmek için izleme gereklidir:

• Login denemeleri (başarısız denemeler)
• Veri erişim patternleri (anormal erişim)
• Ağ trafiği (anormal bağlantılar)
• Sistem değişiklikleri (yetkisiz dosya değişimi)

Kimlik Doğrulama ve Yetkilendirme Yönetimi

Zaman içinde, personel başka departmana geçebilir, terken alabilir. Erişim haklarının deaktif edilmesi gerekiyor:

• Müşteri müşteri giderse hesabını kapat
• Çalışan terken alırsa erişimini kısıtla
• Rol değişirse yetkileri güncelle

Siber Olaylar ve Yanıt (Incident Response)

Eğer bir saldırı meydana gelirse, hızlı ve düzenli bir şekilde yanıt verilmesi gerekiyor:

• Olayı tespit etme
• Yayılmasını durdurma (containment)
• Kaynağını analiz etme (root cause)
• Hasarı tamir etme
• Tekrar meydana gelmesini önleme
• Müşterilere bildirim

Çıktılar

• Patch yönetim raporu
• Monitoring logları
• Siber olay yanıt raporları

Secure SDLC Metodolojileri

Microsoft Security Development Lifecycle (SDL)

Microsoft'un önerdiği ve kendisi de kullandığı metodoloji:

1. Eğitim Sağlayın
2. Güvenlik Gereksinimlerini Tanımlayın
3. Güvenlik ve Gizlilik Risk Modellerini Oluşturun
4. Tasarım Gereksinimlerini Belirleyin
5. Güvenlik En İyi Uygulamalarını Tanımlayın ve Uygulayın
6. Uygun Araçları Uygulayın
7. Güvenlik Testleri Yapın
8. Standart Bir Olay Yanıt Prosesi Kurun

OWASP Secure Coding Practices

OWASP'nin tanımladığı, programlama dili agnostik, 12 ana prensip:

1. Girdi Doğrulama
2. Çıktı Kodlama
3. Kimlik Doğrulama ve Şifre Yönetimi
4. Erişim Kontrol
5. Kriptografi
6. Hata Yönetimi ve Loglama
7. İletişim Güvenliği
8. Sistem Yapılandırması
9. Veritabanı Güvenliği
10. Dosya Yönetimi
11. Hafıza Yönetimi
12. Genel Kodlama Uygulamaları

BSA (Building Security In)

Bir başka kapsamlı rehber.

Secure SDLC Uygulamak: İlk Adımlar

1. Değerlendirme

Mevcut SDLC neresindesin? Hangilerine zaten uyuyorsun, hangilerine uymuyor?

Bir maturity model kullan:

• Level 1: Başlangıç (hoca güvenliği yok)
• Level 2: Temel (bazı yerlerde kontrol var)
• Level 3: Orta (çoğu aşamada var)
• Level 4: İleri (tüm aşamalarda sistematik)
• Level 5: Optimized (devamlı iyileştirme)

2. Pilot Proje

Yeni bir yazılım projesi başlıyorsa, Secure SDLC uygulamayı o projede pilot yapabilirsin.

3. Araç Seçimi

• SAST (Checkmarx, SonarQube)
• DAST (Burp Suite, OWASP ZAP)
• Bağımlılık Taraması (npm audit, Snyk)
• SBOM (Software Bill of Materials) oluşturma

4. Eğitim

Geliştirici ekibini eğit:

• Güvenli kodlama
• OWASP Top 10
• Tehdit modelleme
• Test teknikleri

5. Ölçüm ve İzleme

KPI'ları tanımla:

• Kaç tane güvenlik gereksinimi var?
• Kaç tanesine uyuldu?
• Ortalama zafiyet bulunma süresi nedir?
• Patch uygulanma süresi nedir?

Secure SDLC'nin İşletme Etkisi

Riski Azaltma

• İhlal olasılığı: yüzde 40-60 azalma
• Keşif süresi: 200+ günden 30 güne

Maliyeti Azaltma

• Geliştirme aşamasında tespit: Çok düşük maliyet
• Üretim sonrası tespit: Çok yüksek maliyet

Uyumluluk

• KVKK, GDPR, PCI-DSS uyumluluğu sağlanır
• Denetim geçilmesi kolaylaşır

İtibar

• "Güvenliği tasarımdan itibaren alıyoruz" mesajı
• Müşteri güvenini arttırır

Sonraki Adımlar

Yazılım geliştirme yaşam döngüsünüze güvenlik entegre etmek, uzun bir yolculuk. Ama bu yolculuğun başında başlama işini erkene almak, daha sonraki zorlukları azaltır.

Siber Güvenlik ve Yazılım Güvenliği Hizmetleri rehberimiz, genel bir çerçeve sunarken, Secure SDLC uygulamaya odaklanmaktadır. Ayrıca DevSecOps: Güvenlik Otomasyonu yazımız, Secure SDLC'nin otomasyon yönünü ele almaktadır.

Smart Maple, yazılım geliştiren şirketlerin Secure SDLC uyumluluğunun başlangıcından sonuna kadar yönetmesine yardımcı olur. Eğer SDLC'nizde güvenlik entegrasyonuyla ilgili sorunlar yaşıyorsanız, smart-maple.com adresinden danışmanlık hizmetlerimiz hakkında daha fazla bilgi alın.