# Kurumsal Kod Güvenliği Programı: Secure SDLC ve SecureSys Yaklaşımı

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/kurumsal-kod-guvenligi-programi-secure-sdlc

![Kurumsal Kod Güvenliği Programı: Secure SDLC ve SecureSys Yaklaşımı](/images/bilgi-merkezi/covers/cover-kod-12.webp)

Bir kurum kaynak kod analizi yaptırabilir.

SAST ürünü kullanabilir.

SCA ile açık kaynak bağımlılıklarını tarayabilir.

Secret Scanning ile kod içerisindeki API key ve parolaları tespit edebilir.

DAST çalıştırabilir.

Pentest yaptırabilir.

Geliştiricilere Secure Coding eğitimi verebilir.

Bütün bunlar değerlidir.

Ancak kritik soru şudur:

#### Bu faaliyetler birbirinden bağımsız mı yürütülüyor, yoksa tek bir güvenlik programının parçaları mı?

Gerçek Application Security olgunluğu tam olarak bu ayrımda ortaya çıkar.

Tek tek güvenlik kontrolleri uygulamak, belirli riskleri azaltabilir.

Ancak sürdürülebilir yazılım güvenliği için bu kontrollerin;

**politika, süreç, teknoloji, insan ve ölçüm**

katmanları altında tek bir yapıya dönüştürülmesi gerekir.

Bu yapı genel olarak **Secure SDLC – Secure Software Development Life Cycle** ve kurumsal **Application Security Programı** çerçevesinde ele alınabilir.

Amaç artık yalnızca belirli bir uygulamadaki güvenlik açıklarını bulmak değildir.

Asıl hedef:

**kurumun güvenli yazılım üretme kapasitesini sürekli olarak geliştirmektir.**

Bu bölümde bugüne kadar ele aldığımız bütün kavramları tek bir model içerisinde birleştireceğiz.

Secure Coding’den SAST’a,

SCA’dan Secret Scanning’e,

DevSecOps’tan penteste,

bulgu yönetiminden Security Champion modeline kadar bütün güvenlik katmanlarının kurumsal ölçekte nasıl bir araya getirilebileceğini inceleyeceğiz.

### \1. Kurumsal Kod Güvenliği Programı Nedir?

Kurumsal Kod Güvenliği Programı, bir kurumun geliştirdiği yazılımların güvenlik risklerini yaşam döngüsünün tamamında yönetmek için oluşturduğu sürekli süreçtir.

Bu program yalnızca güvenlik testi yapmaz.

Aynı zamanda:

- güvenlik gereksinimlerini belirler,
- geliştiricilere güvenli kodlama standardı sunar,
- kaynak kodu analiz eder,
- üçüncü taraf bileşenleri izler,
- CI/CD süreçlerine güvenlik ekler,
- bulguları yönetir,
- güvenlik metrikleri üretir,
- tekrar eden zayıflıkları azaltır.

Bu nedenle AppSec programı teknik araç projesi değildir.

Bir yönetim modelidir.

### \2. Tek Seferlik Test ile Program Arasındaki Fark

Tek seferlik test şu soruya cevap verir:

**“Bugün bu uygulamada hangi güvenlik açıkları var?”**

Kurumsal program ise daha kapsamlı sorular sorar:

#### Bu açık neden oluştu?

#### Başka hangi uygulamalarda aynı problem olabilir?

#### Aynı açık yeniden oluşabilir mi?

#### Geliştiriciyi daha erken nasıl uyarabiliriz?

#### Bu problemi otomatik olarak nasıl engelleyebiliriz?

Bu fark çok önemlidir.

Tek seferlik analiz mevcut problemi gösterir.

Program ise problemin tekrarını azaltır.

### \3. Application Security Programının Ana Hedefi

İyi bir AppSec programının temel hedefi:

**daha fazla güvenlik açığı bulmak değildir.**

Asıl hedef:

**daha az güvenlik açığı üretmektir.**

İlk yıllarda daha fazla güvenlik açığı bulunabilir.

Çünkü görünürlük artar.

Ancak program olgunlaştıkça:

- tekrar eden açıkların azalması,
- kritik bulguların daha erken bulunması,
- MTTR süresinin kısalması,
- production’a kaçan zafiyetlerin azalması

beklenir.

### \4. Secure SDLC Nedir?

Secure SDLC, güvenliğin yazılım geliştirme yaşam döngüsünün tamamına entegre edilmesidir.

Klasik SDLC şu şekilde olabilir:

**Planlama → Tasarım → Geliştirme → Test → Release → Production**

Secure SDLC’de ise her aşamanın güvenlik kontrolü vardır.

Örneğin:

**Planlama → Güvenlik Gereksinimleri**

**Tasarım → Threat Modeling**

**Geliştirme → Secure Coding**

**Commit → Secret Scanning**

**Build → SAST + SCA**

**Test → DAST + API Security**

**Release → Pentest / Security Gate**

**Production → Monitoring**

Böylece güvenlik son aşamada yapılan kontrol olmaktan çıkar.

### \5. Secure SDLC Neden Daha Güçlüdür?

Çünkü güvenlik açığının mümkün olduğunca erken tespit edilmesini sağlar.

Örneğin authorization problemi tasarım sırasında fark edilirse mimari daha baştan doğru oluşturulabilir.

Kodlama sırasında bulunursa birkaç satır değişiklik gerekebilir.

Pentest sırasında bulunursa birçok modül etkilenmiş olabilir.

Production’da veri ihlali sonrasında bulunursa maliyet çok daha yüksek olabilir.

Temel prensip:

**Problemi ne kadar erken bulursanız, düzeltmek o kadar kolaydır.**

### \6. Secure SDLC’nin İlk Aşaması: Güvenlik Gereksinimleri

Yazılım projesinin başında güvenlik gereksinimleri belirlenmelidir.

Örneğin:

- kullanıcılar MFA kullanacak mı?
- hassas veriler şifrelenecek mi?
- hangi roller hangi verilere erişecek?
- hangi loglar tutulacak?
- session süresi ne olacak?
- hangi regülasyonlar uygulanacak?

Bu gereksinimler geliştirme başlamadan netleştirilirse güvenlik tasarımın parçası olur.

### \7. Security Requirement Örnekleri

