Güvenli Yazılım Yaşam Döngüsü (Secure SDLC)

1. Giriş

Güvenlik, geleneksel yazılım süreçlerinde çoğu zaman en sona bırakılmıştır: kod yazılır, test edilir, sonra — yayına çıkmadan hemen önce — bir sızma testi yapılır ve çıkan açıklar aceleyle yamanır. Bu modele endüstride "duvara sıçratmak" (throwing over the wall) denir ve iki nedenle başarısızdır: geç bulunan açıkların düzeltme maliyeti yüksektir ve zaman baskısı altında çoğu bulgu "sonra bakarız" diye ertelenir.

Güvenli Yazılım Yaşam Döngüsü (Secure SDLC), bu modeli tersine çevirir. Güvenliği yaşam döngüsünün başından sonuna dağıtır: gereksinim toplarken, tasarlarken, kodlarken, test ederken ve yayınladıktan sonra. Temel ilke, ünlü bir güvenlik mühendisliği aksiyomudur: "Shift left" — güvenlik faaliyetlerini zaman çizelgesinde sola, yani başa doğru kaydırmak.

Bu bölüm bir framework dayatmaz; bunun yerine yaygın olgunluk modellerinin (Microsoft SDL, OWASP SAMM, NIST SSDF) ortak çekirdeğini, PHP ekiplerine uygulanabilir biçimde sunar.

2. Yaşam Döngüsünün Evreleri ve Güvenlik Faaliyetleri

 Gereksinim  →  Tasarım  →  Geliştirme  →  Test  →  Yayın  →  Operasyon
     │            │            │           │        │           │
 Güvenlik     Tehdit       Güvenli      SAST/    Yapılan-   Loglama,
 gereksinim   modelleme    kodlama,     DAST,    dırma      izleme,
 leri,        (Böl. 2),    kod          sızma    sertleş-   yama,
 kötü niyet   güvenli      inceleme     testi    tirme,     incident
 senaryoları  mimari                             gizli      response
                                                 tarama

Her evrenin kendi güvenlik faaliyeti vardır. Hiçbiri diğerinin yerini tutmaz; katmanlı savunma gibi, birbirini tamamlarlar.

3. Evre 1 — Gereksinim: Güvenliği Baştan Tanımlamak

Güvenlik, bir gereksinim olarak yazılmadıkça "önceliklendirme" toplantısında daima kaybeder. Bu yüzden ilk adım, güvenlik gereksinimlerini fonksiyonel gereksinimlerle aynı belgeye koymaktır.

İki pratik teknik:

Kötüye kullanım senaryoları (abuse cases): Normal kullanım senaryolarının (use cases) yanına, bir saldırganın bakış açısından "kötüye kullanım" senaryoları yazın. "Kullanıcı parolasını sıfırlar" senaryosunun yanına "Saldırgan başkasının parola sıfırlama token'ını tahmin etmeye çalışır" senaryosu eklenir. Bu, gereksinim aşamasında savunma ihtiyacını görünür kılar.

Uyum ve standart hedefleri: Sistem KVKK, GDPR, PCI-DSS gibi bir düzenlemeye tabiyse, bunun gereksinimleri baştan tanımlanır. OWASP ASVS (Application Security Verification Standard), doğrulanabilir güvenlik gereksinimlerinin hazır bir kataloğunu sunar ve bir "güvenlik gereksinim listesi" başlangıç noktası olarak idealdir.

4. Evre 2 — Tasarım: Güvenli Mimari ve Tehdit Modelleme

Bu evrenin ana faaliyeti Bölüm 2'de işlenen tehdit modellemedir. Ek olarak, tasarımda uygulanan güvenli tasarım ilkeleri (Saltzer & Schroeder'in klasik ilkelerinden türeyen):

• En az yetki (least privilege): Her bileşen asgari hakla çalışır.
• Güvenli varsayılan (fail secure): Bir kontrol başarısız olduğunda sistem güvenli tarafta kalır (erişimi reddeder).
• Yetki ayrımı (separation of duties): Kritik bir işlem tek bir bileşenin/kişinin kontrolünde olmaz.
• Basitlik (economy of mechanism): Karmaşık güvenlik mekanizmaları daha çok hata barındırır; sade tasarım denetlenebilirdir.
• Tam aracılık (complete mediation): Her erişim, her seferinde denetlenir (önbelleğe alınmış yetki kararlarına dikkat).

Bu ilkeler soyut değildir; her biri Bölüm 1'deki güvensiz kalıpların panzehiridir.

5. Evre 3 — Geliştirme: Güvenli Kodlama ve Kod İnceleme

Güvenli kodlama standardı. Ekip, dile özgü yazılı bir standarda sahip olmalıdır: "SQL daima parametreli", "çıktı bağlama göre kodlanır", "declare(strict_types=1) zorunlu", "gizli anahtarlar koda gömülmez" gibi. Bu standart, kitabın açık bölümlerinin damıtılmış kurallarıdır.

Kod inceleme (code review). Güvenlik odaklı inceleme, her PR'ın parçası olmalıdır. İnceleyen kişi, kitabın checklist'lerini bir rehber olarak kullanır. Özellikle "tehlikeli fonksiyon" (Bölüm 1) ve "güven sınırını geçen doğrulanmamış veri" kalıpları aranır. İnsan incelemesi, otomatik araçların kaçırdığı mantık açıklarını (business logic, IDOR) yakalamada vazgeçilmezdir.

Bağımlılık hijyeni. Composer ile çekilen her paket, kod tabanınızın bir parçasıdır ve saldırı yüzeyinizi genişletir. Bu evrede bağımlılıkların düzenli güncellenmesi ve bilinen açıklara karşı taranması başlar (Bölüm 30).

