Kaynak Kod Analizi Nasıl Yapılır? Metodoloji, Araçlar ve Raporlama

Kapsam belirlemeden retest'e: profesyonel kaynak kod analizinin adım adım metodolojisi, araç seçimi ve raporlama standardı.

Kaynak kod analizi, dışarıdan bakıldığında çoğu zaman basit bir işlem gibi görülebilir.

Kod alınır.

Bir SAST aracı çalıştırılır.

Bulgu listesi oluşturulur.

Rapor hazırlanır.

Ancak profesyonel bir kaynak kod güvenlik analizi bundan çok daha kapsamlıdır.

Çünkü gerçek amaç yalnızca araç çıktısı üretmek değildir.

Asıl amaç:

uygulamanın kaynak kodu içerisindeki gerçek, istismar edilebilir ve iş açısından anlamlı güvenlik risklerini ortaya çıkarmaktır.

Bunu yapabilmek için analiz sürecinin doğru planlanması gerekir.

Hangi repository'lerin inceleneceği,

hangi branch'in kullanılacağı,

hangi teknolojilerin bulunduğu,

uygulamanın mimarisinin nasıl çalıştığı,

hangi modüllerin kritik olduğu,

hangi kullanıcı rollerinin bulunduğu,

hangi dış servislerle entegrasyon yapıldığı

analizin sonucunu doğrudan etkiler.

Aynı şekilde yalnızca otomatik araç kullanılması da yeterli olmayabilir.

Otomatik SAST analizi geniş bir kod tabanını hızlı şekilde tarayabilir.

Ancak authentication, authorization, business logic, kriptografi ve kritik işlem akışları gibi alanlarda manuel kaynak kod analizi gerekebilir.

Bu nedenle profesyonel kaynak kod analizi genellikle birkaç farklı güvenlik katmanının birleşiminden oluşur:

Kapsam Belirleme → Mimari Analiz → Otomatik SAST → Manuel Kod İncelemesi → Bulgu Doğrulama → Risk Derecelendirme → Raporlama → Remediation → Retest

Bu bölümde kaynak kod analizinin başından sonuna nasıl yürütülmesi gerektiğini adım adım ele alacağız.

1. Kaynak Kod Analizi Projesi Nereden Başlar?

İlk aşama kodu taramak değil, kapsamı anlamaktır.

Bir güvenlik analizi başlamadan önce şu soruların cevaplanması gerekir:

Hangi uygulama analiz edilecek?
Hangi repository'ler kapsamda?
Hangi branch veya tag incelenecek?
Production ile analiz edilen kod aynı mı?
Kullanılan programlama dilleri neler?
Hangi framework'ler kullanılıyor?
Uygulamanın kritik modülleri hangileri?
Hangi kullanıcı rolleri bulunuyor?
Uygulama hangi veri türlerini işliyor?
Hangi harici sistemlerle entegrasyon yapıyor?
Uygulama internet-facing mi?

Bu bilgiler yalnızca proje yönetimi için değildir.

Güvenlik testinin derinliğini ve önceliklerini de belirler.

Örneğin ödeme sistemi ile basit bir kurumsal portal aynı güvenlik profiline sahip değildir.

Dolayısıyla aynı metodoloji birebir uygulanmamalıdır.

2. Scope Nedir?

Scope, güvenlik analizinin hangi sistem ve bileşenleri kapsayacağını tanımlar.

Kaynak kod analizi açısından scope şu bileşenleri içerebilir:

Backend repository
Frontend repository
Mobil uygulama
API servisleri
Microservice repository'leri
Shared library'ler
Authentication servisi
Infrastructure as Code
CI/CD configuration
Config dosyaları

Scope ne kadar açık tanımlanırsa analiz o kadar sağlıklı yürütülür.

Belirsiz scope hem güvenlik ekibi hem de geliştirme ekibi açısından yanlış beklenti oluşturabilir.

3. Hangi Branch Analiz Edilmelidir?

Bu önemli ancak sık gözden kaçan bir konudur.

Bir repository'de farklı branch'ler bulunabilir.

Örneğin:

main
develop
release
feature
hotfix

Analiz edilen kodun production ortamında çalışan kodla eşleşmesi önemlidir.

Aksi halde analiz sonucunda bulunan veya bulunmayan açıklar gerçek production durumunu yansıtmayabilir.

Bu nedenle mümkünse:

Release Tag

veya production ile eşleşen commit hash kullanılmalıdır.

Bu bilgi raporda da açık şekilde belirtilmelidir.

4. Commit Hash Neden Kaydedilmelidir?

Kaynak kod sürekli değişir.

Bugün analiz edilen kod yarın farklı olabilir.

Bu nedenle analiz sırasında hangi kod versiyonunun incelendiği kayıt altına alınmalıdır.

Örneğin:

Repository: Payment API

Branch: release/3.2

Commit: a13f72c...

şeklinde bilgi tutulabilir.

Böylece retest sırasında hangi değişikliklerin yapıldığı daha doğru takip edilir.

5. Kaynak Kod Güvenli Şekilde Nasıl Paylaşılmalıdır?

Kaynak kod kurumların en değerli fikri mülkiyet varlıklarından biridir.

Bu nedenle kod paylaşımı güvenlik açısından dikkatli yürütülmelidir.