Örneğin bir finans uygulamasında şu gereksinimler tanımlanabilir:

**Bütün kritik işlemler için güçlü authentication zorunlu.**

**Kullanıcı sadece kendi hesaplarına erişebilir.**

**Finansal işlemler audit log’a yazılır.**

**Hassas veri düz metin saklanmaz.**

**Production credential kaynak kod içerisinde tutulamaz.**

Bunlar daha sonra test edilebilir güvenlik kontrollerine dönüştürülebilir.

### \8. Threat Modeling

Threat Modeling, yazılım geliştirme başlamadan veya önemli mimari değişikliklerde potansiyel tehditlerin analiz edilmesidir.

Bu süreç şu soruları sorar:

- Koruduğumuz varlıklar neler?
- Saldırgan kim olabilir?
- Sisteme nereden girebilir?
- Trust Boundary nerede?
- En kötü saldırı senaryosu nedir?

Bu analiz kaynak kod incelemesi ve pentest önceliklerini de belirleyebilir.

### \9. Threat Modeling Ne Zaman Yapılmalıdır?

Özellikle:

- yeni uygulama,
- yeni kritik modül,
- authentication değişikliği,
- cloud migration,
- yeni API mimarisi,
- finansal işlem sistemi

gibi değişikliklerde faydalıdır.

Her küçük kod değişikliğinde tam threat model yapılması gerekmez.

Risk bazlı yaklaşım kullanılabilir.

### \10. Security Architecture Review

Kritik projelerde güvenlik mimarisi uygulama geliştirilmeden önce gözden geçirilebilir.

Örneğin:

- authentication mimarisi,
- authorization modeli,
- network trust boundary,
- key management,
- secrets management,
- logging mimarisi

değerlendirilebilir.

Bir mimari hatayı üretimden sonra düzeltmek çok maliyetli olabilir.

### \11. Secure Coding Standardı

Secure Coding Standard geliştiricilerin uyması gereken temel güvenlik kurallarını tanımlar.

Örneğin:

- SQL sorgularında parameterized query kullanılmalı.
- Kullanıcı girdileri doğrulanmalı.
- Output encoding uygulanmalı.
- Authorization server-side yapılmalı.
- Secret kaynak kod içerisinde tutulmamalı.
- Güvenli kriptografik algoritmalar kullanılmalı.
- Hassas veri loglanmamalı.

Bu standart teknolojiye özgü hale getirilebilir.

### \12. Teknolojiye Özgü Secure Coding

Genel kurallar faydalıdır ancak geliştiriciler teknolojiye özgü örneklere ihtiyaç duyar.

Örneğin Java için:

- Spring Security
- JPA
- Jackson
- Java Crypto

gibi yapıların güvenli kullanımı anlatılabilir.

.NET ekibi için farklı örnekler gerekir.

JavaScript ve frontend ekipleri için:

- DOM XSS
- CSP
- token storage

gibi konular öne çıkabilir.

### \13. Secure Coding Checklist

Developer ve reviewer için kısa checklist hazırlanabilir.

Örneğin:

- Kullanıcı girdisi doğrulandı mı?
- Authorization mevcut mu?
- Secret var mı?
- SQL query güvenli mi?
- Hassas veri loglanıyor mu?
- Dependency yeni mi?

Bu liste Pull Request sürecinin parçası olabilir.

### \14. Peer Code Review

Geliştiricinin yazdığı kodun başka geliştirici tarafından incelenmesi kod kalitesi kadar güvenliği de artırabilir.

Peer Review sırasında güvenlik checklist’i kullanılabilir.

Ancak bu tam Security Code Review değildir.

Yine de güvenlik hatalarını erken yakalamak açısından önemli bir katmandır.

### \15. Security Code Review

Critical modüllerde özel Security Code Review uygulanabilir.

Özellikle:

- authentication,
- authorization,
- ödeme,
- password reset,
- file upload,
- cryptography

gibi alanlar AppSec uzmanları tarafından manuel incelenebilir.

Bu kontrol SAST’ın göremediği business logic ve mimari problemleri ortaya çıkarabilir.

### \16. SAST’ın Kurumsal Programdaki Rolü

SAST büyük kod tabanını sürekli analiz edebilmesi nedeniyle kurumsal AppSec programının temel otomasyonlarından biridir.

Amaç yılda bir scan değil;

**kod değiştikçe güvenlik kontrolü yapmak**

olmalıdır.

SAST Pull Request veya build aşamasına entegre edilebilir.

### \17. SAST Coverage

Kurumsal programda şu metrik izlenebilir:

#### Kaç repository SAST kapsamında?

Örneğin:

Toplam 200 repository.

SAST kapsamında 170.

Coverage:

%85.

Hedef zaman içerisinde kritik uygulamalarda %100’e yaklaşmak olabilir.

### \18. SAST Policy

Bütün uygulamalar için aynı SAST politikası gerekli olmayabilir.

Tier 1 kritik uygulamada:

- Critical ve High bloklanabilir.
- Full scan sık yapılabilir.
- Manual triage zorunlu olabilir.

Tier 4 internal tool’da daha esnek politika kullanılabilir.

Bu Risk-Based AppSec yaklaşımıdır.

### \19. SCA’nın Kurumsal Rolü

SCA açık kaynak ve üçüncü taraf dependency güvenliğini yönetir.

Kurumsal program açısından temel hedefler:

- dependency inventory,
- known CVE detection,
- EOL package detection,
- license visibility,
- SBOM generation

olabilir.

SCA özellikle modern yazılımlarda zorunlu hale gelmiştir.

### \20. Dependency Governance

Kurum hangi dependency’lerin kullanılabileceği konusunda politika oluşturabilir.

Örneğin:

- EOL library yasak.
- Critical CVE bulunan package yeni projeye eklenemez.
- Belirli lisanslar approval gerektirir.
- Paketler yalnızca trusted repository’den indirilir.

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

### \21. Approved Library Catalog

Kurumsal uygulamalarda onaylı kütüphane listesi oluşturulabilir.

Örneğin:

Authentication → Approved Framework A

Logging → Approved Library B

Cryptography → Approved Library C

Bu yapı güvenli tasarımı standardize eder.