6. Evre 4 — Test: SAST, DAST ve Sızma Testi

Test evresi üç tamamlayıcı yaklaşım kullanır:

Kritik nokta: bu yöntemler rakip değil, tamamlayıcıdır. SAST tasarım/kodlama sırasında sürekli çalışır; DAST staging ortamında; sızma testi büyük sürümler öncesi periyodik olarak. Hiçbiri tek başına yeterli değildir.

7. Evre 5 — Yayın: Sertleştirme ve Gizli Tarama

Yayın öncesi son kontroller:

• Yapılandırma sertleştirme: display_errors=Off, güvenli php.ini, sunucu başlıkları, TLS yapılandırması (Bölüm 26–27).
• Gizli anahtar taraması (secret scanning): Kod tabanında yanlışlıkla commit edilmiş API anahtarı, parola veya token olmadığından emin olun. .env dosyaları depoya girmemelidir (Bölüm 25).
• Yayın onayı (release gate): Kritik güvenlik bulguları çözülmeden yayın yapılmamasını sağlayan bir kapı. Bu kapı, CI/CD'ye gömülü olduğunda insan iradesine bağımlı olmaktan çıkar.

8. Evre 6 — Operasyon: İzleme ve Yanıt

Yayın, güvenliğin sonu değil, sürekli evresinin başıdır:

• Loglama ve izleme (Bölüm 31): Anomali ve saldırı işaretlerinin görünürlüğü.
• Yama yönetimi: Yeni CVE'ler yayımlandıkça bağımlılıkların ve altyapının güncellenmesi. Drupageddon (Bölüm 6) örneği, yama hızının bir güvenlik kontrolü olduğunu gösterdi.
• Incident response (Bölüm 32): Bir olay gerçekleştiğinde önceden hazırlanmış, prova edilmiş bir plan.

9. DevSecOps: Güvenliği Boru Hattına Gömmek

Modern uygulamada Secure SDLC, DevSecOps olarak somutlaşır: güvenlik kontrolleri manuel bir aşama değil, CI/CD boru hattına gömülü otomatik adımlardır.

 git push
    ↓
 CI Pipeline:
    ├─ Lint + statik tip (PHPStan/Psalm)
    ├─ SAST (taint kuralları, Semgrep)          ← güvenlik
    ├─ Bağımlılık taraması (composer audit)     ← güvenlik
    ├─ Gizli anahtar taraması                    ← güvenlik
    ├─ Birim + entegrasyon testleri
    ├─ DAST (staging'e deploy sonrası)          ← güvenlik
    └─ Yayın kapısı: kritik bulgu varsa DURDUR  ← güvenlik
    ↓
 Deploy

Bu otomasyonun değeri, güvenliği "hatırlanması gereken bir şey" olmaktan çıkarıp "atlanamayacak bir adım" hâline getirmesidir. İnsan disiplini yorulur; boru hattı yorulmaz.

10. Checklist

• [ ] Güvenlik gereksinimleri (ASVS temelli) yazılı mı?
• [ ] Kritik akışlar için abuse case'ler tanımlı mı?
• [ ] Yeni özellikler tasarımda tehdit modellemeden geçiyor mu?
• [ ] Yazılı bir güvenli kodlama standardı var mı?
• [ ] Her PR güvenlik odaklı kod incelemesinden geçiyor mu?
• [ ] SAST + bağımlılık + gizli tarama CI'da otomatik mi?
• [ ] Kritik bulguda build'i durduran bir yayın kapısı var mı?
• [ ] Üretim loglanıyor, izleniyor ve bir incident response planı var mı?
• [ ] Yama/güncelleme için düzenli bir kadans tanımlı mı?

11. Laboratuvar

Lab 3.1 — Abuse case yazımı. Bir "parola sıfırlama" akışı için üç normal use case ve karşılık gelen üç abuse case yazın.

Lab 3.2 — CI güvenlik adımları. Basit bir PHP projesine composer audit ve bir statik analiz adımı (PHPStan) ekleyen minimal bir CI yapılandırması (GitHub Actions veya GitLab CI) yazın. Bir bilinen-açıklı bağımlılık ekleyip build'in kırıldığını gözlemleyin.

Lab 3.3 — Yayın kapısı tasarımı. Ekibiniz için "hangi bulgular yayını durdurur?" kriterini tek sayfalık bir politika olarak yazın (kritik/yüksek/orta ayrımıyla).

12. Quiz

1. "Shift left" ne demektir ve neden maliyeti düşürür?
2. "Duvara sıçratmak" anti-modeli neden başarısızdır?
3. Abuse case, use case'ten nasıl farklıdır? Bir örnek verin.
4. Saltzer & Schroeder ilkelerinden "fail secure" ve "complete mediation"ı açıklayın.
5. SAST, DAST ve sızma testinin her birinin güçlü ve zayıf yönü nedir?
6. Neden bu üç test yöntemi birbirinin yerini tutmaz?
7. Yayın kapısı (release gate) nedir ve DevSecOps'ta neden otomatikleştirilir?
8. OWASP ASVS gereksinim aşamasında nasıl kullanılır?
9. Yama yönetimi neden bir güvenlik kontrolü sayılır? (Drupageddon'a atıfla.)
10. DevSecOps boru hattına gömülü en az dört güvenlik adımı sayın.

13. Kaynakça

• Microsoft, Security Development Lifecycle (SDL).
• OWASP, Software Assurance Maturity Model (SAMM).
• NIST SP 800-218, Secure Software Development Framework (SSDF).
• OWASP, Application Security Verification Standard (ASVS).
• Saltzer & Schroeder, The Protection of Information in Computer Systems (1975) — güvenli tasarım ilkeleri.
• OWASP, DevSecOps Guideline.