Mümkünse doğrudan:

kontrollü Git erişimi,
VPN,
kurum içi repository,
güvenli geçici erişim

kullanılmalıdır.

Kaynak kodun açık e-posta eki olarak paylaşılması ideal değildir.

Analiz bittikten sonra kodun nasıl saklanacağı ve ne zaman silineceği de önceden belirlenmelidir.

6. Kaynak Kod Gizliliği Neden Önemlidir?

Kaynak kod yalnızca uygulamanın nasıl çalıştığını göstermez.

Aynı zamanda:

iş mantığını,
altyapı isimlerini,
API endpoint'lerini,
güvenlik kontrollerini,
entegrasyon yapılarını

ortaya çıkarabilir.

Bu nedenle kaynak kod analizi hizmetinde gizlilik sözleşmesi ve erişim kontrolü önemlidir.

Özellikle savunma, finans, kamu ve kritik altyapı projelerinde kaynak kodun dış sisteme yüklenip yüklenmediği de sorgulanmalıdır.

7. Cloud SAST mı On-Premise SAST mı?

SAST çözümü seçerken deployment modeli önemlidir.

Cloud SAST çözümünde kaynak kod veya koddan türetilmiş veriler hizmet sağlayıcının altyapısına gönderilebilir.

On-premise çözümde analiz kurumun kendi ortamında gerçekleştirilebilir.

Kritik projelerde şu sorular sorulmalıdır:

Kod kurum dışına çıkıyor mu?
Analiz verisi nerede tutuluyor?
Sağlayıcı kodu saklıyor mu?
Retention süresi nedir?
Hangi ülke veya region kullanılıyor?
Data residency gereksinimi var mı?

Teknik özellik kadar veri güvenliği modeli de değerlendirilmelidir.

8. Teknoloji Envanteri Çıkarılması

Analizin ilk teknik aşamalarından biri teknoloji stack'inin belirlenmesidir.

Örneğin:

Backend: Java / Spring Boot

Frontend: React / TypeScript

Database: PostgreSQL

Authentication: OAuth 2.0 / JWT

Build: Maven

CI/CD: GitLab CI

gibi bir teknoloji haritası oluşturulabilir.

Bu bilgi hangi SAST kurallarının kullanılacağını ve manuel analizde hangi güvenlik risklerine öncelik verileceğini belirler.

9. Framework Bilgisi Neden Önemlidir?

Aynı programlama dili farklı framework'lerde farklı güvenlik davranışlarına sahip olabilir.

Örneğin Java uygulamasında Spring Security kullanılıyor olabilir.

Yetkilendirme annotation'larla uygulanabilir.

Başka Java uygulamasında özel authentication framework'ü bulunabilir.

Bu iki uygulamanın security code review yöntemi aynı değildir.

SAST aracının framework'ü doğru anlaması False Positive oranını da ciddi şekilde etkiler.

10. Mimari Analiz

Kaynak kod analizi başlamadan önce uygulamanın mimarisi anlaşılmalıdır.

Örneğin monolith mi?

Microservice mi?

API gateway var mı?

Authentication merkezi mi?

Servisler birbirleriyle nasıl iletişim kuruyor?

Database erişimi hangi katmandan yapılıyor?

Bu bilgi güvenlik açısından kritik veri akışlarını anlamaya yardımcı olur.

11. Data Flow Diagram Kullanılabilir mi?

Evet.

Özellikle karmaşık sistemlerde Data Flow Diagram oldukça faydalıdır.

Örneğin:

User

↓

Web Application

↓

API Gateway

↓

Payment Service

↓

Database

şeklinde veri akışı çizilebilir.

Ardından Trust Boundary noktaları belirlenebilir.

Bu yaklaşım manuel kod analizinin daha risk bazlı yapılmasını sağlar.

12. Threat Modeling Kaynak Kod Analizini Güçlendirir mi?

Evet.

Kaynak kod analizi başlamadan önce temel Threat Modeling yapılması kritik bölgeleri görünür hale getirebilir.

Örneğin sistemde:

ödeme,
parola sıfırlama,
dosya yükleme,
admin işlemleri

yüksek riskli olabilir.

Bu fonksiyonlar manuel code review sırasında önceliklendirilebilir.

Böylece milyonlarca satır kod arasında daha etkili güvenlik analizi yapılır.

13. Asset Identification

Uygulamada korunması gereken kritik varlıklar belirlenmelidir.

Örneğin:

müşteri verileri,
kredi kartı bilgileri,
authentication token'ları,
finansal işlem kayıtları,
kişisel veriler,
encryption key'ler.

Bu varlıkların kod içerisinde nasıl işlendiği analiz edilir.

Temel soru:

Saldırgan hangi veriye ulaşmaya çalışır?

olmalıdır.

14. Entry Point Analizi

Saldırganın uygulamaya veri gönderebildiği noktalar belirlenir.

Örneğin:

HTTP GET
HTTP POST
API body
Header
Cookie
File Upload
Message Queue
WebSocket

gibi entry point'ler bulunabilir.

Bu noktalar manuel code review için güçlü başlangıç alanlarıdır.

15. Source Analizi

SAST perspektifinde entry point'ler çoğunlukla Source olarak değerlendirilir.