### \22. Secret Scanning’in Kurumsal Rolü

Secret Scanning’in hedefi yalnızca repository’de API key bulmak değildir.

İdeal model:

#### Secret’ın repository’ye hiç ulaşmaması

olmalıdır.

Bu nedenle:

- pre-commit,
- push protection,
- pipeline scan,
- history scan

birlikte uygulanabilir.

### \23. Zero Secret in Code Politikası

Kurum şu hedefi belirleyebilir:

**Production secret kaynak kod içerisinde tutulamaz.**

Bunu yalnızca politika olarak yazmak yerine teknik olarak enforce etmek daha güçlüdür.

Push Protection active secret içeren commit’i engelleyebilir.

### \24. Secrets Management Standardı

Uygulamalar secret’ları merkezi sistemden almalıdır.

Örneğin:

- Vault,
- Secrets Manager,
- KMS,
- workload identity

yaklaşımları kullanılabilir.

Bu yapı secret lifecycle’ını daha kontrollü hale getirir.

### \25. DAST’ın Kurumsal Programdaki Rolü

DAST test veya staging ortamında otomatik runtime test sağlar.

Özellikle internet-facing web uygulamalarında faydalıdır.

DAST uygulamanın kaynak koddan production benzeri ortama geçerken oluşan güvenlik problemlerini yakalayabilir.

### \26. API Security Testing

Modern kurumlarda web UI kadar API güvenliği de kritiktir.

API güvenlik programında:

- API inventory,
- schema validation,
- DAST,
- manuel pentest,
- authorization testleri

bulunabilir.

Özellikle BOLA ve business logic problemlerinde manuel test önemlidir.

### \27. Pentest Programı

Pentest tek seferlik proje yerine merkezi program olarak yönetilebilir.

Örneğin kritik uygulamalar:

- yılda belirli periyot,
- major release sonrası,
- kritik mimari değişiklikte

pentest alabilir.

Daha düşük riskli uygulamalarda farklı frekans kullanılabilir.

### \28. Pentest Frekansı Nasıl Belirlenir?

Risk bazlı model kullanılabilir.

Örneğin:

#### Tier 1

Sık periyodik pentest + major release.

#### Tier 2

Yıllık veya kritik değişiklik sonrası.

#### Tier 3

Daha seyrek veya risk bazlı.

Bu yalnızca örnek modeldir.

Kurumun regülasyonları ve risk profili belirleyici olmalıdır.

### \29. Pentest Bulguları Programa Nasıl Beslenir?

Pentest raporu yalnızca ilgili uygulamanın remediation’ı için kullanılmamalıdır.

Bulgu trendleri analiz edilmelidir.

Örneğin pentestlerde sürekli:

#### BOLA

bulunuyorsa bütün API ekiplerinde authorization standardı gözden geçirilebilir.

Bu AppSec programının kurumsal öğrenme mekanizmasıdır.

### \30. DevSecOps Entegrasyonu

Secure SDLC’nin otomasyon katmanı büyük ölçüde DevSecOps üzerinden uygulanır.

Pipeline’da:

#### Secret Scan

↓

#### SAST

↓

#### SCA

↓

#### IaC Scan

↓

#### Container Scan

↓

#### Security Quality Gate

bulunabilir.

Böylece güvenlik kontrolü her release’de otomatik çalışır.

### \31. Golden Pipeline

Kurum bütün ekipler için standart güvenli pipeline template oluşturabilir.

Yeni proje başladığında developer güvenlik entegrasyonunu sıfırdan kurmaz.

Golden Pipeline içinde güvenlik kontrolleri varsayılan olarak gelir.

Bu hem operasyonel kolaylık hem standardizasyon sağlar.

### \32. Security Quality Gate

Quality Gate kabul edilemez güvenlik riskini production’a ulaşmadan engeller.

Örneğin:

**Yeni Critical SAST bulgusu → Block**

**Active Production Secret → Block**

**Reachable Critical CVE → Block**

Ancak her bulgu için build durdurulmamalıdır.

Risk bazlı politika gereklidir.

### \33. New Code Policy

Legacy sistemlerde binlerce geçmiş bulgu bulunabilir.

Bu durumda:

**Yeni kod eski güvenlik borcunu artırmamalı.**

prensibi kullanılabilir.

Yeni Critical ve High bulgular bloklanır.

Mevcut Security Debt ayrı planla azaltılır.

### \34. Security Debt Yönetimi

Security Debt görünür ve ölçülebilir olmalıdır.

Örneğin:

- toplam açık bulgu,
- overdue bulgu,
- bulgu yaşı,
- severity dağılımı,
- tekrar eden CWE

izlenebilir.

Security Debt gizli kaldığında zaman içerisinde ciddi risk birikimi oluşur.

### \35. Bulgu Yaşam Döngüsü

Kurumsal AppSec programında bütün bulgular ortak lifecycle kullanabilir.

Örneğin:

#### New

↓

#### Validated

↓

#### Assigned

↓

#### In Progress

↓

#### Fixed

↓

#### Retest

↓

#### Closed

Alternatif durumlar:

#### False Positive

#### Risk Accepted

#### Exception

şeklinde olabilir.

### \36. Merkezi Vulnerability Management

SAST, SCA, DAST ve pentest sonuçları farklı platformlardan gelebilir.

Büyük kurumlarda bütün sonuçların merkezi risk platformunda toplanması faydalıdır.

Bu yapı:

- duplicate bulguları birleştirebilir,
- severity normalize edebilir,
- owner atayabilir,
- SLA takip edebilir.

Böylece güvenlik verisi tek görünümde yönetilir.

### \37. Application Owner

Her uygulamanın bir sahibi bulunmalıdır.

Uygulama sahibi şu konularda sorumluluk alabilir:

- business criticality,
- remediation,
- release riskleri,
- security backlog.

Owner bilgisi AppSec sistemine bağlanmalıdır.

Aksi halde bulgunun kime atanacağı belirsiz kalabilir.

### \38. Security Owner

Uygulama bazında veya ekip bazında Security Champion / Security Owner tanımlanabilir.

Bu kişi AppSec ekibiyle geliştirme ekibi arasında köprü kurar.

Özellikle kritik bulguların yorumlanmasını kolaylaştırır.

