# Bulgu Yönetimi ve Güvenli Kod Düzeltme Süreci: Remediation, Retest ve Security Debt **URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/bulgu-yonetimi-remediation-retest-security-debt ![Bulgu Yönetimi ve Güvenli Kod Düzeltme Süreci: Remediation, Retest ve Security Debt](/images/bilgi-merkezi/covers/cover-kod-11.webp) Kaynak kod analizi tamamlandı. SAST taraması yapıldı. Manuel güvenlik incelemesi gerçekleştirildi. Kritik bulgular doğrulandı. Rapor hazırlandı. Peki şimdi ne olacak? Aslında Application Security programlarının en kritik aşaması tam olarak burada başlar. Çünkü güvenlik açığını bulmak tek başına yeterli değildir. Gerçek değer, bulunan açığın doğru şekilde önceliklendirilmesi, geliştirme ekibine anlaşılır şekilde aktarılması, güvenli biçimde düzeltilmesi ve yapılan düzeltmenin gerçekten etkili olduğunun doğrulanmasıyla ortaya çıkar. Aksi halde güvenlik raporu yalnızca bir doküman olarak kalabilir. Critical ve High bulgular aylarca açık kalabilir. Geliştiriciler hangi açığın önce düzeltilmesi gerektiğini bilemeyebilir. Aynı güvenlik hataları yeni release’lerde tekrar oluşabilir. Ve kurum her pentest veya kaynak kod analizinde aynı bulgularla yeniden karşılaşabilir. Bu nedenle olgun Application Security yaklaşımı yalnızca: #### Detect yani bulma aşamasına odaklanmaz. Şu yaşam döngüsünü yönetir: **Detect → Validate → Prioritize → Assign → Remediate → Retest → Close → Prevent** Bu süreç genel olarak **Vulnerability Management** ve **Remediation Management** yaklaşımının uygulama güvenliği tarafını oluşturur. Bu bölümde bir kaynak kod güvenlik bulgusunun tespit edildiği andan kapatıldığı ana kadar nasıl yönetilmesi gerektiğini ayrıntılı olarak inceleyeceğiz. ### \1. Güvenlik Bulgusu Nedir? Güvenlik bulgusu, uygulama içerisinde tespit edilen ve güvenlik açısından risk oluşturabilecek zayıflığı ifade eder. Bu bulgu: - SAST, - SCA, - Secret Scanning, - DAST, - Manuel Code Review, - Pentest gibi farklı kaynaklardan gelebilir. Örneğin: #### SQL Injection bir güvenlik bulgusu olabilir. Ancak yalnızca bulgunun adı yeterli değildir. Bir bulgunun anlamlı olabilmesi için şu soruların cevaplanması gerekir: - Nerede bulundu? - Kim etkileniyor? - Saldırgan nasıl kullanabilir? - İş etkisi nedir? - Hangi koşullarda istismar edilebilir? - Nasıl düzeltilebilir? - Düzeltmenin sahibi kim? İyi bulgu yönetimi bu bilgileri tek bir yaşam döngüsünde toplar. ### \2. Araç Çıktısı ile Doğrulanmış Bulgu Aynı Şey Değildir SAST veya DAST gibi otomatik araçlar çok sayıda potansiyel bulgu üretebilir. Ancak bu çıktılar doğrudan açık kabul edilmemelidir. Örneğin araç: #### Potential SQL Injection uyarısı verebilir. Ancak framework seviyesinde parameterized query uygulanıyor olabilir. Bu durumda sonuç False Positive olabilir. Bu nedenle ilk aşama: #### Validation yani doğrulamadır. Doğrulanmamış araç çıktısı ile geliştirici backlog’unu doldurmak AppSec programının kalitesini düşürebilir. ### \3. Validation Nedir? Validation, bir güvenlik bulgusunun gerçek olup olmadığının ve hangi şartlarda istismar edilebildiğinin değerlendirilmesidir. Örneğin şu sorular sorulabilir: - Kod gerçekten reachable mı? - Fonksiyon production’da aktif mi? - Girdi saldırgan tarafından kontrol edilebilir mi? - Güvenlik kontrolü başka katmanda uygulanıyor mu? - Exploit senaryosu gerçekçi mi? Bu değerlendirme sonucunda bulgu örneğin: #### True Positive veya: #### False Positive olarak sınıflandırılabilir. ### \4. True Positive True Positive, tespit edilen durumun gerçekten güvenlik açığı olmasıdır. Ancak True Positive olması bulgunun mutlaka Critical olduğu anlamına gelmez. Örneğin bir XSS açığı gerçek olabilir ancak yalnızca internal admin kullanıcısını etkiliyor olabilir. Başka bir XSS ise internet üzerinden tüm müşterileri etkileyebilir. İkisi de True Positive’dir. Ancak risk seviyeleri farklı olabilir. Bu nedenle doğrulamadan sonra ikinci aşama: #### Risk Prioritization olmalıdır. ### \5. False Positive False Positive, güvenlik aracının problem olarak işaretlediği ancak gerçekte istismar edilebilir olmayan durumdur. Örneğin SAST kullanıcı girdisinin SQL sorgusuna ulaştığını görebilir. Fakat kullanılan ORM her sorguyu güvenli biçimde parametrize ediyor olabilir. Bu durumda gerçek SQL Injection yoktur. False Positive’lerin doğru yönetilmesi önemlidir. Çünkü çok fazla yanlış alarm: - geliştirici güvenini azaltır, - security backlog’u büyütür, - gerçek bulguların görünürlüğünü düşürür. Bu durum zamanla **Alert Fatigue** oluşturabilir. ### \6. Risk Önceliklendirme Neden Gereklidir? Bir uygulamada yüzlerce güvenlik bulgusu olabilir. Geliştirme ekibinin hepsini aynı anda düzeltmesi mümkün değildir. Bu nedenle doğru soru şudur: #### Hangisini önce düzeltmeliyiz? Sadece scanner severity’sine göre karar vermek yeterli değildir. Gerçek risk birçok faktörden oluşur. Örneğin: - teknik severity, - exploitability, - reachability, - internet exposure, - veri hassasiyeti, - iş kritikliği birlikte değerlendirilmelidir. ### \7. CVSS Tek Başına Önceliklendirme İçin Yeterli midir? Hayır. CVSS teknik zafiyet şiddetini standardize etmek için faydalıdır. Ancak kurumun gerçek iş riskini tek başına göstermez. Örneğin: CVSS 9.8 skorlu bir açık kullanılmayan demo servisinde olabilir. Buna karşılık CVSS 7.5 skorlu Broken Access Control açığı milyonlarca müşteri kaydına erişim sağlayabilir. İkinci bulgu kurum açısından daha kritik olabilir. Bu nedenle risk değerlendirmesi teknik skorun ötesine geçmelidir. ### \8. Business Criticality Uygulamanın iş açısından önemi risk önceliklendirmesinde büyük rol oynar. Örneğin aynı güvenlik açığı: - kurumsal intranet uygulamasında, - internet bankacılığı sisteminde aynı seviyede değerlendirilmemelidir. Bu nedenle uygulamalara kritik seviyeler atanabilir. Örneğin: #### Tier 1 – Kritik #### Tier 2 – Yüksek #### Tier 3 – Standart #### Tier 4 – Düşük AppSec risk modeli bu sınıflandırmayı kullanabilir. ### \9. Internet Exposure İnternet üzerinden erişilebilir sistemler genellikle daha yüksek saldırı yüzeyine sahiptir. Örneğin internal uygulamadaki zafiyet için saldırganın önce iç ağa erişmesi gerekebilir. Internet-facing uygulamada ise saldırgan doğrudan exploit deneyebilir. Bu nedenle exposure risk skorunu etkileyebilir. Ancak internal uygulamaların risksiz olduğu düşünülmemelidir. Insider threat ve lateral movement gibi saldırılar internal sistemleri de hedefleyebilir. ### \10. Reachability Bir güvenlik açığı bulunan kodun saldırgan tarafından gerçekten erişilebilir olup olmadığı önemli bir kriterdir. Örneğin zafiyetli fonksiyon: - dead code, - test code, - yalnızca local tool içerisinde olabilir. Başka bir durumda aynı fonksiyon public API endpoint’inden çağrılıyor olabilir. Teknik vulnerability aynı olabilir. Gerçek risk tamamen farklıdır. Bu nedenle Reachability özellikle SAST ve SCA bulgularında önemlidir. ### \11. Exploitability Exploitability, güvenlik açığının pratikte ne kadar kolay kullanılabileceğini ifade eder. Örneğin saldırganın: - authentication ihtiyacı var mı? - özel rol gerekiyor mu? - kullanıcı etkileşimi gerekiyor mu? - özel network erişimi gerekiyor mu? - karmaşık saldırı zinciri gerekiyor mu? soruları değerlendirilir. Basit HTTP request ile istismar edilen açık ile yalnızca çok özel koşullarda çalışan açık aynı önceliğe sahip olmayabilir. ### \12. Known Exploitation Bir vulnerability’nin saldırganlar tarafından aktif kullanıldığı biliniyorsa öncelik ciddi şekilde artmalıdır. Özellikle dependency güvenliğinde bu önemlidir. SCA sistemi bir CVE tespit etmiş olabilir. Eğer ilgili açık için public exploit mevcutsa veya aktif saldırılar görülüyorsa normal remediation SLA’sı beklenmeyebilir. Acil düzeltme gerekebilir. ### \13. Data Sensitivity Bulgunun hangi verilere erişim sağladığı da risk değerlendirmesinde önemlidir. Örneğin: - public ürün bilgisi, - kullanıcı profili, - kişisel veri, - finansal kayıt, - authentication credential farklı hassasiyet seviyelerine sahiptir. Bir authorization açığı hassas finansal veriye erişim sağlıyorsa business impact daha yüksek olacaktır. ### \14. Risk Matrisi Kurumlar teknik severity ile iş kritikliği arasında basit risk matrisi oluşturabilir. Örneğin: **High Severity + Critical Application = Critical Risk** **Medium Severity + Critical Application = High Risk** **High Severity + Low Criticality = Medium/High Risk** Bu yapı scanner’ın verdiği severity’yi kurumsal bağlamla zenginleştirir. ### \15. Critical Bulgu Nedir? Critical bulgu genellikle çok yüksek etki ve yüksek istismar potansiyeli taşıyan güvenlik problemidir. Örneğin: - unauthenticated Remote Code Execution, - authentication bypass, - kritik SQL Injection, - production cloud admin credential exposure Critical olarak değerlendirilebilir. Bu tür bulgular çoğunlukla normal sprint planını beklememelidir. Acil remediation süreci gerekebilir. ### \16. High Bulgu High severity bulgular ciddi güvenlik etkisine sahip ancak Critical seviyeden daha sınırlı olabilir. Örneğin: - hassas veri erişimi, - ciddi Broken Access Control, - kritik business logic problemi, - privilege escalation High seviyede değerlendirilebilir. Bu bulgular için belirli remediation SLA uygulanabilir. ### \17. Medium Bulgu Medium bulgular gerçek güvenlik riski taşır ancak genellikle belirli koşullar gerektirir veya etkisi daha sınırlıdır. Bunların backlog’da unutulmaması önemlidir. Çünkü saldırganlar bazen birkaç Medium bulguyu bir araya getirerek daha ciddi saldırı zinciri oluşturabilir. ### \18. Low Bulgu Low seviyeli bulgular doğrudan ciddi exploit sağlamayabilir. Ancak Defence in Depth açısından önem taşıyabilir. Örneğin: - eksik security header, - sınırlı bilgi ifşası, - düşük etkili configuration sorunu Low olabilir. Bunların tamamen göz ardı edilmesi de doğru değildir. ### \19. Informational Bulgu Informational bulgu doğrudan vulnerability olmayabilir. Güvenlik iyileştirmesi veya best practice önerisi olabilir. Örneğin: **HTTP response içerisinde gereksiz server version bilgisi.** Bu tek başına exploit olmayabilir. Ancak saldırgan reconnaissance sırasında bilgi kazanabilir. ### \20. Remediation Nedir? Remediation, güvenlik açığının güvenli şekilde düzeltilmesidir. Ancak remediation: **“Riskli satırı değiştir.”** demekten daha kapsamlıdır. Doğru remediation: - kök nedeni ortadan kaldırmalı, - uygulamanın fonksiyonunu bozmamalı, - yeni güvenlik açığı oluşturmamalı, - mümkünse tekrar oluşmasını engellemeli. Bu nedenle güvenlik ve geliştirme ekiplerinin birlikte çalışması gerekir. ### \21. Patch ile Root Cause Fix Aynı Şey midir? Her zaman değil. Örneğin SQL Injection için geliştirici kullanıcı girdisindeki ' karakterini engelleyebilir. Bu belirli saldırıyı durdurabilir. Ancak kök neden hâlâ vardır. Doğru çözüm parameterized query kullanmaktır. Bu nedenle güvenlik remediation’ında: #### Payload-specific fix yerine: #### Root Cause Fix tercih edilmelidir. ### \22. Kök Nedenin Düzeltilmesi Aynı güvenlik problemi birden fazla yerde bulunuyorsa tek tek satır düzeltmek yerine ortak bileşenin düzeltilmesi daha etkili olabilir. Örneğin 25 SQL Injection aynı unsafe database helper’dan kaynaklanıyorsa: 25 farklı fonksiyonu değiştirmek yerine, helper güvenli hale getirilebilir. Bu yaklaşım hem daha hızlı hem daha sürdürülebilirdir. ### \23. Secure Fix Nedir? Secure Fix, güvenlik problemini geçici olarak bastırmak yerine güvenli tasarım prensiplerine uygun şekilde çözmektir. Örneğin: **Problem:** User input shell command’a ekleniyor. Kötü çözüm: Belirli birkaç karakteri filtrelemek. İyi çözüm: Shell çağırmamak veya güvenli API kullanmak. Bu fark Secure Coding’in temelidir. ### \24. Remediation Guidance Güvenlik raporunda geliştiriciye uygulanabilir öneri sunulmalıdır. Örneğin sadece: **“SQL Injection açığını kapatın.”** yeterli değildir. Daha iyi öneri: **“Dinamik string birleştirme yerine ilgili framework’ün parameterized query API’sini kullanın.”** şeklindedir. Mümkünse kullanılan teknolojiye özgü örnek verilmelidir. ### \25. Unsafe ve Secure Kod Örneği Geliştiricinin problemi daha hızlı anlaması için kötü ve iyi uygulama karşılaştırılabilir. Örneğin: #### Unsafe Dinamik SQL string oluşturma. #### Secure Prepared Statement kullanımı. Bu yaklaşım güvenlik raporunun eğitim değerini de artırır. ### \26. Remediation Developer’ın Sorumluluğu mudur? Genellikle kod değişikliğini geliştirici yapar. Ancak güvenlik ekibi de sürecin parçasıdır. Güvenlik ekibi: - riski açıklar, - güvenli yaklaşımı önerir, - kritik durumlarda tasarımı değerlendirir, - düzeltmeyi retest eder. Bu ortak sorumluluk modelidir. ### \27. Bulgu Owner Ataması Her güvenlik bulgusunun sorumlu bir sahibi olmalıdır. Örneğin: - Application Team - Backend Team - Platform Team - DevOps Team - IAM Team owner olabilir. Owner yoksa bulgunun kapanma ihtimali ciddi şekilde düşer. Bu nedenle otomatik ticket entegrasyonu faydalıdır. ### \28. Ticket Sistemi Entegrasyonu AppSec bulguları Jira, Azure DevOps veya benzeri sistemlere aktarılabilir. Ticket içerisinde örneğin: - bulgu adı, - severity, - affected file, - remediation, - SLA, - security owner yer alabilir. Bu yaklaşım PDF raporun geliştiricinin günlük iş akışına dönüşmesini sağlar. ### \29. Security Backlog Bütün açıklar anında kapatılamıyorsa Security Backlog oluşturulur. Ancak backlog sadece bulgu deposu olmamalıdır. Her bulgu: - priority, - owner, - deadline, - status bilgisine sahip olmalıdır. Aksi halde Security Debt kontrolsüz büyür. ### \30. Security Debt Nedir? Security Debt, henüz giderilmemiş güvenlik problemlerinin zaman içerisinde birikmesini ifade eder. Technical Debt’e benzer. Örneğin ekip sürekli yeni feature geliştiriyor ancak Medium güvenlik bulgularını erteliyor olabilir. Zaman içerisinde yüzlerce açık birikir. Bu yapı daha sonra büyük remediation maliyetine dönüşebilir. ### \31. Security Debt Nasıl Oluşur? En yaygın nedenler: - zaman baskısı, - feature önceliği, - legacy code, - yanlış risk değerlendirmesi, - owner eksikliği, - yetersiz kaynak, - düşük AppSec olgunluğu. Security Debt tamamen sıfırlanamayabilir. Ancak bilinmeli ve yönetilmelidir. ### \32. Security Debt Envanteri Kurum açık security debt’i görünür hale getirmelidir. Örneğin dashboard: #### Critical Open: 2 #### High Open: 13 #### Medium Open: 84 #### Overdue: 21 gösterebilir. Bu veri yönetim için önemli risk göstergesidir. ### \33. Security Debt Yaşı Yalnızca kaç bulgu olduğu değil ne kadar süredir açık olduğu da önemlidir. Örneğin 400 günlük High vulnerability ciddi süreç problemine işaret edebilir. Bu nedenle **Finding Age** ölçülmelidir. ### \34. SLA Nedir? SLA burada bulgunun belirli süre içerisinde ele alınması beklentisini ifade eder. Örneğin kurum politikası: **Critical:** 3 gün **High:** 15 gün **Medium:** 45 gün **Low:** 90 gün şeklinde olabilir. Bu süreler örnektir. Kurumun sektörüne, regülasyonuna ve risk iştahına göre belirlenmelidir. ### \35. Critical Açık İçin Normal SLA Beklenmeli mi? Her zaman değil. Örneğin internet-facing production sisteminde aktif exploitation bulunan Critical RCE tespit edilirse normal SLA süresi beklemek uygun olmayabilir. Incident Response devreye girebilir. Geçici mitigation uygulanabilir. Servis erişimi sınırlandırılabilir. Ardından kalıcı düzeltme yapılabilir. ### \36. Mitigation ile Remediation Arasındaki Fark #### Mitigation riskin geçici olarak azaltılmasıdır. #### Remediation kök nedenin kalıcı şekilde düzeltilmesidir. Örneğin SSRF açığında WAF kuralı geçici mitigation olabilir. Kodun allowlist mimarisiyle yeniden tasarlanması kalıcı remediation olabilir. İkisi karıştırılmamalıdır. ### \37. Compensating Control Bulgu hemen düzeltilemiyorsa riski azaltmak için başka güvenlik kontrolü uygulanabilir. Örneğin: - network ACL, - WAF, - feature disable, - access restriction compensating control olabilir. Ancak kontrolün gerçek risk azaltma etkisi doğrulanmalıdır. ### \38. Risk Acceptance Nedir? Bazı bulgular bilinçli olarak kabul edilebilir. Örneğin düzeltme maliyeti çok yüksek ve gerçek exploitability çok düşük olabilir. Bu durumda Risk Acceptance uygulanabilir. Ancak karar: - belgeli, - onaylı, - süreli, - gerekçeli olmalıdır. ### \39. Geliştirici Kendi Bulduğu Riski Kabul Edebilir mi? Kurumsal modele bağlıdır ancak ideal olarak yüksek riskli güvenlik kabulü yalnızca geliştirici kararı olmamalıdır. Risk Owner veya ilgili yönetim sorumlusu onaylamalıdır. Çünkü teknik ekip yalnızca teknik maliyeti görürken iş tarafı gerçek riski taşıyan taraftır. ### \40. Risk Acceptance Süresiz Olmalı mı? Tercihen hayır. Örneğin: #### Risk accepted until next major release veya belirli tarih atanabilir. Süre dolduğunda bulgu tekrar değerlendirilir. Bu sayede yıllar önce verilen kararlar sonsuza kadar geçerli kalmaz. ### \41. Exception Management Security policy’de istisna gerekiyorsa Exception Management süreci kullanılabilir. Örneğin pipeline bir vulnerable dependency nedeniyle build’i engelliyor olabilir. Geliştirici bunun unreachable olduğunu kanıtlayabilir. Security team belirli süre için exception verebilir. Bu istisna kayıt altına alınmalıdır. ### \42. Suppression ile Risk Acceptance Aynı Şey midir? Hayır. Suppression genellikle teknik gürültüyü kaldırmak için kullanılır. Örneğin False Positive bulgu suppress edilir. Risk Acceptance ise gerçek bir güvenlik riskinin bilinçli şekilde kabul edilmesidir. Bu ayrım önemlidir. ### \43. Retest Nedir? Retest, geliştirici bulguyu düzelttikten sonra güvenlik ekibinin güvenlik açığının gerçekten kapanıp kapanmadığını doğrulamasıdır. Bu kritik bir aşamadır. Çünkü: **“Kod değişti.”** demek: **“Açık kapandı.”** anlamına gelmez. Düzeltme yanlış uygulanmış olabilir. ### \44. Retest Nasıl Yapılır? Bulgunun türüne göre yöntem değişir. Örneğin SAST bulgusu için: Yeni kod tekrar SAST’tan geçirilebilir. Business Logic açığı için: Manuel pentest gerekir. Dependency CVE için: SCA yeniden çalıştırılabilir. Secret exposure için: Eski credential’ın revoke edildiği doğrulanabilir. Retest yöntemi bulgunun doğasına uygun olmalıdır. ### \45. Retest Sonucu Durumları Bulgu örneğin şu durumlara geçebilir: #### Closed Düzeltme doğrulandı. #### Partially Fixed Risk kısmen azaltıldı. #### Still Open Açık devam ediyor. #### Risk Accepted Düzeltme yapılmadı, risk kabul edildi. #### Not Applicable Teknik şartlar değişti. Bu durumların açık tanımları olmalıdır. ### \46. Partial Fix Nedir? Bazen geliştirici açığın yalnızca bir bölümünü düzeltir. Örneğin authorization kontrolü üç endpoint’ten ikisine eklenmiştir. Üçüncü endpoint hâlâ açıktır. Bu durumda bulgu Closed yapılmamalıdır. **Partially Fixed** olarak kalabilir. ### \47. Fix Doğru Ama Eksikse Ne Olur? Remediation yeni saldırı yollarını değerlendirmelidir. Örneğin kullanıcı /api/orders/123 endpoint’inde authorization kontrolünü düzeltmiş olabilir. Ancak /api/order/export/123 hâlâ aynı veriye erişiyor olabilir. Bu nedenle retest yalnızca orijinal payload’ı tekrar göndermekten ibaret değildir. Kök nedenin tüm varyasyonları incelenmelidir. ### \48. Security Regression Nedir? Daha önce düzeltilen güvenlik probleminin yeni kod değişiklikleriyle tekrar ortaya çıkmasına Security Regression denir. Örneğin SQL Injection üç ay önce kapatılmıştır. Başka geliştirici aynı unsafe helper’ı tekrar kullanmıştır. Açık geri dönmüştür. Bu nedenle tek seferlik remediation yeterli değildir. ### \49. Regression Test Nasıl Oluşturulur? Bulgu kapatıldıktan sonra mümkünse otomatik test yazılmalıdır. Örneğin authorization açığı için integration test oluşturulabilir. Standart kullanıcı başka kullanıcının verisine erişmeye çalışır. Test beklenen sonucu doğrular: #### 403 Forbidden Gelecekte kontrol kaldırılırsa test fail olur. ### \50. Güvenlik Bulgusu Unit Test’e Dönüştürülebilir mi? Bazı durumlarda evet. Örneğin: - authorization, - validation, - cryptographic policy unit veya integration test ile kontrol edilebilir. Bu yaklaşım güvenlik bilgisini kalıcı hale getirir. ### \51. Pentest Bulgusu Otomasyona Dönüştürülebilir mi? Bazı pentest bulguları custom SAST, DAST veya regression rule’a dönüştürülebilir. Örneğin kurumun internal framework’ündeki belirli unsafe kullanım manuel pentest sırasında keşfedilmiş olabilir. Custom SAST rule yazılır. Bundan sonra diğer bütün repository’lerde otomatik kontrol edilir. Bu AppSec olgunluğunun önemli göstergesidir. ### \52. Finding Recurrence Nedir? Aynı CWE veya aynı root cause sürekli tekrar ediyorsa yalnızca bulgu bazlı remediation yeterli değildir. Örneğin 6 ay içerisinde 30 Broken Access Control bulunmuş olabilir. Bu durumda problem: **“30 ayrı açık”** değil, **“Authorization tasarımımızda sistematik problem var.”** olarak görülmelidir. ### \53. Root Cause Remediation Tekrarlayan zafiyetlerde daha üst seviyede çözüm gerekir. Örneğin: - central authorization library, - secure database helper, - approved crypto library, - mandatory security middleware oluşturulabilir. Bu şekilde güvenli davranış geliştiricinin manuel tercihinden çıkarılıp platform standardına dönüşür. ### \54. Secure by Default Framework İdeal durumda internal framework güvenli davranışı default yapar. Örneğin yeni endpoint varsayılan olarak authenticated olabilir. Developer açıkça public yapmak isterse özel annotation kullanır. Böylece güvenli yol otomatik hale gelir. Bu Security by Design yaklaşımının güçlü örneğidir. ### \55. Bulgu Yönetimi ve Security Champion Security Champion ekip içerisinde bulguların daha hızlı anlaşılmasına yardımcı olabilir. Örneğin AppSec ekibinin oluşturduğu bulguyu takımın geri kalanına açıklar. Remediation için teknik yönlendirme yapabilir. Bu yapı özellikle büyük geliştirme organizasyonlarında güvenlik ekiplerinin ölçeklenmesini sağlar. ### \56. Remediation Workshop Nedir? Özellikle kritik proje sonrası AppSec ve development ekipleri bulguları birlikte değerlendirebilir. Workshop sırasında: - en kritik açıklar, - kök nedenler, - önerilen kod değişiklikleri, - architectural fixes ele alınabilir. Bu, yalnızca PDF rapor göndermekten çok daha etkilidir. ### \57. Security ile Developer Arasında Dil Problemi Güvenlik uzmanı: **“CWE-639 Authorization Bypass.”** diyebilir. Geliştirici ise: **“Hangi fonksiyonu değiştirmeliyim?”** diye sorar. İyi bulgu yönetimi bu iki dili birleştirir. Bulgu teknik olarak doğru ama geliştirici açısından aksiyona dönüşebilir olmalıdır. ### \58. İyi Bulgu Açıklaması Nasıl Olmalı? Örnek yapı: #### Risk Standart kullanıcı başka müşterinin faturalarına erişebiliyor. #### Root Cause Backend nesne sahipliğini doğrulamıyor. #### Affected Endpoint GET /api/invoices/{id} #### Remediation Query sonucu döndürülmeden önce invoice owner ID ile authenticated user ID doğrulanmalı. Bu format geliştiricinin ne yapması gerektiğini açık hale getirir. ### \59. Güvenli Kod Örneği Özellikle kritik bulgularda framework’e uygun güvenli kod örneği verilebilir. Bu geliştiricinin remediation süresini kısaltır. Ancak copy-paste kodun her ortama uygun olmayabileceği belirtilmelidir. Önemli olan güvenlik prensibinin anlaşılmasıdır. ### \60. Security SLA Nasıl İzlenir? Dashboard oluşturulabilir. Örneğin: - Open Critical - Overdue High - MTTR - Closure Rate - Reopened Findings izlenebilir. Bu metrikler AppSec operasyonunun gerçek durumunu gösterir. ### \61. Mean Time to Remediate – MTTR MTTR, bulgunun tespit edilmesinden kapatılmasına kadar geçen ortalama süredir. Örneğin: Critical MTTR: 3 gün High MTTR: 12 gün Medium MTTR: 45 gün takip edilebilir. Amaç zaman içerisinde bu süreleri risk bazlı azaltmaktır. ### \62. Closure Rate Belirli dönemde açılan bulguların ne kadarının kapatıldığını gösterir. Örneğin: Ay boyunca 100 yeni bulgu. 80 bulgu kapandı. Closure Rate %80 olabilir. Ancak severity bazlı ayrı değerlendirme yapmak daha anlamlıdır. ### \63. Reopen Rate Closed yapılan bulgunun retest veya sonraki testte tekrar açık bulunma oranı önemlidir. Yüksek Reopen Rate remediation kalitesinin düşük olduğunu gösterebilir. Bu durumda developer guidance iyileştirilmelidir. ### \64. Security Debt Trend Toplam açık bulgu sayısı zaman içerisinde izlenebilir. Amaç her zaman sıfır bulgu olmayabilir. Ancak trend önemlidir. Örneğin security debt sürekli artıyorsa program sürdürülebilir değildir. Yeni açık üretim hızı remediation hızından fazladır. ### \65. Burn-Down Security Debt için sprint burn-down yaklaşımı kullanılabilir. Örneğin: Quarter başlangıcı: 120 High bulgu. Quarter sonu hedef: 40 High bulgu. Her sprint belirli remediation kapasitesi ayrılabilir. Bu güvenlik işlerini görünür hale getirir. ### \66. Security Remediation Sprint Özellikle legacy sistemlerde belirli dönemler remediation için ayrılabilir. Ancak sürekli sadece ayrı “security sprint” kullanmak ideal değildir. Uzun vadede güvenlik normal geliştirme backlog’unun parçası olmalıdır. ### \67. Feature ile Security Öncelik Çatışması Geliştirme ekipleri sürekli yeni feature baskısı altında olabilir. Güvenlik açığı çoğu zaman gelir getiren yeni özellik kadar görünür değildir. Bu nedenle risk yönetimi yönetsel destek gerektirir. Critical güvenlik açığının neden feature’dan önce ele alınması gerektiği net şekilde tanımlanmalıdır. ### \68. Product Owner Güvenlik Sürecinde Yer Almalı mı? Evet. Product Owner veya ilgili iş sahibi uygulamanın kritikliği ve remediation öncelikleri konusunda sürece dahil olabilir. Çünkü güvenlik yalnızca teknik konu değildir. Business risk’tir. ### \69. Security Risk Owner Her kritik uygulamanın bir risk owner’ı olması faydalıdır. Bu kişi teknik owner olmak zorunda değildir. Risk Acceptance gibi kararların kimin tarafından verileceği böylece netleşir. ### \70. AppSec Dashboard Kimler İçin Olmalı? Farklı kullanıcılar farklı bilgi ister. #### Developer Kendi açık ticket’larını görmek ister. #### Engineering Manager Ekibin security backlog’unu görmek ister. #### CISO / Security Manager Kurum genelindeki trendleri görmek ister. #### Executive Management Kritik business risk’i görmek ister. Dashboard’lar bu ihtiyaçlara göre özelleştirilebilir. ### \71. Yöneticiye Kod Satırı Gösterilmeli mi? Genellikle gerekmez. Üst yönetim için şu bilgiler daha değerlidir: - kaç Critical açık var, - hangi kritik uygulamalar etkileniyor, - ne kadarı SLA dışı, - risk trendi ne yönde. Teknik detaylar engineering seviyesinde kalabilir. ### \72. Developer İçin Yönetici Özeti Yeterli mi? Hayır. Developer’ın doğrudan: - file, - function, - line, - root cause, - remediation bilgisine ihtiyacı vardır. Bu nedenle AppSec raporu farklı seviyelerde detay sunmalıdır. ### \73. Risk-Based SLA SLA yalnızca severity’ye değil varlık kritikliği ve exposure’a göre farklılaştırılabilir. Örneğin Internet-facing Tier 1 uygulamadaki High bulgu için daha kısa süre uygulanabilir. Internal Tier 4 uygulamadaki aynı zafiyet için daha uzun süre tanımlanabilir. Bu daha gerçekçi risk yönetimi sağlar. ### \74. Dependency Remediation SCA bulgularında remediation çoğunlukla dependency upgrade olur. Ancak geliştirici şu bilgiyi görmelidir: - mevcut version, - vulnerable range, - fixed version, - breaking change riski. Blind upgrade production problemi yaratabilir. Bu nedenle test süreci gereklidir. ### \75. Secret Bulgusunun Remediation’ı Secret exposure’da yalnızca dosyadan kaldırmak yeterli değildir. Doğru süreç: #### Revoke ↓ #### Rotate ↓ #### Repository Cleanup ↓ #### Log Investigation ↓ #### Prevention şeklindedir. Bu bir güvenlik olayı olarak ele alınabilir. ### \76. Authorization Bulgusunun Remediation’ı Broken Access Control açığında sadece frontend butonunu gizlemek çözüm değildir. Backend server-side authorization kontrolü uygulanmalıdır. Örneğin: #### Authenticated User #### Object Ownership #### Required Permission doğrulanmalıdır. Bu kontrol merkezi hale getirilebilirse tekrar riski azalır. ### \77. XSS Remediation XSS için yalnızca