Kullanıcı kontrollü veri kod içerisinde takip edilir.

Amaç:

Bu veri hangi kritik fonksiyonlara ulaşabiliyor?

sorusunu cevaplamaktır.

Bu analiz Injection ve veri işleme problemlerinin tespitinde kritik öneme sahiptir.

16. Sink Analizi

Sink, güvenlik açısından kritik fonksiyonlardır.

Örneğin:

SQL execute
OS command execution
file read/write
HTTP request
HTML output
XML parser

gibi fonksiyonlar sink olabilir.

Kaynak kod analizinde bu fonksiyonların kullanıcı kontrollü verilerle ilişkisi değerlendirilir.

17. Source-to-Sink Analizi

Bir veri akışı örneği:

HTTP Parameter

↓

Controller

↓

Service

↓

Repository

↓

SQL Query

şeklinde olabilir.

Buradaki amaç kullanıcı girdisinin SQL sorgusuna ulaşmadan önce güvenli şekilde işlenip işlenmediğini anlamaktır.

SAST araçları bu analizi otomatik olarak gerçekleştirebilir.

Manuel uzman ise özellikle karmaşık veya özel framework yapılarında sonucu doğrular.

18. İlk SAST Taraması

Teknoloji stack belirlendikten sonra uygun SAST profiliyle ilk tarama gerçekleştirilebilir.

Bu ilk tarama genellikle baseline oluşturur.

Sonuçlarda yüzlerce veya binlerce bulgu çıkabilir.

Ancak bu çıktının tamamı gerçek zafiyet olarak kabul edilmemelidir.

İlk aşama ham güvenlik verisidir.

19. Baseline Scan Nedir?

Baseline Scan uygulamanın mevcut güvenlik durumunu ortaya koyan ilk kapsamlı taramadır.

Örneğin:

7 Critical
35 High
182 Medium
640 Low

bulgu görülebilir.

Bu sayı doğrudan müşteriye sunulmamalıdır.

Önce triage gerekir.

Çünkü önemli bölümü False Positive veya duplicate olabilir.

20. Tool Output Neden Nihai Rapor Değildir?

Bir SAST aracının ürettiği export dosyasını müşteriye rapor olarak sunmak profesyonel kaynak kod analizi değildir.

Araç sonuçları:

False Positive,
Duplicate,
Not Reachable,
Test Code,
Dead Code

içerebilir.

Dolayısıyla her bulgunun bağlam içerisinde değerlendirilmesi gerekir.

Bu aşamaya Security Triage denir.

21. Security Triage

Triage sırasında bulgular incelenir.

Her bulgu için şu sorular sorulabilir:

Veri gerçekten kullanıcı kontrollü mü?
Riskli kod gerçekten çalışıyor mu?
Production'da kullanılıyor mu?
Güvenlik kontrolü başka katmanda var mı?
Framework bu işlemi otomatik güvenli hale getiriyor mu?
Saldırgan bu noktaya ulaşabilir mi?

Bu süreç False Positive oranını ciddi şekilde düşürür.

22. Duplicate Bulgular

Aynı güvenlik problemi farklı veri akışlarında tekrar raporlanabilir.

Örneğin tek bir güvensiz helper fonksiyon 20 farklı endpoint tarafından çağrılıyor olabilir.

SAST bunu 20 ayrı bulgu olarak raporlayabilir.

Ancak kök neden tek bir fonksiyon olabilir.

Profesyonel raporda bu ilişki gösterilmelidir.

23. Root Cause Analysis

Kaynak kod analizinin en değerli aşamalarından biri kök neden analizidir.

Örneğin 15 SQL Injection bulgusu varsa hepsi aynı unsafe database helper'dan kaynaklanıyor olabilir.

Bu durumda tek tek 15 kod satırını düzeltmek yerine ortak helper güvenli hale getirilebilir.

Bu yaklaşım remediation maliyetini ciddi şekilde azaltır.

24. Manuel Kaynak Kod Analizi Ne Zaman Başlar?

SAST triage sonrasında veya paralel olarak manuel analiz gerçekleştirilebilir.

Manuel analiz özellikle yüksek riskli alanlara odaklanır.

Örneğin:

Authentication
Authorization
Payment
Admin functions
Cryptography
File upload
Password reset
Token management
External integrations

öncelikli olabilir.

25. Authentication Kod Analizi

Authentication kodu incelenirken şu alanlar değerlendirilebilir:

Login logic
Password hashing
Account lockout
MFA
Session creation
Token generation
Password reset
Logout
Token revocation

Bu alanlar kritik güvenlik fonksiyonlarıdır.

Küçük bir hata hesap ele geçirmeye kadar ilerleyebilir.

26. Authorization Analizi

Authorization code review manuel analizde en önemli alanlardan biridir.

Örneğin:

Bu kullanıcı bu kaynağa gerçekten erişebilir mi?

sorusu her kritik işlem için değerlendirilmelidir.

Yalnızca login kontrolü yeterli değildir.

Object-level ve function-level authorization birlikte incelenmelidir.

27. Role Matrix Kullanımı

Karmaşık uygulamalarda Role Matrix hazırlanabilir.

Örneğin:

Fonksiyon	User	Manager	Admin
Kendi profilini görme	Evet	Evet	Evet
Diğer kullanıcıyı görme	Hayır	Sınırlı	Evet
Kullanıcı silme	Hayır	Hayır	Evet

Manuel code review sırasında gerçek kod bu iş kuralıyla karşılaştırılır.

Böylece Broken Access Control problemleri daha kolay tespit edilir.

28. Business Logic Analizi

Business Logic otomatik araçların en fazla zorlandığı alanlardan biridir.

Örneğin:

indirim limiti,
ödeme sırası,
transfer limiti,
approval mekanizması,
rezervasyon kuralı

gibi iş kuralları kod içerisinde incelenebilir.

Burada güvenlik uzmanının uygulamanın işleyişini anlaması gerekir.

29. Financial Logic Review

Finansal işlem yapan uygulamalarda özellikle:

amount manipulation,
currency conversion,
transaction replay,
approval bypass,
negative value,
rounding error

gibi alanlar değerlendirilebilir.

Bu problemler klasik SAST kuralları tarafından her zaman bulunamaz.

30. Input Validation Review

Kullanıcı girdilerinin nasıl doğrulandığı incelenir.

Örneğin:

format,
length,
range,
allowed characters,
business constraint

kontrolleri değerlendirilebilir.

Ancak input validation her güvenlik probleminin ana çözümü değildir.

Örneğin SQL Injection için parameterized query yine gereklidir.

31. Output Encoding Review

Özellikle web uygulamalarında kullanıcı kontrollü verinin nasıl çıktıya verildiği incelenir.

HTML,

JavaScript,

URL,

CSS

farklı güvenlik bağlamlarına sahiptir.

Context-aware encoding uygulanmalıdır.

32. Database Security Review

Database erişim katmanında şu noktalar incelenebilir:

prepared statement,
raw query,
ORM unsafe function,
dynamic query,
excessive DB privilege,
credential management.

Ayrıca database error'larının kullanıcıya yansıyıp yansımadığı da kontrol edilebilir.

33. File Handling Review

Dosya işlemleri yüksek riskli alanlardandır.

Şu fonksiyonlar incelenebilir:

upload,
download,
delete,
archive extraction,
filename generation,
path construction.

Path Traversal ve unsafe upload gibi problemler burada ortaya çıkabilir.

34. SSRF Review

Sunucunun dış sisteme request gönderdiği fonksiyonlar incelenir.

Örneğin:

URL preview,
webhook,
image import,
PDF generation,
callback

gibi özellikler SSRF riski taşıyabilir.

Allowlist ve network restriction kontrolleri değerlendirilir.

35. Cryptography Review

Kriptografi analizi yalnızca hangi algoritmanın kullanıldığını kontrol etmek değildir.

Şu alanların tamamı önemlidir:

algorithm,
key size,
key storage,
IV,
random generation,
password hashing,
signing.

Özellikle hard-coded key kullanımı kritik risk olabilir.

36. Random Number Review

Güvenlik açısından kritik token'lar için cryptographically secure random number generator kullanılmalıdır.

Örneğin:

password reset token,
session ID,
verification code,
API token

normal pseudo-random fonksiyonla üretilmemelidir.

37. Logging Review

Loglama hem güvenlik kontrolü hem veri sızıntısı kaynağı olabilir.

Şunlar incelenebilir:

password loglanıyor mu?
token loglanıyor mu?
PII açık şekilde loglanıyor mu?
failed login loglanıyor mu?
admin action audit ediliyor mu?

İyi logging doğru olayları kaydeder ancak secret veya hassas veriyi ifşa etmez.

38. Error Handling Review

Detaylı stack trace production'da kullanıcıya gösteriliyorsa bilgi ifşası oluşabilir.

Manuel analizde exception handling yapısı kontrol edilir.

Örneğin:

generic error response,
secure internal logging,
exception sanitization

uygulanıyor mu değerlendirilebilir.

39. Secret Review

Kaynak kod ve repository history üzerinde secret scanning gerçekleştirilebilir.

Özellikle:

API key
DB password
cloud credential
private key
token

aranır.

Bulunan active secret'lar kritik olarak ele alınabilir.

40. Dependency Review

SCA ile üçüncü taraf bileşenler analiz edilir.

Örneğin:

package,
version,
CVE,
dependency path,
fixed version

belirlenir.

SCA sonuçları da SAST gibi triage edilmelidir.

41. Reachability Review

Riskli dependency'nin zafiyetli fonksiyonu gerçekten kullanılıyor mu değerlendirilir.

Bu işlem özellikle büyük dependency listelerinde risk önceliğini belirlemek açısından önemlidir.

42. Configuration Review

Kaynak kod repository'sinde security configuration dosyaları da bulunabilir.

Örneğin:

CORS config
auth config
Spring Security
nginx template
application config

incelenebilir.

Yanlış configuration kod kadar kritik güvenlik problemi yaratabilir.

43. Infrastructure as Code Review

Scope'a dahilse Terraform, Kubernetes YAML ve diğer IaC dosyaları analiz edilebilir.

Örneğin:

public resource,
overly permissive IAM,
privileged container,
disabled encryption

gibi problemler tespit edilebilir.

44. CI/CD Configuration Review

Kaynak kod güvenli ama pipeline güvensiz olabilir.

Bu nedenle kritik projelerde:

pipeline credential,
branch protection,
deployment permission,
third-party action,
artifact integrity

gibi konular değerlendirilebilir.

45. Build Script Review

Build script'leri supply chain riskleri açısından önemlidir.

Örneğin build sırasında internetten doğrulanmadan script indiriliyor olabilir.

Package integrity kontrol edilmiyor olabilir.

Secret command line argument içinde kullanılıyor olabilir.

Bunlar da analiz kapsamına alınabilir.

46. Manual Review ve SAST Sonuçları Nasıl Birleştirilir?

SAST ve manuel analiz farklı bulgular üretebilir.

Örneğin SAST:

SQL Injection

bulabilir.

Manuel analiz:

Authorization Bypass

tespit edebilir.

Raporun tek bir risk modeli altında bu iki kaynağı birleştirmesi gerekir.

Müşteri açısından bulgunun hangi yöntemle bulunduğundan daha önemli olan gerçek riskidir.

47. Bulgu Doğrulama

Her bulgu mümkün olduğunca doğrulanmalıdır.

Örneğin SQL Injection potansiyel olarak tespit edilmiş olabilir.

Kod analiziyle Source-to-Sink akışı doğrulanır.

Mümkünse test ortamında güvenli şekilde runtime doğrulama da yapılabilir.

Bu yaklaşım bulgunun güvenilirliğini yükseltir.

48. Proof of Concept Gerekli midir?

Her kaynak kod bulgusunda exploit geliştirmek gerekli değildir.

Ancak kritik bulgularda kontrollü Proof of Concept gerçek riskin anlaşılmasını kolaylaştırabilir.

Özellikle:

RCE
Authentication Bypass
Authorization Bypass
SQL Injection

gibi bulgularda etki gösterilebilir.

Tabii test ortamı ve yetki sınırları gözetilmelidir.

49. Kaynak Kod Analizinde CVSS Kullanımı

CVSS teknik severity belirlemek için kullanılabilir.

Ancak yalnızca CVSS skoru gerçek iş riskini tam olarak göstermez.

Örneğin yüksek CVSS skorlu bir fonksiyon production'da kullanılmıyor olabilir.

Bu nedenle CVSS şu bilgilerle desteklenmelidir:

Reachability
Exposure
Data sensitivity
Business criticality
Exploitability

50. CWE Mapping

Her güvenlik bulgusunun mümkün olduğunca uygun CWE kategorisiyle eşleştirilmesi faydalıdır.

Bu kurumların uzun vadeli güvenlik trendlerini ölçmesine yardımcı olur.

Örneğin kurum şunu görebilir:

CWE-79 türü sorunlar 6 ayda %40 azaldı.

Bu Secure Coding programının etkisini gösterir.

51. OWASP Mapping

Web ve API uygulamalarında bulgular OWASP risk kategorileriyle de eşleştirilebilir.

Bu özellikle teknik olmayan yöneticilerin sonuçları anlamasını kolaylaştırabilir.

Ancak OWASP Top 10 bütün zafiyetleri kapsayan tam teknik taxonomy olarak görülmemelidir.

CWE ile birlikte kullanılması daha güçlüdür.

52. Risk Severity Nasıl Belirlenmelidir?

Örnek seviyeler:

Critical

Sistem ele geçirme veya çok yüksek iş etkisi.

High

Ciddi veri veya yetki riski.

Medium

Belirli şartlarda anlamlı güvenlik etkisi.

Low

Sınırlı etki veya defence-in-depth problemi.

Informational

Doğrudan vulnerability olmayabilir ancak iyileştirme önerisidir.

Bu sınıflandırma kurum risk modeline göre değişebilir.

53. Technical Severity ve Business Risk Ayrımı

İdeal raporda bu ayrım düşünülmelidir.

Teknik olarak Medium olan bulgu kritik ödeme fonksiyonundaysa business risk High olabilir.

Teknik olarak High olan bir bulgu kullanılmayan demo fonksiyonda ise gerçek risk daha düşük olabilir.

Bu nedenle AppSec raporu yalnızca scanner severity'si sunmamalıdır.

54. Exploitability

Bulgunun ne kadar kolay istismar edilebileceği değerlendirilir.

Örneğin:

authentication gerekiyor mu?
special condition gerekiyor mu?
internetten erişilebilir mi?
kullanıcı etkileşimi gerekiyor mu?

gibi sorular önemlidir.

55. Impact

Saldırı başarılı olduğunda ne olabilir?

Örneğin:

veri sızıntısı,
yetki yükseltme,
finansal işlem manipülasyonu,
account takeover,
remote code execution

gibi etkiler olabilir.

Rapor riskin gerçek sonucunu açıkça anlatmalıdır.

56. Remediation Nedir?

Remediation güvenlik açığının düzeltilmesi sürecidir.

İyi bir kaynak kod analizi yalnızca problemi göstermez.

Nasıl düzeltileceğini de anlatır.

Örneğin:

Problem: String concatenation ile SQL.

Remediation: Parameterized Query.

Ancak çözüm teknoloji stack'e uygun olmalıdır.

57. Güvenli Kod Örneği Vermek Faydalı mıdır?

Evet.

Özellikle geliştirici odaklı raporlarda oldukça değerlidir.