### \39. Security Champion Programı

Security Champion modeli kurumsal AppSec ölçeklenmesinde çok değerlidir.

Her geliştirme takımından bir veya birkaç teknik kişi güvenlik konusunda daha fazla eğitim alır.

Görevleri örneğin:

- security review desteği,
- bulgu triage,
- Secure Coding paylaşımı,
- AppSec iletişimi

olabilir.

### \40. Security Champion Programı Nasıl Başlatılır?

İlk aşamada gönüllü veya teknik olarak güçlü geliştiriciler seçilebilir.

Bu kişilere:

- OWASP,
- Secure Coding,
- Threat Modeling,
- SAST triage

eğitimleri verilebilir.

Düzenli AppSec toplantılarına dahil edilebilirler.

Ama Security Champion tam zamanlı güvenlik uzmanı haline getirilmemelidir.

### \41. AppSec Ekibinin Rolü

Merkezi AppSec ekibi genel olarak:

- policy,
- tool management,
- architecture guidance,
- critical review,
- pentest management,
- developer enablement,
- metrics

alanlarında çalışabilir.

Ama her güvenlik bulgusunun manuel takibini tek başına yapmak zorunda olmamalıdır.

Otomasyon ve Security Champion yapısı ölçek sağlamalıdır.

### \42. Development Ekibinin Rolü

Geliştirme ekipleri:

- Secure Coding standardına uymalı,
- otomatik güvenlik bulgularını değerlendirmeli,
- remediation yapmalı,
- gerekli durumlarda riskleri AppSec’e eskale etmelidir.

Güvenlik başka departmana devredilen bir görev olmamalıdır.

### \43. Platform Ekibinin Rolü

Platform Engineering ekibi güvenliği kolaylaştırabilir.

Örneğin:

- güvenli pipeline,
- secrets manager entegrasyonu,
- approved base image,
- standard auth library,
- logging framework

sunabilir.

Bu yapı geliştiricinin güvenli çözümü kendisi üretmek zorunda kalmasını azaltır.

### \44. Paved Road

Güvenli yöntem en kolay yöntem haline getirilmelidir.

Örneğin geliştirici yeni mikroservis oluştururken hazır template kullanır.

Template zaten:

- authentication,
- logging,
- SAST,
- SCA,
- container security

içerir.

Geliştirici güvenliği ayrıca düşünmek zorunda kalmaz.

Bu yaklaşım Paved Road olarak ifade edilebilir.

### \45. Security by Default

Kurumsal framework güvenli davranışı varsayılan hale getirmelidir.

Örneğin:

Yeni API endpoint default authenticated.

Yeni storage default private.

Yeni database encryption default enabled.

Yeni repository SAST default active.

Bu yaklaşım insan hatasını ciddi şekilde azaltır.

### \46. Security by Design

Security by Design güvenliğin sistem tasarımı sırasında ele alınmasını ifade eder.

Örneğin authentication sonradan eklenen özellik olmamalıdır.

Authorization mimarisi baştan tasarlanmalıdır.

Data classification uygulama başlamadan düşünülmelidir.

Bu yaklaşım Security by Default ile birlikte güçlüdür.

### \47. Secure Defaults ve Developer Productivity

Güvenli varsayılanlar aynı zamanda geliştirme hızını artırabilir.

Geliştiricinin her proje için sıfırdan:

- auth,
- logging,
- secrets,
- pipeline

tasarlaması gerekmez.

Güvenli yapı hazır gelir.

Bu nedenle güvenlik her zaman yavaşlatıcı değildir.

Doğru tasarlanırsa hızlandırıcı olabilir.

### \48. Application Security Tiering

Her uygulamaya aynı güvenlik seviyesi uygulanması maliyetli ve verimsiz olabilir.

Bu nedenle uygulamalar sınıflandırılabilir.

Örneğin:

#### Tier 1

Kritik müşteri / finans / internet-facing.

#### Tier 2

Önemli iş uygulamaları.

#### Tier 3

Standart internal uygulamalar.

#### Tier 4

Düşük riskli yardımcı sistemler.

Her tier için farklı güvenlik kontrolleri tanımlanabilir.

### \49. Tier 1 Kontrolleri

Örneğin Tier 1 uygulamada:

- Threat Modeling
- Secure Coding
- SAST
- SCA
- Secret Scanning
- DAST
- Manuel Code Review
- Pentest
- SBOM

zorunlu olabilir.

Bu sadece örnektir.

Kurumun risk yapısına göre şekillendirilmelidir.

### \50. Tier 2 Kontrolleri

Tier 2 için:

- SAST
- SCA
- Secret Scanning
- periyodik DAST
- risk bazlı pentest

uygulanabilir.

Manuel review yalnızca kritik değişikliklerde yapılabilir.

### \51. Tier 3 ve Tier 4

Daha düşük riskli uygulamalarda minimum baseline uygulanabilir.

Örneğin:

- SAST
- SCA
- Secret Scanning

gibi temel otomatik kontroller yeterli olabilir.

Ama hiçbir uygulama tamamen güvenlik kontrolü dışında bırakılmamalıdır.

### \52. Risk-Based AppSec Nedir?

Risk-Based AppSec bütün uygulamalara eşit güvenlik kaynağı harcamak yerine en kritik varlıklara daha yüksek güvenlik derinliği uygulamayı hedefler.

Bu yaklaşım AppSec ekibinin sınırlı kaynaklarını daha verimli kullanmasını sağlar.

Pentest uzmanı internal demo uygulaması yerine kritik ödeme sistemine daha fazla zaman ayırabilir.

### \53. AppSec Envanteri

Kurumsal programın temeli uygulama envanteridir.

Kurum şu bilgileri bilmelidir:

- kaç uygulama var,
- owner kim,
- teknoloji stack ne,
- internet-facing mi,
- hangi veriyi işliyor,
- business criticality ne,
- son pentest ne zaman.

Bu bilgi yoksa güvenlik kapsamını yönetmek zordur.

### \54. Shadow Application Problemi

Merkezi envanterde olmayan uygulamalar güvenlik kontrollerinden kaçabilir.

Örneğin küçük bir ekip internal tool geliştirir.

Sonra araç müşteri verisi işlemeye başlar.

