# Kaynak Kod Analizi Nasıl Yapılır? Metodoloji, Araçlar ve Raporlama **URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/kaynak-kod-analizi-nasil-yapilir-metodoloji ![Kaynak Kod Analizi Nasıl Yapılır? Metodoloji, Araçlar ve Raporlama](/images/bilgi-merkezi/covers/cover-kod-10.webp) 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. #### Retest gerekli midir? Özellikle Critical ve High bulgular için önerilir. Düzeltmenin gerçekten güvenlik açığını kapatıp kapatmadığı doğrulanmalıdır. ### Sonuç: İyi Kaynak Kod Analizi Araç Çalıştırmak Değil, Kodu Anlamaktır Kaynak kod analizi dışarıdan bakıldığında teknik bir tarama faaliyeti gibi görülebilir. Ancak gerçek güvenlik değeri kullanılan aracın isminden çok metodolojiden gelir. SAST büyük kod tabanını tarayabilir. SCA dependency risklerini gösterebilir. Secret Scanning credential sızıntılarını bulabilir. Ancak bunların tamamı ham güvenlik verisidir. Gerçek güvenlik analizi bu veriyi bağlamla birleştirdiğinde ortaya çıkar. Uygulama ne yapıyor? Bu fonksiyona kim erişebilir? Bu veri ne kadar kritik? Kod production'da gerçekten kullanılıyor mu? Saldırgan bu akışı istismar edebilir mi? İş etkisi ne olur? Bu sorular cevaplanmadan bir araç çıktısının gerçek riske dönüşmesi mümkün değildir. Bu nedenle güçlü kaynak kod analizi üç temel bileşenden oluşur: #### Otomasyon genişlik sağlar. #### İnsan uzmanlığı derinlik sağlar. #### Metodoloji ikisini gerçek riske dönüştürür. Sonuçta amaç 10.000 satırlık scanner çıktısı üretmek değildir. Amaç geliştiriciye ve yönetime net olarak şunu söyleyebilmektir: **Burada bir risk var.** **Bu nedenle oluşuyor.** **Şu saldırıya yol açabilir.** **Ve güvenli şekilde böyle düzeltilmelidir.** Gerçek kaynak kod güvenliği tam olarak burada başlar.