Unsafe ve Secure örnek karşılaştırması remediation süresini azaltabilir.

Ancak örnek uygulamanın gerçek framework ve diline uygun olmalıdır.

Genel pseudocode bazen yeterli olmayabilir.

58. Remediation Guidance Ne Kadar Detaylı Olmalı?

Bulgunun riskine göre değişebilir.

Örneğin düşük seviyeli security header eksikliği için kısa öneri yeterli olabilir.

Karmaşık authorization problemi için:

root cause,
affected flow,
secure architecture recommendation,
test case

daha detaylı verilmelidir.

59. Developer-Friendly Report

İyi rapor geliştirici tarafından kullanılabilir olmalıdır.

Her bulgu mümkünse şu bilgileri içermelidir:

Title
Severity
Affected File
Line Number
Description
Root Cause
Attack Scenario
CWE
OWASP
Remediation
Secure Code Example

Bu format güvenlik raporunu aksiyona dönüştürür.

60. Yönetici Özeti Ayrı Olmalı mı?

Evet.

Teknik rapor yüzlerce sayfa olabilir.

Üst yönetimin kod satırlarını incelemesi beklenmez.

Executive Summary şu konulara odaklanabilir:

toplam risk,
kritik bulgu sayısı,
en önemli risk alanları,
tekrar eden zayıflıklar,
önerilen öncelikler.

Böylece aynı rapor hem teknik hem yönetim tarafına hizmet eder.

61. Risk Distribution

Rapor içerisinde risk dağılımı gösterilebilir.

Örneğin:

Critical: 2

High: 7

Medium: 18

Low: 31

Ancak sadece sayı yeterli değildir.

En kritik üç risk ayrıca açıklanmalıdır.

62. CWE Distribution

Tekrarlayan zayıflık kategorileri raporlanabilir.

Örneğin:

Authorization: %28

Input Validation: %22

Secret Management: %15

Bu sonuçlar geliştirici eğitimleri için değerli veri sağlar.

63. Root Cause Summary

Örneğin 50 bulgu 7 temel kök nedenden kaynaklanıyor olabilir.

Bunu göstermek tek tek bulgu sayısından daha değerlidir.

Çünkü kurum şu soruya cevap alır:

Neden açık üretiyoruz?

Bu AppSec olgunluğunu artırır.

64. Remediation Prioritization

Bütün bulgular aynı anda düzeltilmeyebilir.

Bu nedenle önceliklendirme yapılmalıdır.

Örnek:

Priority 1

Internet-facing Critical / High.

Priority 2

Authentication ve authorization.

Priority 3

Hassas veri ve secret riskleri.

Priority 4

Medium Security Debt.

Bu yaklaşım ekip kaynaklarını doğru yönlendirir.

65. Remediation Workshop

Karmaşık projelerde rapor teslim etmek tek başına yeterli olmayabilir.

Security ve development ekipleri birlikte remediation workshop yapabilir.

Bu toplantıda:

Critical bulgular,
root cause,
safe implementation,
ownership

değerlendirilir.

Bu, özellikle ilk kaynak kod analizi projelerinde oldukça faydalıdır.

66. Bulgu Owner Ataması

Her bulgunun bir sahibi olmalıdır.

Aksi halde bulgular raporda kalabilir.

Örneğin:

Authentication Team

Payment Team

Platform Team

gibi owner atanabilir.

Ticket sistemine entegrasyon yapılabilir.

67. SLA Belirleme

Risk seviyesine göre remediation SLA belirlenebilir.

Örneğin:

Critical: Acil

High: Öncelikli

Medium: Planlı sprint

Low: Backlog

Kurumun kendi risk yönetimi yaklaşımı ve regülasyonları dikkate alınmalıdır.

68. Retest Nedir?

Geliştiriciler bulguları düzelttikten sonra güvenlik ekibi düzeltmeyi doğrular.

Bu aşamaya Retest denir.

Amaç yalnızca kod değişmiş mi bakmak değildir.

Güvenlik açığı gerçekten kapanmış mı kontrol edilir.

69. Retest'te Yeni Açık Oluşabilir mi?

Evet.

Bazen remediation yeni güvenlik problemi yaratabilir.

Örneğin geliştirici SQL Injection'ı düzeltirken yeni authorization kontrolü eklemiş ve başka bir akışı bozmuş olabilir.

Bu nedenle özellikle kritik değişikliklerde regression testing önemlidir.

70. Security Regression Test

Daha önce bulunan açığın tekrar oluşmaması için otomatik test oluşturulabilir.

Örneğin:

Pentestte belirli authorization bypass bulunmuştur.

Düzeltildikten sonra unit veya integration security test eklenebilir.

Böylece aynı problem gelecekte otomatik yakalanır.

Bu oldukça olgun bir DevSecOps yaklaşımıdır.

71. Pentest Bulgusu SAST Rule'a Dönüştürülebilir mi?

Bazı durumlarda evet.

Örneğin kurumun internal framework'ünde güvensiz bir helper kullanımı pentest sırasında keşfedilmiş olabilir.

AppSec ekibi custom SAST rule yazar.

Bundan sonra bütün repository'ler aynı pattern açısından otomatik taranır.

Bu güvenlik bilgisini ölçeklendirir.

72. Kaynak Kod Analizi Ne Sıklıkta Yapılmalıdır?