Ancak AppSec sistemine hiç dahil olmamıştır.

Bu nedenle repository discovery ve cloud inventory ile shadow application’lar tespit edilebilir.

### \55. Repository Discovery

Git organizasyonundaki bütün repository’ler taranabilir.

Örneğin:

- active repository,
- archived repository,
- owner,
- language,
- last commit

bilgileri çıkarılabilir.

Böylece AppSec kapsamı daha doğru belirlenir.

### \56. Criticality Scoring

Application criticality şu faktörlere göre belirlenebilir:

- internet exposure,
- data sensitivity,
- transaction value,
- user count,
- regulatory impact,
- business dependency.

Bu skorlama AppSec kontrol seviyesini belirlemeye yardımcı olur.

### \57. Data Classification ile AppSec İlişkisi

Bir uygulamanın hangi veriyi işlediği güvenlik seviyesini belirler.

Örneğin public içerik sunan site ile kişisel sağlık verisi işleyen sistem aynı riskte değildir.

Data Classification AppSec tiering modeline girdi sağlayabilir.

### \58. Regulatory Context

Bazı uygulamalar regülasyon veya müşteri güvenlik gereksinimlerine tabi olabilir.

Bu durum:

- pentest sıklığı,
- güvenlik kanıtları,
- code review,
- logging,
- SBOM

gibi kontrolleri etkileyebilir.

Bu nedenle GRC ve AppSec ekipleri birlikte çalışmalıdır.

### \59. OWASP ASVS Kullanımı

OWASP ASVS Application Security Verification Standard, kurumsal güvenlik gereksinimlerini yapılandırmak için kullanılabilir.

Authentication,

Authorization,

Session Management,

Validation,

Cryptography

gibi alanlarda kontrol gereksinimleri sunar.

ASVS Secure SDLC için güçlü referans olabilir.

### \60. CWE Kullanımı

CWE bulguların teknik zayıflık türlerini standardize eder.

Kurumsal programda CWE mapping sayesinde tekrar eden güvenlik hataları analiz edilebilir.

Örneğin en sık bulunan üç CWE:

- Authorization
- XSS
- Hard-coded Credential

olabilir.

Bu bilgi eğitim ve platform yatırımlarını yönlendirebilir.

### \61. OWASP Top 10 Kullanımı

OWASP Top 10 yönetim ve farkındalık için güçlü referanstır.

Ancak AppSec programının bütün teknik kontrollerini yalnızca Top 10 ile sınırlandırmak doğru değildir.

CWE,

ASVS,

kurumsal Secure Coding Standardı

ile birlikte değerlendirilmelidir.

### \62. AppSec Metrikleri

Ölçülmeyen program geliştirilemez.

Kurumsal AppSec programında birçok metrik kullanılabilir.

Örneğin:

- Security Coverage
- Open Critical Findings
- MTTR
- Security Debt
- Finding Recurrence
- Vulnerability Escape Rate
- Pentest Coverage
- SAST Coverage
- SCA Coverage
- Secret Leak Rate

Ancak metrikler doğru yorumlanmalıdır.

### \63. SAST Coverage

Kaç aktif repository SAST ile korunuyor?

Örneğin:

**180 / 200 = %90**

Bu yüksek görünürlük gösterebilir.

Ancak kalan %10 kritik uygulamalarsa risk devam eder.

Bu nedenle coverage sayı kadar criticality ile birlikte okunmalıdır.

### \64. SCA Coverage

Kaç uygulamanın dependency güvenliği izleniyor?

SCA kapsamı düşükse supply chain riski görünmez kalabilir.

Hedef özellikle production uygulamalarda yüksek coverage olmalıdır.

### \65. Secret Leak Rate

Kaç yeni secret repository’ye girdi?

Kaçı push protection tarafından engellendi?

Zaman içerisinde secret leak oranının azalması geliştirici farkındalığının arttığını gösterebilir.

### \66. Vulnerability Escape Rate

Geliştirme ve test süreçlerinde yakalanamayıp production’a ulaşan güvenlik açıklarının oranıdır.

Amaç zaman içerisinde bu oranı düşürmektir.

Bu AppSec programının gerçek etkinliğini gösteren önemli metriklerden biridir.

### \67. Mean Time to Remediate

MTTR bulgunun tespitinden kapatılmasına kadar geçen ortalama süredir.

Critical ve High bulgularda zaman içerisinde düşmesi beklenir.

Ancak yalnızca ortalama değil overdue bulgu oranı da izlenmelidir.

### \68. Recurrence Rate

Aynı tür güvenlik açığının tekrar oluşma oranı önemli olgunluk göstergesidir.

Örneğin SQL Injection azalıyorsa Secure Coding ve SAST kontrolü etkili olabilir.

Authorization problemleri artıyorsa daha fazla manuel ve mimari çalışma gerekebilir.

### \69. Security Debt

Security Debt trendi yönetim için kritik metriktir.

Toplam açık sayısı sürekli artıyorsa remediation kapasitesi yeterli değildir.

Yeni bulgu üretim hızı kapanma hızını geçmektedir.

Bu durumda engineering roadmap’e security capacity eklenmesi gerekebilir.

### \70. Security KPI mı KRI mı?

Bazı metrikler performans göstergesi, bazıları risk göstergesi olarak kullanılabilir.

Örneğin:

**SAST Coverage → KPI**

**Open Critical Findings → KRI**

olarak düşünülebilir.

Bu ayrım yönetim raporlamasını daha anlamlı hale getirir.

### \71. Developer’ı Bulgu Sayısıyla Ölçmek Doğru mu?

Genellikle risklidir.

Geliştiricileri:

**“Kim daha az güvenlik açığı üretti?”**

şeklinde bireysel skorlamak güvenlik bulgularının saklanmasına veya yanlış teşviklere neden olabilir.

Daha iyi yaklaşım takım ve süreç olgunluğunu ölçmektir.

Amaç cezalandırmak değil öğrenmektir.

### \72. Security Culture

Güvenlik kültürü, geliştiricinin açığı saklamak yerine rahatlıkla güvenlik ekibine bildirebildiği ortamdır.

Hataların bulunması normaldir.

Önemli olan aynı hatadan öğrenmektir.

Bu nedenle AppSec ekibi “security police” algısından uzak durmalıdır.