Bu uygulamanın geliştirme sıklığına bağlıdır.

Sürekli geliştirme yapılan projelerde otomatik SAST her Pull Request veya build'de çalışabilir.

Manuel kaynak kod analizi ise:

major release,
mimari değişiklik,
authentication değişikliği,
kritik yeni özellik

sonrasında yapılabilir.

73. Full Scan Ne Zaman Çalıştırılmalı?

Full SAST scan büyük projelerde zaman alabilir.

Bu nedenle:

Pull Request → Incremental Scan

Nightly / Weekly → Full Scan

modeli kullanılabilir.

Bu hız ve kapsam arasında denge sağlar.

74. Release Öncesi Güvenlik Kontrolü

Kritik release öncesinde:

SAST
SCA
Secret Scanning
DAST
Pentest

sonuçları tek risk görünümünde değerlendirilebilir.

Belirli seviyenin üzerinde açık varsa release risk kabul sürecine alınabilir.

75. Kaynak Kod Analizi ile Secure SDLC İlişkisi

Kaynak kod analizi Secure SDLC'nin yalnızca bir aşamasıdır.

Öncesinde:

Threat Modeling

ve Secure Coding.

Sonrasında:

DAST,

Pentest,

Monitoring

bulunur.

Bu nedenle tek seferlik analiz yerine bütün yaşam döngüsüne entegre model daha güçlüdür.

76. Kaynak Kod Analizinde Kullanılan Araçlar

SAST ürünleri farklılık gösterebilir.

Bazı araçlar enterprise ölçeğinde çalışır.

Bazıları open source olabilir.

Bazıları belirli programlama dillerinde daha güçlü olabilir.

Araç seçiminde:

language support,
framework support,
data flow capability,
CI/CD integration,
false positive,
custom rule

gibi kriterler önemlidir.

Araç ismi metodolojiden daha önemli değildir.

77. Tek SAST Aracı Yeterli mi?

Her zaman değil.

Farklı araçlar farklı kurallarda güçlü olabilir.

Ancak birden fazla araç kullanmak da bulgu gürültüsünü artırabilir.

Araç sayısından çok:

doğru tuning + manuel doğrulama

önemlidir.

78. Custom Rule Nedir?

Kurumun kendi geliştirme framework'üne özgü security rule yazılabilir.

Örneğin:

unsafeExecute()

isimli internal fonksiyon kullanımı yasaklanabilir.

SAST bu fonksiyon görüldüğünde otomatik bulgu oluşturabilir.

Bu kurumun security knowledge'ını otomasyona dönüştürür.

79. SAST Tuning

İlk scan sonrasında sistem optimize edilmelidir.

Örneğin:

custom sanitizer tanımı,
false positive suppression,
framework model,
source/sink rule

eklenebilir.

İyi tuning zaman içerisinde bulgu kalitesini ciddi şekilde yükseltir.

80. Tool Accuracy Nasıl Ölçülür?

Sadece bulunan toplam bulgu sayısına bakılmamalıdır.

Daha anlamlı metrik:

True Positive Rate

olabilir.

Örneğin 100 bulgunun 90'ı False Positive ise araç operasyonel olarak sorun yaratabilir.

Amaç maksimum bulgu değil maksimum anlamlı sinyaldir.

81. Kaynak Kod Analizinde İnsan Faktörü

Otomasyon ne kadar güçlü olursa olsun uzman deneyimi önemlidir.

Özellikle:

business logic,
complex authorization,
architectural flaw,
attack chaining

alanlarında insan analizi kritik olmaya devam eder.

Bu nedenle modern model:

Automation at Scale + Human Depth

şeklinde düşünülmelidir.

82. Analiz Ekibinin Yetkinliği

Kaynak kod analizi yapan ekibin yalnızca siber güvenlik bilmesi yeterli değildir.

Yazılım geliştirme bilgisi de gerekir.

Örneğin:

programlama dili,
framework,
design pattern,
database,
API architecture

bilgisi analizin kalitesini doğrudan etkiler.

Çünkü kodu anlamadan kod güvenliği analiz edilemez.

83. White Box Avantajı

Kaynak kod analizi white box görünürlük sağlar.

Saldırganın dışarıdan göremediği:

internal validation,
security control,
unreachable code,
sensitive function

görülebilir.

Bu pentest ile birlikte kullanıldığında oldukça güçlüdür.

84. Kaynak Kod Analizi ve Pentest Birlikte Nasıl Kullanılır?

İdeal senaryolardan biri şudur:

SAST

↓

Manual Code Review

↓

Pentest

SAST geniş kod kapsamı sağlar.

Manuel code review kritik noktaları derinleştirir.

Pentest gerçek çalışma ortamında etkileri doğrular.

Bu üç katman birlikte güçlü güvenlik görünürlüğü oluşturur.

85. Source-Assisted Pentest

Pentester'ın source code erişimine sahip olması test verimliliğini artırabilir.

Örneğin koddan hidden endpoint bulunabilir.

Authorization implementation anlaşılabilir.

Potential sink görülebilir.

Ardından runtime üzerinde kontrollü test yapılabilir.

Bu yaklaşım özellikle kritik uygulamalarda değerlidir.

86. Raporun Amacı Ne Olmalıdır?

İyi kaynak kod analizi raporunun amacı güvenlik ekibinin ne kadar fazla bulgu bulduğunu göstermek değildir.

Amaç geliştirme ekibinin:

neye, neden ve hangi sırayla müdahale etmesi gerektiğini

göstermektir.

Rapor karar verilebilir olmalıdır.

87. Rapor Tesliminden Sonra Süreç Bitmeli mi?

Hayır.

En değerli aşama çoğu zaman rapordan sonra başlar.

Remediation,

developer workshop,

retest,

metrics

süreci devam etmelidir.

Aksi halde rapor birkaç ay sonra güncelliğini kaybedebilir.

88. Continuous Code Security

Olgun kurumlarda kaynak kod analizi tek seferlik hizmet olmaktan çıkar.

Her Pull Request'te otomatik kontroller çalışır.

Kritik modüller periyodik manuel review alır.

Yeni CVE'ler sürekli izlenir.

Pentest major release'lerde yapılır.

Bu yapıya Continuous Application Security perspektifiyle yaklaşılabilir.

SecureSys Kaynak Kod Analizi Metodolojisi

SecureSys olarak kaynak kod analizini yalnızca bir SAST aracının çalıştırılması ve araç çıktısının raporlanması şeklinde değerlendirmiyoruz.

Uygulamanın gerçek güvenlik seviyesini anlayabilmek için analiz sürecinin;

kapsam, teknoloji, mimari, iş mantığı ve saldırı yüzeyi

perspektiflerini birlikte içermesi gerektiğini düşünüyoruz.

Proje kapsamına göre süreç şu şekilde ele alınabilir:

1. Kapsam Belirleme

Repository, branch, teknoloji ve kritik modüllerin belirlenmesi.

2. Mimari Analiz

Uygulamanın authentication, authorization, data flow ve entegrasyon yapısının anlaşılması.

3. Otomatik SAST Analizi

Kod tabanının güvenlik zayıflıkları açısından geniş kapsamlı taranması.

4. SCA ve Secret Scanning

Üçüncü taraf dependency ve credential risklerinin değerlendirilmesi.

5. Manuel Kaynak Kod Analizi

Kritik business logic, authentication, authorization ve hassas işlem akışlarının uzman tarafından incelenmesi.

6. Security Triage

False Positive sonuçların ayıklanması ve gerçek risklerin doğrulanması.

7. CWE / OWASP / Risk Mapping

Bulguların standardize edilmesi.

8. Remediation Guidance

Geliştirici ekiplerine uygulanabilir güvenli kod önerileri sağlanması.

9. Retest

Düzeltmelerin güvenlik açısından doğrulanması.

Amaç mümkün olan en fazla bulguyu üretmek değildir.

Amaç:

gerçek riskleri bulmak, geliştiricinin anlayacağı şekilde açıklamak ve aynı güvenlik problemlerinin tekrar oluşmasını azaltacak bir yapı oluşturmaktır.

Çünkü iyi bir kaynak kod analizi yalnızca bugünkü zafiyetleri ortaya çıkarmaz.

Kurumun yarın daha güvenli kod üretmesine de katkı sağlar.

Sık Sorulan Sorular

Kaynak kod analizi nasıl yapılır?

Kaynak kod analizi genel olarak kapsam belirleme, mimari inceleme, otomatik SAST, manuel kod analizi, bulgu doğrulama, risk derecelendirme, raporlama ve retest aşamalarından oluşur.

Kaynak kod analizi için kodun tamamı gerekli midir?

Kapsama bağlıdır. Ancak bütün veri akışlarını ve framework davranışlarını doğru değerlendirebilmek için ilgili uygulamanın tamamına veya yeterli repository kapsamına erişim faydalıdır.

SAST sonucu doğrudan rapor olarak kullanılabilir mi?

Profesyonel değerlendirmede önerilmez. Bulguların False Positive, reachability, iş etkisi ve gerçek istismar koşulları açısından uzman tarafından doğrulanması gerekir.

Kaynak kod analizinde manuel inceleme gerekir mi?

Özellikle kritik uygulamalarda evet. Business Logic, authentication ve authorization gibi alanlar manuel analizden önemli ölçüde faydalanır.

Kaynak kod analizi ne kadar sürer?

Uygulamanın kod büyüklüğü, teknoloji çeşitliliği, mimari karmaşıklık ve manuel analiz kapsamına göre değişir.

Hangi programlama dilleri analiz edilebilir?

Kullanılan SAST ve uzmanlık kapsamına bağlı olarak Java, C#, JavaScript, TypeScript, Python, PHP, Go, C/C++, Kotlin, Swift ve diğer diller analiz edilebilir.

Kaynak kod analizi ile pentest birlikte yapılmalı mı?

Kritik uygulamalarda oldukça güçlü bir yaklaşımdır. Kaynak kod analizi iç görünürlük sağlarken pentest çalışan uygulamayı saldırgan perspektifinden değerlendirir.

Kaynak kod analizi raporunda ne bulunmalıdır?

Bulgu adı, risk seviyesi, etkilenen kod, teknik açıklama, kök neden, saldırı senaryosu, CWE/OWASP ilişkisi, remediation ve gerekiyorsa güvenli kod örneği bulunmalıdır.