### \73. Güvenlik Ekibi Geliştiricinin Karşısında mı Olmalı?

Hayır.

Başarılı AppSec programında güvenlik ekibi:

**enabler**

rolündedir.

Geliştiriciye:

- güvenli kütüphane,
- hazır pipeline,
- code example,
- hızlı danışmanlık

sağlar.

Ama gerektiğinde kritik risklerde kontrol ve bloklama yetkisi de bulunabilir.

### \74. Developer Self-Service Security

Geliştiricinin güvenlik ekibine ticket açmadan birçok işlemi yapabilmesi faydalıdır.

Örneğin portal üzerinden:

- SAST sonucu,
- remediation guide,
- approved library,
- secret management rehberi

görülebilir.

Bu AppSec ekibinin ölçeklenmesini kolaylaştırır.

### \75. AppSec Knowledge Base

Kurum içi bilgi merkezi oluşturulabilir.

Örneğin:

#### SQL Injection Nasıl Düzeltilir?

#### JWT Güvenliği

#### Secure File Upload

#### Spring Authorization

gibi içerikler hazırlanabilir.

Böylece güvenlik bilgisi kurumsallaşır.

### \76. Just-in-Time Guidance

Geliştirici SAST bulgusu aldığında doğrudan ilgili kurumsal güvenlik rehberine yönlendirilebilir.

Örneğin:

**CWE-89 → Kurumsal SQL Security Standardı**

Bu yaklaşım eğitim ile operasyonu birleştirir.

### \77. Secure Coding Eğitimleri

Yıllık genel eğitim yerine teknoloji ve bulgu trendlerine göre özel eğitimler daha etkili olabilir.

Örneğin kurumda en fazla authorization problemi varsa:

#### Secure API Authorization

eğitimi düzenlenebilir.

Gerçek kurum bulguları anonimleştirilerek örnek kullanılabilir.

### \78. Hands-On Eğitim

Güvenli kodlama eğitimleri yalnızca sunumdan oluşmamalıdır.

Geliştiriciler:

- zafiyetli kodu,
- exploit mantığını,
- güvenli fix’i

uygulamalı görebilir.

Bu yöntem farkındalığı ciddi şekilde artırır.

### \79. Security Champion Eğitimi

Security Champion’lara daha ileri seviye eğitim verilebilir.

Örneğin:

- Threat Modeling
- SAST Triage
- OWASP ASVS
- API Security
- Security Architecture

konularında eğitim sağlanabilir.

### \80. AppSec Office Hours

Güvenlik ekibi belirli zamanlarda developer’lara açık danışmanlık saati düzenleyebilir.

Geliştirici:

“Bu authentication mimarisi güvenli mi?”

sorusunu proje sonunda değil tasarım aşamasında sorabilir.

Bu ciddi Shift Left avantajı sağlar.

### \81. Pre-Release Security Review

Kritik release öncesinde otomatik test sonuçları tek yerde değerlendirilir.

Örneğin:

SAST → Passed

SCA → Accepted

Secret Scan → Passed

DAST → Passed

Pentest → Closed Critical/High

Sonrasında release onayı verilebilir.

### \82. Security Sign-Off Gerekli midir?

Her uygulamada olmayabilir.

Kritik sistemlerde risk bazlı security sign-off uygulanabilir.

Ama security team her release’in manuel bottleneck’i olmamalıdır.

Mümkün olduğunca kontroller otomatik olmalıdır.

Manuel sign-off yalnızca yüksek riskli durumlarda kullanılmalıdır.

### \83. Continuous AppSec

Olgun modelde güvenlik tek seferlik scan değildir.

Kod değiştikçe SAST çalışır.

Dependency değiştikçe SCA çalışır.

Yeni CVE çıktığında uygulamalar yeniden değerlendirilir.

Secret push sırasında engellenir.

DAST periyodik çalışır.

Pentest kritik release’lerde yapılır.

Bu yaklaşım **Continuous Application Security** olarak düşünülebilir.

### \84. Continuous Monitoring

Production güvenliği de AppSec programının parçasıdır.

Örneğin:

- WAF,
- application log,
- SIEM,
- anomaly detection,
- runtime security

kullanılabilir.

Shift Left production güvenliğinin yerine geçmez.

### \85. Production Bulguları Development’a Geri Beslenmeli mi?

Evet.

Örneğin SOC bir saldırı pattern’i görür.

AppSec ekibi ilgili kod zayıflığını analiz eder.

Secure Coding standardı güncellenir.

Custom SAST rule oluşturulur.

Bu feedback loop çok değerlidir.

### \86. Incident to Prevention

Güvenlik olayı yalnızca incident response ile kapanmamalıdır.

Örneğin production’da credential exposure yaşandı.

Sonrasında:

- Secret Scanning,
- Push Protection,
- Vault migration,
- developer training

uygulanabilir.

Böylece incident gelecekteki riski azaltır.

### \87. Red Team Bulguları AppSec’e Beslenebilir mi?

Evet.

Red Team uygulama seviyesinde zayıflık veya credential kullanımı keşfedebilir.

Bu bulgu Secure SDLC kontrolüne dönüştürülebilir.

Red Team ile AppSec arasında bilgi paylaşımı olgun güvenlik programının önemli özelliğidir.

### \88. Bug Bounty Bulguları

Bug Bounty programı bulunan kurumlarda dış araştırmacıların bulguları da AppSec Knowledge Base’e beslenebilir.

Örneğin yeni bir authorization bypass pattern’i bulunur.

Benzer bütün uygulamalar taranabilir.

### \89. Security Intelligence Loop

Olgun model şöyle çalışır:

#### Pentest / Incident / Bug Bounty / Red Team

↓

#### Yeni Güvenlik Bilgisi

↓

#### Secure Coding Standardı

↓

#### SAST / DAST Rule

↓

#### Developer Training

↓

#### Prevention

Bu döngü kurumun güvenlik bilgisini sürekli büyütür.

### \90. Kurumsal AppSec Programı Nasıl Başlatılır?

Her şeyi aynı anda yapmak gerekmez.

Aşamalı yaklaşım daha sürdürülebilirdir.

#### Faz 1 – Görünürlük

Application Inventory

Pentest

Baseline SAST

SCA

#### Faz 2 – Standardizasyon

Secure Coding

Risk Model

Finding Lifecycle

#### Faz 3 – Otomasyon

CI/CD Integration

Secret Scanning

Quality Gate

#### Faz 4 – Ölçekleme

Security Champions

Golden Pipeline

Central AppSec Platform

#### Faz 5 – Olgunluk

Threat Modeling

Metrics

Continuous AppSec

Bu yapı kurumun ihtiyaçlarına göre uyarlanmalıdır.

### \91. İlk Adım: Envanter

Neyi koruduğunuzu bilmiyorsanız güvenlik programı kuramazsınız.

İlk olarak:

- uygulamalar,
- repository’ler,
- owner’lar,
- teknoloji stack,
- criticality

belirlenmelidir.

Bu AppSec programının temel veri setidir.

### \92. İkinci Adım: Baseline

Mevcut güvenlik durumunu anlamak gerekir.

Örneğin kritik uygulamalarda:

- pentest,
- SAST,
- SCA,
- secret scan

çalıştırılabilir.

Bu ilk Security Debt görünürlüğünü sağlar.

### \93. Üçüncü Adım: Standardizasyon

Bulgular ortak risk modeli altında yönetilmelidir.

Secure Coding standardı oluşturulmalıdır.

Developer workflow tanımlanmalıdır.

Kimin ne yapacağı net olmalıdır.

### \94. Dördüncü Adım: Otomasyon

Sık yapılan kontroller CI/CD içerisine taşınmalıdır.

Örneğin:

- SAST,
- SCA,
- Secret Scan

otomatik hale getirilebilir.

Bu manuel güvenlik yükünü azaltır.

### \95. Beşinci Adım: Risk-Based Quality Gate

Bütün bulgulara değil kritik risklere otomatik blok uygulanabilir.

Bu noktada AppSec artık release sürecinin teknik parçası olur.

### \96. Altıncı Adım: Ölçüm

Program için KPI ve KRI belirlenir.

Örneğin:

- SAST Coverage,
- MTTR,
- Open Critical,
- Recurrence Rate,
- Security Debt.

Zaman içerisinde gelişim ölçülür.

### \97. Yedinci Adım: Sürekli İyileştirme

Pentest ve incident bulguları süreçlere geri beslenir.

Yeni rule’lar oluşturulur.

Eğitimler güncellenir.

Platform standartları geliştirilir.

Program yaşayan yapıya dönüşür.

### \98. AppSec Programının Başarısız Olma Nedenleri

En yaygın nedenlerden bazıları:

- yalnızca tool satın almak,
- geliştiriciyi sürece dahil etmemek,
- çok fazla False Positive,
- her şeyi build blocker yapmak,
- owner tanımlamamak,
- bulguları PDF’de bırakmak,
- ölçüm yapmamak.

Başarılı program araç değil süreç odaklıdır.

### \99. “Security Police” Modelinin Problemi

Güvenlik ekibi yalnızca:

**Hayır.**

**Release olmaz.**

**Bu açık.**

diyorsa development ile çatışma oluşabilir.

Daha iyi yaklaşım:

#### Neden risk?

#### Nasıl düzeltilebilir?

#### Güvenli yolu nasıl kolaylaştırabiliriz?

sorularına odaklanmaktır.

### \100. Güvenlik Geliştirmenin Parçası Olmalı

En olgun seviyede geliştirici güvenlik kontrolünü dış bir zorunluluk gibi görmez.

Kod kalitesi gibi değerlendirir.

Örneğin unit test’in fail olması normal kabul edilir.

SAST gate’in fail olması da benzer şekilde normal development feedback haline gelir.

Bu kültürel değişim Secure SDLC’nin en önemli hedeflerinden biridir.

### SecureSys Kurumsal Kod Güvenliği ve Secure SDLC Yaklaşımı

SecureSys olarak kaynak kod analizini tek başına bir güvenlik hizmeti olarak değil, daha geniş bir **Application Security ve Secure SDLC** yaklaşımının bileşeni olarak değerlendiriyoruz.

Bir uygulamada kaynak kod analizi gerçekleştirmek mevcut güvenlik açıklarını görünür hale getirebilir.

Ancak sürdürülebilir güvenlik için yalnızca mevcut açıkları bulmak yeterli değildir.

Asıl hedef:

**bu açıkların neden oluştuğunu anlamak ve gelecekte tekrar oluşma ihtimalini azaltmaktır.**

Bu nedenle proje ve kurumun olgunluk seviyesine göre aşağıdaki katmanlar birlikte ele alınabilir:

#### Threat Modeling

↓

#### Secure Coding

↓

#### SAST

↓

#### SCA

↓

#### Secret Scanning

↓

#### DevSecOps / CI-CD Security

↓

#### DAST / API Security

↓

#### Manuel Kaynak Kod Analizi

↓

#### Pentest

↓

#### Remediation ve Retest

↓

#### Continuous AppSec

Bu yaklaşım ile güvenlik yalnızca release öncesi yapılan bir kontrol olmaktan çıkar.

Yazılım geliştirme yaşam döngüsünün tamamına yayılır.

Aynı zamanda bütün uygulamalara aynı güvenlik yükünü uygulamak yerine Risk-Based AppSec modeli kullanılabilir.

Kritik finansal veya internet-facing uygulamalar daha derin:

- Threat Modeling,
- Manuel Code Review,
- Pentest

kontrollerine tabi tutulabilir.

Daha düşük riskli uygulamalarda otomatik SAST, SCA ve Secret Scanning baseline güvenliği sağlayabilir.

Programın uzun vadeli başarısı için teknoloji kadar insan ve süreç de önemlidir.

Bu nedenle:

#### Security Champion

#### Secure Coding Training

#### Developer Security Guidance

#### Finding Management

#### Security Metrics

yapıları da kurumsal modele dahil edilmelidir.

Hedef çok sayıda güvenlik ürünü kullanmak değildir.

Hedef:

**doğru güvenlik kontrolünü doğru uygulamaya, doğru zamanda ve doğru derinlikte uygulamaktır.**

### SecureSys Yaklaşımında Önerilen Kod Güvenliği Yaşam Döngüsü

Örnek kurumsal model şu şekilde kurgulanabilir:

#### \1. Uygulama Envanteri

Tüm aktif uygulamalar ve repository’ler belirlenir.

#### \2. Kritiklik Sınıflandırması

Business criticality, internet exposure ve data sensitivity değerlendirilir.

#### \3. Secure Coding Baseline

Geliştirme ekipleri için ortak güvenlik standartları oluşturulur.

#### \4. Otomatik Kod Güvenliği

SAST, SCA ve Secret Scanning devreye alınır.

#### \5. DevSecOps

Kontroller CI/CD pipeline’ına entegre edilir.

#### \6. Kritik Uygulama Analizi

Manuel code review ve pentest uygulanır.

#### \7. Bulgu Yönetimi

Risk bazlı remediation ve SLA süreçleri işletilir.

#### \8. Retest

Critical ve High bulgular doğrulanır.

#### \9. Kurumsal Öğrenme

Tekrar eden CWE ve root cause’lar analiz edilir.

#### \10. Prevention

Yeni SAST rule, Secure Coding standardı veya platform kontrolü oluşturulur.

Bu döngü tekrar ettikçe güvenlik olgunluğu artar.

### Sık Sorulan Sorular

#### Secure SDLC nedir?

Secure SDLC, güvenliğin yazılım geliştirme yaşam döngüsünün planlama, tasarım, geliştirme, test, release ve production aşamalarının tamamına entegre edilmesidir.

#### Application Security Programı nedir?

Kurumun uygulama güvenliği risklerini sürekli olarak yönetmek için oluşturduğu politika, süreç, teknoloji, insan ve ölçüm yapılarının tamamıdır.

#### Kaynak kod analizi Secure SDLC’nin neresindedir?

Kaynak kod analizi geliştirme ve test aşamalarında kritik rol oynar ancak Threat Modeling, Secure Coding, SCA, DAST ve pentest gibi diğer kontrollerle birlikte kullanılmalıdır.

#### Her uygulamaya aynı güvenlik kontrolü uygulanmalı mı?

Hayır. Risk-Based AppSec yaklaşımıyla uygulamanın kritikliği, işlediği veri ve internet exposure seviyesine göre farklı güvenlik derinlikleri uygulanabilir.

#### Security Champion nedir?

Geliştirme ekibi içerisinde güvenlik konusunda ek sorumluluk ve eğitim alan, AppSec ekibiyle geliştiriciler arasında köprü görevi gören teknik ekip üyesidir.

#### Secure Coding Standardı neden gereklidir?

Geliştiricilerin tekrar eden güvenlik hatalarını azaltmak için ortak güvenli kodlama kuralları sunar.

#### SAST, SCA ve Secret Scanning yeterli midir?

Temel otomatik kod güvenliği için güçlü bir başlangıçtır ancak kritik uygulamalarda manuel code review, DAST, API Security ve pentest gibi ek kontroller gerekebilir.

#### DevSecOps ile Secure SDLC aynı şey midir?

Hayır. DevSecOps özellikle güvenlik kontrollerinin DevOps ve CI/CD süreçlerine entegrasyonuna odaklanır. Secure SDLC yazılım yaşam döngüsünün daha geniş kısmını kapsar.

#### Application Security nasıl ölçülür?

SAST/SCA coverage, MTTR, açık Critical bulgu sayısı, Security Debt, Recurrence Rate ve Vulnerability Escape Rate gibi metrikler kullanılabilir.

#### İyi AppSec programının temel hedefi nedir?

Yalnızca daha fazla güvenlik açığı bulmak değil, güvenlik açıklarını daha erken tespit etmek ve aynı tür zafiyetlerin tekrar oluşmasını azaltmaktır.

### Sonuç: Güvenli Yazılım Bir Test Sonucu Değil, Kurumsal Yetkinliktir

Bu serinin başında basit bir soruyla yola çıktık:

#### Kaynak Kod Analizi nedir?

Ancak yolculuk ilerledikçe gördük ki kaynak kod güvenliği tek bir tarama işleminden çok daha fazlasıdır.

Kod içerisinde güvenlik açığı oluşabilir.

SAST bu açığı erken tespit edebilir.

Ancak SAST her şeyi göremez.

Manuel analiz business logic’i değerlendirebilir.

SCA açık kaynak dependency’lerin risklerini görünür hale getirir.

Secret Scanning kod içerisinde unutulan credential’ları tespit eder.

DAST çalışan uygulamanın davranışını test eder.

Pentest gerçek saldırgan perspektifi sağlar.

DevSecOps bütün bu kontrollerin önemli bölümünü yazılım geliştirme sürecine taşır.

Remediation süreci bulguların gerçekten kapanmasını sağlar.

Security Champion modeli güvenlik bilgisini geliştirme ekiplerinin içerisine yayar.

Secure SDLC ise bütün parçaları tek bir yaşam döngüsünde birleştirir.

Sonuçta ortaya çıkan yapı yalnızca bir kaynak kod analizi hizmeti değildir.

**Kurumsal yazılım güvenliği yetkinliğidir.**

Olgun bir organizasyonda güvenlik ekibi release’in sonunda ortaya çıkıp:

**“Bu uygulama güvenli mi?”**

diye sormaz.

Güvenlik proje başladığı anda masadadır.

Mimari tasarlanırken vardır.

Kod yazılırken vardır.

Pull Request açılırken vardır.

Build oluşturulurken vardır.

Production’a çıkarken vardır.

Ve uygulama çalışırken de devam eder.

İşte Secure SDLC’nin gerçek anlamı budur.

Güvenliği yazılım geliştirme sürecinin sonuna eklemek değil;

**yazılım geliştirme sürecinin kendisini güvenli hale getirmek.**

Bu nedenle kaynak kod güvenliği yolculuğunun son cümlesi aslında ilk bölümdeki ana mesajımıza geri dönmektedir:

**Güvenlik production ortamında başlamaz.**

**Güvenlik ilk kod satırıyla başlar.**

Ve kurumsal olgunluk seviyesinde buna bir cümle daha eklemek gerekir:

**Güvenli kod bir geliştiricinin bireysel başarısı değil, kurumun oluşturduğu güvenli yazılım geliştirme sisteminin sonucudur.**