Kaynak Kod Analizi (SAST) Nedir? Güvenli Kod İnceleme Rehberi

Bir yazılım ekibi, release öncesinde kaynak kodunu SAST aracına gönderiyor. Tarama tamamlandığında 1.846 finding oluşuyor. Dashboard kırmızı ve turuncu kayıtlarla doluyor. Security ekibi yüksek severity sonuçlarını ayıklamaya, developer’lar ise kendilerine atanan ticket’ların hangi kısmının gerçekten risk olduğunu anlamaya çalışıyor.

İlk haftanın sonunda bulguların önemli bölümü kapatılıyor. Bazıları test kodunda. Bazıları uygulamanın hiç çağırmadığı bir function içinde. Bir kısmında araç, kurumun kullandığı custom sanitizer’ı tanımıyor. Bazı kayıtlar duplicate. Rapor küçüldükçe herkes rahatlıyor.

Fakat uygulamadaki asıl problem listede yok.

Bir endpoint, giriş yapmış kullanıcının gönderdiği invoiceId değerini alıyor ve kaydı doğrudan repository’den getiriyor. Kullanıcı authenticated, endpoint üzerinde role kontrolü var ve input type olarak geçerli. Eksik olan tek şey, faturanın aynı tenant’a ait olduğunun doğrulanması. Bu kontrol kodda açıkça “tehlikeli bir function” şeklinde görünmediği için kullanılan rule set tarafından işaretlenmiyor.

Uzman reviewer, controller’dan service’e ve repository’ye uzanan akışı takip ettiğinde authorization kararının yalnızca role seviyesinde verildiğini görüyor. İki farklı tenant hesabıyla yapılan negative test, bir müşterinin başka müşteriye ait faturaya erişebildiğini doğruluyor.

Bu örneğin diğer yüzü de var. Yalnızca manuel incelemeye güvenen ekip, yüzlerce repository ve milyonlarca satır içinde tekrar eden riskli pattern’lerin tamamını göremeyebilir. Aynı unsafe deserialization çağrısı, unutulmuş bir mikroserviste veya nadiren build edilen bir modülde kalabilir. SAST’ın ölçek ve tekrar kabiliyeti burada insan incelemesinin ulaşamayacağı bir coverage sağlar.

Dolayısıyla doğru soru “SAST mı, manuel Secure Code Review mı?” değildir.

Doğru soru şudur:

Bu rehberde kaynak kod analizi nedir, SAST nasıl çalışır, hangi açıkları bulur, manuel secure code review neden gereklidir, SAST, DAST, IAST ve SCA nerede ayrışır, CI/CD entegrasyonu nasıl kurulmalı ve kaliteli bir kod inceleme raporu hangi kanıtları içermelidir sorularını teknik ayrıntılarıyla ele alacağız.

1. Kaynak kod analizi nedir?

Kaynak kod analizi, bir uygulamanın güvenlik davranışını kodun içinden inceleyen değerlendirme sürecidir. Amaç yalnızca riskli satırları işaretlemek değildir. Uygulamanın veriyi nereden aldığını, hangi trust boundary’lerden geçirdiğini, hangi güvenlik kararlarını nerede verdiğini ve saldırgan kontrollü verinin hangi kritik işlemlere ulaşabildiğini anlamaktır.

Profesyonel bir çalışma genellikle şu katmanları birlikte ele alır:

• Source code ve gerektiğinde generated code
• Build dosyaları ve resolved dependency graph
• Application configuration ve aktif environment profile’ları
• Authentication ve authorization implementation’ı
• Input validation, encoding ve data transformation akışları
• Database, file system, operating system ve network erişimleri
• Cryptography, key management ve secret kullanımı
• Error handling, logging ve fail-open davranışlar
• Background job, message consumer, scheduler ve webhook gibi HTTP dışı entry point’ler
• SAST, SCA, secret scanning ve gerektiğinde IaC scanning sonuçları
• Unit, integration ve security test’lerinin güvenlik varsayımları

Bu kapsam nedeniyle “kaynak kod analizi” ile “SAST taraması” aynı anlama gelmez. SAST belirli bir analiz motorunun kod üzerinde otomatik olarak finding üretmesidir. Kaynak kod analizi ise bu çıktının ötesine geçerek architecture, context, root cause, exploitability ve remediation ilişkisini kurar.

Kaynak kod analizi neyi cevaplamalıdır?

İyi bir inceleme sonunda şu sorular cevapsız kalmamalıdır:

1. 1Uygulamanın attacker-controlled entry point’leri nelerdir?
2. 2Hassas veri ve kritik işlemler hangi component’lerde bulunur?
3. 3Authentication tamamlandıktan sonra object-level ve function-level authorization nerede uygulanır?
4. 4Security control’ler fail-open davranabilir mi?
5. 5Aynı root cause repository genelinde başka nerelerde tekrar eder?
6. 6Build edilen artifact ile incelenen commit gerçekten aynı mıdır?
7. 7Bulgu production context’inde hangi role, tenant, veri veya iş sürecini etkiler?
8. 8Önerilen fix yalnızca örneği mi kapatır, yoksa root cause’u mu giderir?
9. 9Düzeltme regression test’e veya kalıcı bir SAST rule’una dönüştürülebilir mi?

Bu soruların bir kısmı otomatik analizle yanıtlanabilir. Bir kısmı ise requirement, architecture ve runtime davranışı bilinmeden doğru cevaplanamaz.

Kaynak kod analizi yalnızca release öncesi mi yapılır?

Hayır. Tek seferlik ve büyük bir review, özellikle kritik release, satın alma, birleşme, legacy modernizasyonu veya incident sonrasında değerli olabilir. Ancak kod her gün değişiyorsa güvenlik değerlendirmesi de değişiklik akışına yaklaşmalıdır.

Olgun modelde:

• Developer IDE veya pre-commit aşamasında hızlı feedback alır.
• Pull request üzerinde değişen kod için SAST ve secret scanning çalışır.
• Default branch üzerinde daha geniş analiz yapılır.
• Kritik architecture veya security control değişiklikleri manuel review gate’ine girer.
• Release öncesinde yüksek riskli business flow’lar derinlemesine incelenir.
• Production davranışı DAST ve sızma testiyle ayrıca doğrulanır.

Kaynak kod analizi bu nedenle tek bir toplantı veya scanner job’ı değil, Secure SDLC içinde farklı derinliklerde tekrar eden bir assurance sürecidir.

2. SAST nedir, ne bulur ve neyi kaçırır?

SAST, Static Application Security Testing ifadesinin kısaltmasıdır. Uygulama çalıştırılmadan source code, bytecode veya bazı ürünlerde binary üzerinde static analysis yapar. Analiz motoru syntax, Abstract Syntax Tree, Control Flow Graph, call graph, type bilgisi ve data flow gibi yapılardan yararlanarak güvenlik zayıflığına işaret eden pattern’leri arar.

Basit bir SAST kuralı, riskli function çağrılarını veya hardcoded secret pattern’lerini arayabilir. Daha gelişmiş bir motor, kullanıcı girdisinin birden fazla function ve dosya üzerinden ilerleyerek SQL query, shell command, template renderer veya file path gibi bir sink’e ulaşıp ulaşmadığını modelleyebilir.

SAST’ın güçlü olduğu nokta tekrarlanabilir coverage’dır. Aynı rule set yüzlerce repository’de, her pull request’te veya her gece çalıştırılabilir. Finding’i file, line ve code flow ile developer’a yakın bir noktada gösterebilir.

SAST’ın sınırı ise gördüğü kodu gerçek çalışma context’iyle her zaman birleştirememesidir. Araç şu sorulara eksik cevap verebilir:

• Bu endpoint gerçekten internetten erişilebilir mi?
• İlgili function yalnızca test profile’ında mı çalışıyor?
• Custom sanitizer saldırı girdisini doğru context için gerçekten güvenli hâle getiriyor mu?
• Authorization kontrolü role seviyesinde var, fakat object ownership kontrolü de var mı?
• Bir işlemin iki kez yapılması finansal etki oluşturuyor mu?
• Runtime configuration kodda tanımlanandan farklı mı?
• Reverse proxy, WAF, API gateway veya service mesh davranışı attack path’i değiştiriyor mu?

SAST çoğunlukla injection, path traversal, unsafe deserialization, tehlikeli API kullanımı, bazı cryptography hataları, hardcoded secret ve memory safety problemleri gibi kodda gözlemlenebilir sınıflarda etkilidir. Business logic abuse, gerçek IDOR, multi-step authorization, race condition ve deployment configuration gibi context ağırlıklı alanlarda tek başına yeterli değildir.

Bu ayrımın daha teknik açıklaması için SAST nedir, hangi açıkları bulur ve hangilerini kaçırır yazısında parsing, AST, control flow, data flow, false positive ve false negative mekanizmalarını ayrıntılı olarak inceleyebilirsiniz.

SAST sonucu temizse kod güvenli midir?

Hayır. Temiz sonuç yalnızca aşağıdaki koşullar birlikte doğrulanırsa anlam taşır:

• Scanner gerçekten başarıyla tamamlandı.
• Doğru repository, branch ve commit tarandı.
• İlgili language ve framework analiz motoru tarafından destekleniyor.
• Build context eksiksiz sağlandı.
• Generated code ve kritik modüller kapsam dışında kalmadı.
• Uygun rule set etkinleştirildi.
• Sonuçlar parse ve upload edilirken kaybolmadı.
• Suppression ve baseline kayıtları gözden geçirildi.

Bu koşullar sağlansa bile “finding yok” ifadesi, “security weakness yok” anlamına gelmez. Yalnızca aracın mevcut coverage’ı içinde finding üretilmediğini gösterir.

SAST aracı seçerken neye bakılmalıdır?

Araç değerlendirmesi, demo ekranındaki finding sayısıyla yapılmamalıdır. Aynı repository’yi daha fazla uyarıyla dolduran ürün daha iyi coverage sağlamış olmayabilir. Gürültülü bir rule set, developer’ın gerçekten önemli sonuçları görmesini zorlaştırabilir.

Seçim sırasında şu başlıklar kanıtlanmalıdır:

• Kullanılan language ve framework version’ları destekleniyor mu?
• Analiz source code ile mi sınırlı, yoksa build, bytecode ve dependency context’ini kullanabiliyor mu?
• Interprocedural ve cross-file data flow hangi derinlikte çalışıyor?
• Custom source, sink, sanitizer ve framework modeli tanımlanabiliyor mu?
• Monorepo, generated code ve birden fazla build sistemi nasıl ele alınıyor?
• Pull request için incremental scan desteği var mı?
• IDE, CI/CD, issue tracker ve SARIF integration seçenekleri yeterli mi?
• Rule suppression, audit trail ve risk acceptance yaşam döngüsü yönetilebiliyor mu?
• Source code SaaS ortamına mı çıkıyor, yoksa on-premises veya customer-managed deployment mümkün mü?
• Scan süresi development akışına uygun mu?

Tool benchmark sonuçları yararlı bir başlangıçtır, fakat kurumun kendi code pattern’lerini temsil etmeyebilir. En doğru karşılaştırma, gerçek framework’leri ve custom abstraction’ları içeren kontrollü bir proof repository üzerinde yapılır. Bilinen positive ve negative test case’leriyle detection, false positive, code flow kalitesi ve çalışma süresi birlikte ölçülmelidir.

3. Manuel Secure Code Review ile otomatik SAST arasındaki fark

SAST ve Secure Code Review aynı repository’ye bakabilir, fakat farklı türde kanıt üretir.

SAST, önceden tanımlanabilen ve makine tarafından aranabilen code pattern’lerde ölçek sağlar. Uzman reviewer ise uygulamanın nasıl çalışması gerektiğini, güvenlik kararının hangi business context içinde verildiğini ve birbirinden güvenli görünen parçaların birlikte nasıl risk oluşturduğunu değerlendirir.

Örneğin bir ödeme endpoint’inde şu kontroller bulunabilir:

• Kullanıcı authenticated
• Request body schema açısından geçerli
• Tutar pozitif
• Kart token’ı doğru formatta
• Database query parameterized

SAST bu kontrollerin bir kısmını görebilir ve injection bulunmadığını gösterebilir. Fakat aynı paymentIntentId değerinin iki eşzamanlı request ile iki kez tamamlanabildiğini veya işlemin farklı merchant hesabı adına finalize edilebildiğini anlamak için state transition, ownership ve concurrency context’i gerekir.

Manuel Secure Code Review özellikle şu alanlarda üstünlük sağlar:

• Custom authentication ve authorization
• Tenant isolation ve object ownership
• Business rule ve state machine
• Fail-open error handling
• Multi-step workflow
• Race condition ve idempotency
• Cryptographic protocol kullanımı
• Güvenlik kontrolünün farklı katmanlarda tutarsız uygulanması
• Framework annotation veya middleware sırasından doğan semantic hata
• Root cause ve sistemik remediation tasarımı

SAST ise şu alanlarda daha güçlüdür:

• Büyük codebase üzerinde tekrarlanan pattern arama
• Her commit veya pull request’te aynı kontrolü çalıştırma
• Unutulmuş module ve nadir kullanılan function’larda coverage
• File ve line seviyesinde hızlı developer feedback
• Standard rule set’lerin kurumsal ölçekte uygulanması
• Düzeltmeden sonra aynı pattern’in geri gelip gelmediğini izleme

Bu nedenle güçlü model şudur:

1. 1SAST geniş tarama alanını oluşturur.
2. 2Uzman reviewer bulguları triage eder.
3. 3High-risk entry point ve trust boundary’ler manuel incelenir.
4. 4Manuel review sırasında bulunan tekrar edilebilir pattern için custom rule yazılır.
5. 5Finding remediation ve regression test ile kapatılır.
6. 6Runtime exploitability gerektiğinde sızma testiyle doğrulanır.

İki yöntemin coverage, context, maliyet, false positive ve raporlama açısından daha ayrıntılı karşılaştırması için Secure Code Review ile otomatik SAST taraması arasındaki fark başlıklı teknik incelemeye bakabilirsiniz.

4. Kaynak kod analizi ile sızma testi arasındaki fark

Kaynak kod analizi uygulamanın nasıl yazıldığını, sızma testi ise çalışan sistemin saldırgan girdisine gerçekte nasıl davrandığını inceler.

Kod incelemesi root cause’a yakındır. Bir authorization hatasının hangi service katmanında doğduğunu, yanlış helper’ın kaç yerde kullanıldığını ve güvenli fix’in nasıl merkezileştirilebileceğini gösterebilir. Buna karşılık runtime configuration, reverse proxy davranışı, deployed artifact, cloud permission veya üçüncü taraf integration etkisi source code içinde tam olarak görünmeyebilir.

Sızma testi gerçek attack surface’e yakındır. Uygulamanın dışarıdan erişilebilen flow’larını, security control’lerin runtime etkisini ve bir zafiyetin exploit edilmesiyle oluşan business impact’i gösterebilir. Buna karşılık erişilemeyen code path’leri, nadir exception branch’lerini veya repository genelindeki sistemik hatayı sınırlı sürede göremeyebilir.

White box sızma testi, tester’a source code veya architecture bilgisinin verilmesi nedeniyle iki yaklaşımı yakınlaştırır. Yine de aynı çalışma değildir. White box pentest’in temel kanıtı çalışan hedefteki davranıştır. Secure Code Review’ın temel kanıtı ise implementation içindeki root cause ve code path’tir.

En yüksek assurance için şu döngü kurulmalıdır:

Bu ayrımı SQL injection, IDOR, SSRF, deserialization, cryptography ve race condition örnekleri üzerinden görmek için kaynak kod analizi ile sızma testi nerede ayrışır yazısını okuyabilirsiniz.

Kurumsal bir çalışma planlanırken iki hizmetin aynı deliverable gibi fiyatlandırılması doğru değildir. Kod erişimi, build edilebilirlik, language ve framework çeşitliliği, deployed version eşleşmesi, test hesabı, environment ve beklenen evidence seviyesi ayrı scope kalemleridir.

5. SAST, DAST, IAST ve SCA farkları

Application Security programlarında en sık yapılan kavramsal hata, bütün scanner türlerini aynı işi yapan alternatif ürünler gibi değerlendirmektir. Oysa her yaklaşım farklı visibility ve evidence üretir.

SAST ile DAST neden birbirinin alternatifi değildir?

SAST, bir sink’e giden riskli data flow’u kodda görebilir. DAST ise ilgili flow’un deployed ortamda erişilebilir ve exploit edilebilir olup olmadığını sınar. SAST root cause’a, DAST gerçek davranışa yakındır.

Örneğin SAST, SQL string concatenation tespit edebilir. Fakat code path feature flag nedeniyle kapalı olabilir. Tersi durumda DAST bir injection davranışı görebilir, ancak arka planda kullanılan dynamic query builder nedeniyle doğru root cause’u belirleyemeyebilir.

IAST ne zaman değer üretir?

IAST, test sırasında hangi code path’in gerçekten çalıştığını application process’i içinden gözlemleyebilir. Bu yaklaşım source ve runtime bilgisini bir araya getirdiği için bazı finding’lerde yüksek confidence sağlayabilir.

Ancak IAST sonucu, test suite’in ulaştığı flow’larla sınırlıdır. Authorization bypass için gerekli ikinci role hiç kullanılmadıysa veya background consumer test edilmediyse instrumentation bu yolu gözlemleyemez.

SCA neden kaynak kod analizi değildir?

SCA, kullanılan package ve component’leri belirleyerek bunları bilinen vulnerability ve license verileriyle eşleştirir. Uygulamanın kendi yazdığı kodda bulunan IDOR, SQL injection veya business logic hatasını aramaz.

Aynı şekilde SAST da dependency’nin yayımlanmış CVE bilgisini eksiksiz yönetmek için tasarlanmamıştır. Bazı platformlar her iki capability’yi tek üründe sunsa bile sonuçlar ayrı veri kaynağı ve ayrı remediation mantığıyla ele alınmalıdır.

Hangisi seçilmeli?

Tek bir araç seçmek yerine risk katmanına göre kombinasyon kurulmalıdır:

• First-party code weakness için SAST
• Context ve security requirement için Secure Code Review
• Third-party component için SCA
• Çalışan uygulama ve configuration için DAST
• Test sırasında runtime code path görünürlüğü için IAST
• Gerçek exploitability ve chained impact için sızma testi

İsimlerin çokluğu programı karmaşıklaştırmamalıdır. Her araç için “hangi soruyu cevaplıyor, hangi kanıtı üretiyor ve hangi riski açıkta bırakıyor?” sorusu yazılı olarak cevaplanmalıdır.

6. Hangi zafiyetler kod düzeyinde yakalanır?

Bir vulnerability sınıfının kod içinde görünmesi, her implementation’ın aynı kolaylıkla bulunabileceği anlamına gelmez. Detection başarısı language, framework, build context, kullanılan wrapper’lar, data flow derinliği ve rule kalitesine göre değişir.

Injection zafiyetleri

SAST’ın klasik güçlü alanı, attacker-controlled input’un tehlikeli sink’e ulaştığı data flow’lardır. Örnek sink’ler şunlardır:

• SQL query
• Operating system command
• LDAP filter
• XPath expression
• Template expression
• Dynamic code evaluation
• Header veya log formatı

Ancak “parameterized API kullanılmış” olması yalnızca ilgili injection context’ini çözebilir. Query doğru parametrelenmiş olsa bile sorgu yanlış tenant’a ait veriyi getiriyorsa authorization açığı devam eder.

Authentication ve authorization

SAST bazı açık riskleri yakalayabilir:

• Security annotation olmayan kritik method
• Herkese açık bırakılan route
• Hardcoded administrative bypass
• Güvensiz password comparison
• Token validation’da kapatılmış signature kontrolü
• permitAll veya benzeri geniş policy kullanımı

Fakat aracın “kontrol var” demesi, kontrolün doğru olduğu anlamına gelmez. Bir role check bulunabilir, fakat resource ownership kontrolü eksik olabilir. Bir middleware token’ı doğrulayabilir, fakat ikinci route farklı bir middleware chain üzerinden geçebilir.

Authorization incelemesinde şu üç seviye ayrı izlenmelidir:

1. 1Function-level authorization: Kullanıcı bu işlemi çağırabilir mi?
2. 2Object-level authorization: Kullanıcı bu kaynağa erişebilir mi?
3. 3Property-level authorization: Kullanıcı bu field’ı okuyabilir veya değiştirebilir mi?

Bu ayrım yapılmadığında SAST annotation varlığını güvenlik sonucu sanabilir.

Unsafe deserialization

Static analysis, bilinen tehlikeli deserialization API’lerini ve attacker-controlled verinin bu API’lere ulaşmasını tespit edebilir. Fakat gerçek risk şu ayrıntılara bağlıdır:

• Hangi type’lara izin veriliyor?
• Polymorphic type handling açık mı?
• İlgili gadget classpath üzerinde bulunuyor mu?
• Object yalnızca parse mı ediliyor, yoksa side effect üreten method çağrılıyor mu?
• Signature veya integrity kontrolü deserialization’dan önce mi yapılıyor?

Dolayısıyla finding yalnızca “riskli API çağrısı” şeklinde bırakılmamalıdır.

Hardcoded secret

Secret scanning API key, token, private key veya password pattern’lerini geniş ölçekte arayabilir. Burada iki hata yaygındır:

• Her yüksek entropy string’i secret sanmak
• Bulunan secret’ı dosyadan silince incident’ın kapandığını düşünmek

Gerçek çalışma secret’ın geçerli olup olmadığını, hangi sisteme eriştiğini, repository history’de ne kadar kaldığını ve hangi log veya artifact’lara yayıldığını araştırmalıdır. Remediation çoğu durumda revoke, rotate, history analizi ve erişim log’u incelemesini içerir.

Güvenli file upload örneği

File upload güvenliği, yalnızca filename veya MIME kontrolüyle değerlendirilemez. Kod incelemesi request limitinden temporary storage’a, type validation’dan quarantine ve malware scanning’e, parser isolation’dan güvenli download’a kadar file lifecycle’ı izlemelidir.

Bu alan için hazırladığımız güvenli dosya yükleme geliştirici kontrol listesi, extension allowlist’in neden tek başına yeterli olmadığını ve code review sırasında hangi boundary’lerin izlenmesi gerektiğini ayrıntılı olarak açıklar.

7. Dil ve framework’e göre kaynak kod analizi yaklaşımı

Generic bir OWASP checklist’i başlangıç sağlayabilir, fakat framework davranışını modellemeyen inceleme kritik riskleri kaçırır. Aynı güvenlik amacı Java Spring, .NET, Node.js ve Python uygulamalarında farklı noktalarda uygulanır.

Java ve Spring

Spring projesinde yalnızca SecurityConfig dosyasını okumak yeterli değildir. Birden fazla SecurityFilterChain varsa matcher sırası, method security gerçekten etkin mi, self-invocation proxy’yi bypass ediyor mu, JPA repository query tenant scope içeriyor mu ve request body doğrudan entity’ye bind ediliyor mu soruları incelenmelidir.

Spring MVC ile WebFlux aynı execution model’e sahip değildir. ThreadLocal tabanlı security context varsayımı reactive flow’da bozulabilir. @PreAuthorize annotation’ının varlığı, proxy dışından veya aynı class içinden çağrılan method için beklenen kontrolün çalıştığını garanti etmez.

Bu framework’e özel review akışını build graph’tan Actuator ve async messaging’e kadar adım adım ele alan Java Spring güvenlik kod incelemesi rehberimizi kullanabilirsiniz.

.NET ve ASP.NET Core

.NET uygulamasında middleware sırası güvenlik davranışının parçasıdır. Authentication ve authorization middleware’lerinin endpoint mapping ile ilişkisi, fallback policy, birden fazla authentication scheme ve custom authorization handler’lar birlikte incelenmelidir.

Model binding sırasında client’ın değiştirmemesi gereken property’lerin DTO içine alınması over-posting riskine yol açabilir. EF Core parameterization sağlasa da FromSqlRaw, dynamic sorting veya string ile oluşturulan filtreler ayrıca incelenmelidir. Data Protection API kullanılıyor olması da key storage, rotation ve purpose separation’ın doğru olduğu anlamına gelmez.

Node.js, Express ve NestJS

Node.js ekosisteminde runtime esnekliği review’ı zorlaştırır. Route ve middleware’ler farklı modüllerde dinamik olarak register edilebilir. Express’te middleware sırası, NestJS’te global guard, controller guard ve route-level metadata ilişkisi authorization sonucunu değiştirebilir.

Öncelikli sink’ler arasında child_process, unsafe template rendering, filesystem operation, dynamic module loading ve outbound HTTP client’lar bulunur. Object merge davranışları prototype pollution, geniş DTO binding ise mass assignment riskine dönüşebilir.

Async flow’larda authorization kontrolünden sonra state’in değişmesi veya callback içinde farklı identity context kullanılması da yalnızca pattern taramasıyla kolayca görülemez.

Python, Django, Flask ve FastAPI

Python’da decorator, dependency injection ve metaprogramming kullanımı static analysis için belirsizlik oluşturabilir. Django’da view permission ile object permission ayrımı, serializer field’ları ve custom manager query’leri önemlidir. Flask uygulamalarında blueprint ve decorator sırası, FastAPI’de dependency chain ve response model’leri birlikte değerlendirilmelidir.

pickle, yaml.load benzeri deserialization yüzeyleri, subprocess kullanımları, Jinja template context’i, debug mode ve background task’ler öncelikli alanlardır. ORM kullanılması raw query veya authorization problemlerini ortadan kaldırmaz.

Aynı language, farklı risk

İki Java projesi aynı SAST aracıyla taransa bile coverage aynı değildir. Biri standart Spring Security kullanırken diğeri custom gateway annotation’ı ve şirket içi ORM wrapper’ı kullanabilir. İkinci projede doğru sonuç için:

• Custom source ve sink modelleri
• Sanitizer tanımları
• Framework-specific rule
• Build dependency’leri
• Generated code
• Application-specific authorization pattern’leri

analiz motoruna öğretilmelidir.

Bu nedenle araç seçiminde yalnızca “Java destekliyor” veya “Python destekliyor” ifadesi yeterli değildir. Kullanılan framework, version, build sistemi ve custom abstraction coverage’ı kanıtlanmalıdır.

8. Güvenli kod inceleme nereden başlar?

Reviewer’ın ilk yaptığı iş bütün repository’yi satır satır okumaya başlamak olmamalıdır. Önce uygulamanın güvenlik haritası çıkarılmalıdır.

1. Review contract oluşturun

İncelemenin sınırı yazılı hâle getirilmelidir:

• Repository ve module listesi
• Branch, tag ve commit SHA
• Build talimatı
• İncelenecek language ve framework’ler
• Generated code ve third-party code durumu
• In-scope ve out-of-scope component’ler
• Beklenen ASVS seviyesi veya security requirement set’i
• Production artifact ile eşleşme yöntemi
• Data handling ve NDA koşulları
• Rapor, remediation workshop ve retest beklentisi

“Backend kodu incelenecek” ifadesi scope değildir. Authentication service başka repository’deyse veya API gateway policy’leri kapsam dışındaysa reviewer eksik bir güvenlik resmi görür.

2. Build ve dependency graph çıkarın

Manifest dosyasında yazan dependency, build edilen artifact içinde kullanılan gerçek version olmayabilir. Lockfile, parent dependency, transitive dependency, plugin, repository source ve build profile birlikte incelenmelidir.

Build edilemeyen repository için SAST coverage’ı sınırlanabilir. Bu durumda hangi module’lerin çözümlenemediği raporda açıkça yazılmalı, “tarama tamamlandı” ifadesi kullanılmamalıdır.

3. Entry point envanteri oluşturun

Yalnızca HTTP controller’ları çıkarmak yetmez. Şunlar da entry point olabilir:

• REST ve GraphQL resolver
• WebSocket handler
• Message queue consumer
• Scheduled job
• Webhook
• File import
• CLI command
• RPC method
• Serverless function
• Administrative maintenance endpoint

Attacker-controlled veya düşük güvenli kaynaktan gelen veri bu girişlerden sisteme ulaşır.

4. Trust boundary ve kritik asset’leri işaretleyin

Her boundary için şu sorular sorulmalıdır:

• Veri hangi identity ile geliyor?
• Integrity nasıl korunuyor?
• Authorization kararı nerede veriliyor?
• Veri hangi tenant veya kullanıcıyla ilişkilendiriliyor?
• Hangi dönüşümden sonra güvenilir sayılıyor?
• Başka bir process, network zone veya cloud account’a geçiyor mu?
• Sonuç log, cache, queue veya file olarak kalıcılaşıyor mu?

5. Security control implementation’ını bulun

Authentication filter, authorization service, tenant resolver, input validator, output encoder, cryptography wrapper, secret client, audit logger ve error handler gibi merkezi control’ler öncelikli incelenmelidir.

Merkezi control doğruysa bütün uygulama otomatik olarak güvenli değildir. Hangi code path’lerin bu control’ü bypass edebildiği ayrıca araştırılmalıdır.

6. High-risk flow’lara öncelik verin

Risk bazlı başlangıç noktaları şunlardır:

• Para veya bakiye hareketi
• Yetki ve rol değişikliği
• Kişisel veya ticari hassas veri
• File upload ve processing
• Outbound request
• Administrative function
• Bulk export
• Password reset ve account recovery
• Tenant geçişi
• Webhook ve integration
• Dynamic query veya command execution

Bu harita oluşturulduktan sonra SAST finding’leri doğru context içinde anlam kazanır.

9. Data flow ve taint analysis nasıl çalışır?

SAST’ın en önemli analiz tekniklerinden biri taint analysis’tir. Amaç, güvenilmeyen bir kaynaktan gelen verinin tehlikeli bir işlem noktasına ulaşmasını izlemektir.

Temel model dört parçadan oluşur:

1. 1Source: Attacker-controlled veya düşük güvenli veri kaynağı
2. 2Propagator: Veriyi taşıyan veya dönüştüren function
3. 3Sanitizer: Belirli bir sink context’i için veriyi güvenli hâle getiren kontrol
4. 4Sink: Verinin güvenlik etkisi üretebileceği kritik işlem

Örnek source’lar:

• HTTP query ve body parameter
• Header ve cookie
• Message queue payload
• File içeriği veya filename
• Database’den okunan, daha önce kullanıcı tarafından yazılmış veri
• Environment variable
• Third-party API response

Örnek sink’ler:

• SQL veya NoSQL query
• Operating system command
• Template rendering
• HTML output
• File path
• URL fetch
• Dynamic code execution
• Deserialization
• Log veya response header

Basit bir SQL injection data flow’u

Aşağıdaki Spring örneğinde customerId, HTTP request’ten source olarak gelir ve string concatenation ile SQL sink’ine ulaşır:

@GetMapping("/orders")
public List<Order> findOrders(@RequestParam String customerId) {
    String sql = "SELECT * FROM orders WHERE customer_id = '" + customerId + "'";
    return jdbcTemplate.query(sql, orderRowMapper);
}

Data flow şu şekilde özetlenebilir:

HTTP query parameter
        ↓
customerId
        ↓
String concatenation
        ↓
jdbcTemplate.query(...)
        ↓
SQL interpreter

Parameterized query, girdinin SQL syntax olarak yorumlanmasını engeller:

@GetMapping("/orders")
public List<Order> findOrders(@RequestParam String customerId) {
    String sql = "SELECT * FROM orders WHERE customer_id = ?";
    return jdbcTemplate.query(sql, orderRowMapper, customerId);
}

Bu değişiklik SQL injection root cause’unu giderir. Ancak hâlâ bir authorization sorusu vardır:

SAST parameterization’ı doğrulayabilir. Tenant relation’ı ise uygulamanın identity ve ownership modelini anlamadan doğrulayamaz.

Context-sensitive sanitizer neden önemlidir?

Bir veri bir context için güvenli hâle getirilmiş olabilir, başka bir context için olmayabilir.

• HTML encoding, SQL injection kontrolü değildir.
• URL encoding, operating system command için sanitizer değildir.
• SQL parameterization, dynamic table veya column name için allowlist ihtiyacını ortadan kaldırmaz.
• Path normalization, symlink boundary’sini tek başına çözmez.
• Input validation, output encoding’in yerine geçmez.

SAST aracı custom sanitizer’ı yanlış modellediğinde iki sonuç oluşabilir:

• Güvenli flow’u riskli sanarak false positive üretir.
• Yetersiz sanitizer’ı güvenli sanarak false negative üretir.

Interprocedural analysis

Gerçek uygulamalarda source ile sink aynı function’da bulunmaz. Veri controller’dan service’e, mapper’a, helper’a ve repository’ye geçebilir. Interprocedural analysis, function sınırları boyunca bu akışı takip etmeye çalışır.

Zorluklar şunlardır:

• Interface ve dynamic dispatch
• Reflection
• Dependency injection
• Callback ve event handler
• Asynchronous queue
• Framework-generated code
• Native call
• External service
• Dynamic language özelliği

Call graph eksikse data flow da eksik kalır.

Path-sensitive analysis

Aynı sink’e giden her yol riskli değildir. Bir branch üzerinde strict allowlist uygulanırken başka bir branch doğrudan sink’e ulaşabilir. Path-sensitive analiz bu koşulları ayırmaya çalışır.

Fakat path sayısı büyüdükçe state explosion oluşur. Araç performansı korumak için approximation yapar. Bu approximation false positive veya false negative üretebilir.

Second-order data flow

Attacker-controlled veri ilk request sırasında database’e güvenli biçimde yazılabilir. Daha sonra background job bu veriyi okuyup command, template veya query içinde kullanabilir. İlk flow ile sink arasında zaman ve component farkı vardır.

Bu tür second-order vulnerability’ler, tek scan veya tek request bağlamında kolayca kaçabilir. Reviewer persistent data source’larını ve downstream consumer’ları ayrıca izlemelidir.

Taint analysis authorization’ı çözebilir mi?

Kısmen. Bir engine, user-controlled ID’nin repository query’ye ulaştığını görebilir veya tenant filter içermeyen query pattern’ini işaretleyebilir. Ancak bir resource’un kime ait olduğunu, hangi role’ün hangi state’te erişmesi gerektiğini ve exception kararının business açısından doğru olup olmadığını genel olarak bilemez.

Bu yüzden authorization için taint analysis yardımcı signal’dır, nihai karar değildir.

10. CI/CD’ye SAST entegrasyonu nasıl yapılmalı?

Pipeline’a yeni bir sast job’ı eklemek teknik entegrasyonun küçük kısmıdır. Asıl mesele doğru kodun tarandığını, finding’in doğru kişiye ulaştığını ve quality gate’in development akışını bozmayacak şekilde gerçek riski yönettiğini kanıtlamaktır.

Katmanlı scan modeli

Tek profile bütün pipeline ihtiyaçlarını karşılamaz.

Developer ve IDE katmanı

• Hızlı ve yüksek confidence rule’lar
• Değiştirilen file için anlık feedback
• Developer’ın neden ve güvenli örnek görebilmesi

Pull request katmanı

• New code veya changed code odaklı analiz
• Kısa çalışma süresi
• Yüksek confidence ve yüksek impact finding’ler için progressive gate
• Code owner ve security owner’a görünürlük

Default branch katmanı

• Daha geniş rule set
• Repository genelinde data flow
• Baseline ve trend takibi
• SARIF veya benzeri standard output

Scheduled deep scan

• Daha maliyetli interprocedural query’ler
• Full build ve bütün module’ler
• Cross-repository veya monorepo analizi
• Rule ve coverage regression kontrolü

Release assurance katmanı

• Açık high-risk finding kontrolü
• Risk acceptance süresi ve owner doğrulaması
• Manuel review gerektiren değişikliklerin kontrolü
• SCA, secret scanning ve DAST sonuçlarıyla birlikte release kararı

İlk günden bütün bulgular build’i kırmamalıdır

Legacy repository’ye SAST eklendiğinde yüzlerce existing finding çıkabilir. Hepsini blocking yapmak ekipleri güvenli kod yazmaya yöneltmek yerine scanner’ı bypass etmeye teşvik eder.

Daha sağlıklı rollout:

1. 1Repository ve language coverage’ını doğrular.
2. 2Mevcut finding’ler için baseline oluşturur.
3. 3New code üzerinde yüksek confidence finding’leri gate yapar.
4. 4Existing debt’i owner ve remediation planıyla ayrı yönetir.
5. 5False positive oranına göre rule set’i tune eder.
6. 6Gate’i kademeli olarak genişletir.

Baseline geçmiş riski silmez. Yalnızca mevcut security debt ile yeni eklenen problemi birbirinden ayırır.

Scanner çalışmadıysa yeşil sonuç üretilmemelidir

Pipeline aşağıdaki durumlarda “başarılı tarama” göstermemelidir:

• Build dependency çözülemedi
• Analyzer process’i timeout oldu
• Repository checkout eksik
• SARIF upload başarısız
• İlgili language analiz edilmedi
• Rule bundle yüklenmedi
• License veya service erişimi nedeniyle scan atlandı

“Finding yok” ile “scan yok” aynı status değildir.

Finding developer’a nasıl ulaşmalı?

İyi bir finding kaydı en az şu bilgileri taşımalıdır:

• File ve line
• Source-to-sink code flow
• Rule ve CWE
• Confidence
• Affected branch ve commit
• Neden güvenlik problemi olduğu
• Uygulanabilir remediation örneği
• Owner
• Suppression veya risk acceptance durumu
• Fix verification sonucu

SARIF gibi standart formatlar, farklı static analysis araçlarının sonuçlarını repository içindeki code scanning deneyimine taşımayı kolaylaştırabilir. Format standardı tek başına finding kalitesini yükseltmez, fakat location, rule ve code flow bilgisinin kaybolmadan aktarılmasına yardımcı olur.

CI/CD entegrasyonunda baseline, quality gate, suppression, pipeline permission ve metric hatalarını ayrı ayrı ele aldığımız CI/CD’ye SAST eklerken en sık yapılan 7 hata rehberi, uygulama planı için daha derin bir çerçeve sunar.

11. False positive ve triage nasıl yönetilir?

False positive, aracın vulnerability olarak işaretlediği flow’un gerçek context içinde güvenlik açığı oluşturmamasıdır. Ancak bir finding’in developer tarafından “bu çalışmaz” denilerek kapatılması false positive kanıtı değildir.

Triage sırasında şu akış izlenmelidir:

1. 1Source gerçekten attacker-controlled mı?
2. 2Data flow eksiksiz mi?
3. 3Sink doğru sınıflandırılmış mı?
4. 4Sanitizer ilgili context için yeterli mi?
5. 5Code path build ve runtime’da reachable mı?
6. 6Authentication veya authorization gibi compensating control var mı?
7. 7Control bütün entry point’lerde uygulanıyor mu?
8. 8Finding hangi configuration ve framework davranışına bağlı?
9. 9Risk başka bir sink veya second-order flow’da devam ediyor mu?
10. 10Kapatma kararı evidence ile tekrar üretilebilir mi?

Suppression nasıl yapılmalı?

Suppression kalıcı ve sahipsiz bir sessizlik mekanizmasına dönüşmemelidir. Her kayıt şu alanları içermelidir:

• Gerekçe
• Evidence
• Reviewer
• Tarih
• Scope
• Rule version
• Son kullanma veya yeniden değerlendirme tarihi

Inline suppression comment’i kolaydır, fakat kodla birlikte yıllarca yaşayabilir. Rule güncellendiğinde veya control değiştiğinde kayıt yeniden gözden geçirilmelidir.

False positive oranı tek başına kalite metriği değildir

Finding sayısını azaltmak için agresif rule kapatmak false positive oranını düşürebilir, fakat false negative riskini artırır. Bu nedenle program şu metrikleri birlikte izlemelidir:

• Confirmed finding oranı
• Rule bazında false positive oranı
• Mean Time to Triage
• Mean Time to Remediate
• Reopened finding
• Expired suppression
• New code finding yoğunluğu
• Coverage başarısızlığı
• Manuel review veya pentest ile sonradan bulunan SAST-detectable weakness

Son metrik özellikle değerlidir. Sızma testinde bulunan bir injection root cause’u SAST tarafından görülebilecek durumdaysa, konu yalnızca tek finding değildir. Rule, build context veya coverage eksikliği araştırılmalıdır.

12. SCA ile bağımlılık ve lisans riski

Modern uygulamanın önemli bölümü third-party component’lerden oluşur. Software Composition Analysis, manifest, lockfile, build output veya binary üzerinden kullanılan component’leri belirler ve bunları bilinen vulnerability ile license bilgileriyle eşleştirir.

İyi bir SCA süreci şu ayrımları yapmalıdır:

• Direct ve transitive dependency
• Declared ve resolved version
• Development, test ve production dependency
• Runtime artifact içinde bulunan ve bulunmayan component
• Reachable ve yalnızca mevcut vulnerable code
• Patch, upgrade, replacement veya compensating control seçenekleri
• License obligation ve policy ihlali

Bir dependency’nin CVE ile eşleşmesi otomatik olarak production riskinin kritik olduğu anlamına gelmez. Bununla birlikte vulnerable function’a reachability görülmemesi de kesin güvenlik kanıtı değildir. Reflection, configuration, plugin architecture ve eksik call graph reachability sonucunu etkileyebilir.

SCA raporunda ne olmalı?

• Component adı ve ekosistemi
• Resolved version
• Dependency path
• İlgili CVE ve severity
• Fix bulunan version
• Runtime kullanım durumu
• Reachability confidence
• Public exploit veya active exploitation bilgisi
• License ve obligation
• Owner ve remediation tarihi
• SBOM referansı

SCA, SAST’ın yerine geçmez. Biri third-party component riskini, diğeri first-party code weakness’i inceler. İkisi aynı dashboard’da gösterilebilir, fakat remediation owner ve doğrulama adımı farklı olabilir.

13. Secret scanning ve hardcoded credential

Secret scanning, repository içindeki API key, access token, private key, connection string ve password gibi credential’ları arar. Pattern matching, provider-specific format ve entropy analizi birlikte kullanılabilir.

Tarama yalnızca güncel branch ile sınırlı olmamalıdır. Secret şu alanlarda kalabilir:

• Git history
• Eski branch ve tag
• Build log
• CI artifact
• Container layer
• Test fixture
• Infrastructure template
• Example configuration
• Notebook
• Mobile application resource
• Crash dump

Secret bulunduğunda doğru müdahale

Secret’ı source code’dan silmek yalnızca ilk adımdır. Şunlar yapılmalıdır:

1. 1Credential revoke veya rotate edilir.
2. 2Yetki scope’u ve erişebildiği asset’ler belirlenir.
3. 3Kullanım log’ları incelenir.
4. 4Repository history ve fork exposure’ı değerlendirilir.
5. 5Build artifact ve cache’ler temizlenir.
6. 6Secret manager kullanımına geçilir.
7. 7Aynı pattern için preventive control eklenir.

Finding geçerli bir credential ise bu artık yalnızca code quality konusu değil, olası security incident’tır.

False positive neden oluşur?

Test key, hash, UUID, encoded fixture ve yüksek entropy içeren sıradan veri secret sanılabilir. Kapatma kararında yalnızca value’ya değil provider, format, kullanım yeri ve doğrulama yöntemine bakılmalıdır. Gerçek credential’ı doğrulamak için production sisteminde kontrolsüz authentication denemesi yapılmamalıdır.

14. OWASP ASVS kaynak kod analizinde nasıl kullanılır?

OWASP Application Security Verification Standard, application security requirement’larını yapılandırılmış bir doğrulama çerçevesinde sunar. OWASP’ın güncel stable sürümü ASVS 5.0.0’dır.

ASVS’nin kaynak kod analizindeki değeri, review’ın yalnızca aracın bulabildiği rule’larla sınırlanmasını önlemesidir. Authentication, session management, authorization, validation, cryptography, communication, malicious code ve business logic gibi security control alanları requirement bazında ele alınabilir.

ASVS bir SAST rule set’i değildir

Her ASVS requirement static analysis ile doğrulanamaz. Bazıları:

• Source code inspection
• Configuration review
• Architecture evidence
• Runtime test
• Process evidence
• Manuel negative test

gerektirir.

Bir vendor’ın “OWASP ASVS coverage” demesi, bütün requirement’ların otomatik olarak doğrulandığı anlamına gelmez. Hangi ASVS version’ının, hangi requirement ID’lerinin ve hangi evidence türüyle kontrol edildiği sorulmalıdır.

ASVS 5.0.0 requirement’larına referans verilirken version bilgisinin ID ile birlikte yazılması değişiklik yönetimini kolaylaştırır. Örneğin yalnızca 1.2.5 yerine v5.0.0-1.2.5 formatı, raporun hangi standard sürümüne dayandığını açıklar.

Review planı ASVS ile nasıl kurulabilir?

1. 1Uygulamanın assurance ihtiyacı belirlenir.
2. 2İlgili ASVS requirement’ları scope’a alınır.
3. 3Her requirement için evidence yöntemi yazılır.
4. 4SAST ile doğrulanabilecek maddeler rule mapping’e bağlanır.
5. 5Manuel review gerektiren maddeler reviewer checklist’ine alınır.
6. 6Runtime test gerektiren maddeler sızma testi planına aktarılır.
7. 7Out-of-scope ve not-applicable kararları gerekçelendirilir.

OWASP Top 10 yeterli midir?

Hayır. OWASP Top 10 farkındalık ve risk iletişimi için değerlidir, fakat ayrıntılı source code review checklist’i değildir. Kod incelemesinde ASVS requirement’ları, CWE sınıfları, framework-specific güvenlik dokümantasyonu, threat model ve kurumun security requirement’ları birlikte kullanılmalıdır.

Özellikle 2025 CWE Top 25 listesinde XSS, SQL injection, CSRF, missing authorization, out-of-bounds write, path traversal ve command injection gibi root cause sınıflarının öne çıkması, kod düzeyindeki weakness yönetiminin önemini gösterir. Ancak liste sırası, her kurumun kendi risk önceliği değildir.

15. Kaynak kod analizi raporu ve remediation

İyi rapor yalnızca finding listesi vermez. İncelenen artifact’ı, coverage sınırlarını, root cause’u ve düzeltmenin nasıl doğrulanacağını açıklar.

Yönetici özeti

Yönetici özeti teknik ayrıntıyı silmemeli, karara dönüştürmelidir:

• İncelenen uygulama ve business function
• Scope ve assurance seviyesi
• Kritik risk temaları
• Systemic root cause’lar
• Release veya risk kararı üzerindeki etkiler
• Öncelikli remediation alanları
• Kapsam ve evidence sınırlamaları

Teknik rapor

Her finding mümkün olduğunca şu alanları içermelidir:

• Başlık
• Severity ve priority
• CWE ve ilgili ASVS requirement’ı
• Etkilenen repository, module, file ve line
• Commit SHA veya artifact version
• Source-to-sink data flow
• Preconditions
• Vulnerable code
• Root cause
• Exploit veya abuse senaryosu
• Etkilenen role, tenant, veri ve iş süreci
• Mevcut control ve bypass koşulu
• Güvenli remediation yaklaşımı
• Gerekirse örnek kod
• Regression test önerisi
• Retest veya verification adımı

Örnek finding özeti

Başlık: Tenant scope uygulanmadan fatura erişimi
Root cause: Repository query yalnızca invoiceId ile çalışıyor
Precondition: Authenticated customer hesabı
Etki: Başka tenant'a ait fatura metadata'sına erişim
Kod yolu: InvoiceController → InvoiceService → InvoiceRepository
Remediation: Query'yi tenantId ile scope et, service boundary'de ownership doğrula
Regression: İki tenant ve üç role içeren negative authorization test'i

Bu yapı, developer’ın yalnızca satırı değil güvenlik varsayımını düzeltmesini sağlar.

Remediation neden generic olmamalıdır?

“Input validation uygulayın” veya “authorization kontrolü ekleyin” uygulanabilir öneri değildir. Güçlü remediation:

• Kontrolün hangi boundary’de uygulanacağını
• Ortak helper veya policy’nin nasıl kullanılacağını
• Fail-closed davranışın ne olacağını
• Existing data ve backward compatibility etkisini
• Regression test’in hangi negative case’i içereceğini
• Aynı root cause’un repository genelinde nasıl aranacağını

açıklamalıdır.

Retest neyi doğrulamalıdır?

Retest yalnızca vulnerable satırın değiştiğini kontrol etmez. Şunlara bakar:

• Original data flow kesildi mi?
• Alternate entry point bypass bırakıyor mu?
• Fix bütün tenant ve role’lerde çalışıyor mu?
• Yeni validation farklı encoding veya parser ile aşılabiliyor mu?
• Regression test eklendi mi?
• Finding başka module’lerde tekrar ediyor mu?

Kod değişikliği merged olduğu için bulgu teknik olarak kapanmış sayılmaz.

16. Kaynak kod analizi hizmeti seçerken 8 kriter

1. SAST ile manuel Secure Code Review ayrımı açık mı?

Teklif yalnızca tool adı, scan süresi ve PDF rapor içeriyorsa bunun tam kaynak kod analizi olup olmadığı sorgulanmalıdır. Manuel review kapsamı, reviewer eforu ve high-risk flow’lar açıkça yazılmalıdır.

2. Language ve framework coverage’ı kanıtlanıyor mu?

“Java destekleniyor” ifadesi yeterli değildir. Spring Security, custom annotation, ORM wrapper, generated code ve build sistemi gibi gerçek teknoloji ayrıntıları değerlendirilmelidir.

3. Scope commit ve artifact seviyesinde tanımlı mı?

Repository adı dışında branch, tag, commit SHA, module, generated code, configuration ve deployed artifact eşleşmesi bulunmalıdır. Aksi halde sonuç hangi version için geçerli olduğu bilinmeyen bir rapora dönüşür.

4. Security context nasıl oluşturuluyor?

Reviewer’ın architecture, authentication modeli, role matrix, tenant yapısı, kritik data ve business flow hakkında hangi girdileri alacağı belli olmalıdır. Context olmadan manuel review da generic checklist’e dönüşebilir.

5. False positive ve false negative nasıl yönetiliyor?

Finding’lerin kim tarafından triage edileceği, suppression evidence’ı, rule tuning ve manuel sampling yaklaşımı sorulmalıdır. “Araç zaten sıfıra yakın false positive üretir” gerçekçi bir güvence değildir.

6. Kod gizliliği nasıl korunuyor?

Şu başlıklar sözleşmede yer almalıdır:

• NDA
• Source code’un tutulduğu location
• On-premises veya controlled environment seçeneği
• Reviewer access modeli
• Encryption
• Log ve artifact içeriği
• Subprocessor kullanımı
• Retention süresi
• Secure deletion
• Access audit

7. Rapor developer’ın kullanabileceği kadar teknik mi?

Rapor yalnızca severity ve CWE vermemelidir. Root cause, code flow, vulnerable location, remediation pattern ve regression test önerisi içermelidir. Teknik debrief ve developer workshop imkânı değerlendirilmelidir.

8. Remediation ve verification çalışmanın parçası mı?

Hizmet rapor tesliminde bitmemelidir. Kritik bulguların geliştirici ekiple açıklanması, fix yaklaşımının gözden geçirilmesi ve retest ile kapanışın doğrulanması beklenmelidir.

SECNODEX’in Kaynak Kod Analizi ve Secure Code Review hizmeti, SAST coverage’ını uzman manuel inceleme, OWASP ASVS referansı, business logic ve authorization analizi, geliştirici odaklı remediation ve verification adımlarıyla birleştirir.

18. Sonuç: Güçlü kaynak kod analizi, scanner çıktısını güvenlik kararına dönüştürür

SAST gereklidir, fakat tek başına yeterli değildir.

Otomatik static analysis, büyük codebase üzerinde tekrarlanabilir coverage sağlar. Riskli pattern’leri erken gösterir, developer feedback süresini kısaltır ve aynı weakness’in yeniden eklenmesini önlemeye yardımcı olur. Fakat uygulamanın business rule’unu, tenant modelini, exception kararını ve gerçek authorization amacını her zaman anlayamaz.

Manuel Secure Code Review bu context’i sağlar. Entry point’leri, trust boundary’leri, data flow’ları ve security control implementation’ını birlikte değerlendirir. Buna karşılık insan incelemesi de otomasyon olmadan milyonlarca satırdaki tekrar eden pattern’leri her değişiklikte aynı coverage ile tarayamaz.

Olgun yaklaşım şu parçaları birleştirir:

1. 1Doğru repository, commit ve build context
2. 2Language ve framework’e uygun SAST
3. 3SCA ve secret scanning
4. 4Risk bazlı manuel Secure Code Review
5. 5OWASP ASVS ile requirement coverage
6. 6Root cause ve developer odaklı remediation
7. 7Regression test ve custom rule
8. 8Gerektiğinde source code context’iyle planlanan sızma testi
9. 9Retest ve ölçülebilir finding lifecycle

SECNODEX, kaynak kod güvenliği çalışmalarını yalnızca scanner raporu üretmek için yürütmez. Otomatik analizi uzman incelemesiyle birleştirir, kritik code path’lerde authorization ve business logic kararlarını değerlendirir, bulguları root cause ve uygulanabilir remediation adımlarıyla raporlar.

Kaynak kodunuz için doğru review scope’unu belirlemek, SAST sonuçlarınızın neden gürültülü olduğunu değerlendirmek veya kritik bir release öncesinde Secure Code Review planlamak için SECNODEX ile iletişime geçebilirsiniz.

Çalışan uygulamadaki runtime davranışı ve gerçek exploitability’yi ayrıca doğrulamak için SECNODEX Sızma Testi hizmetini inceleyebilirsiniz.

Kaynaklar ve ileri okuma

• OWASP — Source Code Analysis Tools
• OWASP — Code Review Guide
• OWASP — Application Security Verification Standard 5.0.0
• OWASP — DevSecOps Guideline
• OWASP — Software Component Verification Standard
• OWASP — Dependency-Check
• NIST SP 800-218 — Secure Software Development Framework 1.1
• NIST SP 800-218 Rev. 1 — SSDF 1.2 Initial Public Draft
• MITRE — 2025 CWE Top 25 Most Dangerous Software Weaknesses
• OASIS — SARIF Version 2.1.0

<!--

EDİTORYAL INTERNAL LINK NOTU

Bu pillar sayfası aşağıdaki alt cluster içeriklerin merkezidir:

1. 1/blog/sast-nedir-hangi-aciklari-bulur-hangilerini-kacirir
2. 2/blog/secure-code-review-ile-otomatik-sast-taramasi-farki
3. 3/blog/kaynak-kod-analizi-ile-sizma-testi-farki
4. 4/blog/ci-cdye-sast-eklerken-en-sik-yapilan-7-hata
5. 5/blog/java-spring-guvenlik-kod-incelemesi
6. 6/blog/guvenli-dosya-yukleme-gelistirici-kontrol-listesi

Her cluster yazısından bu pillar sayfasına açıklayıcı ve birbirinden doğal anchor text'lerle geri bağlantı kurulmalıdır.

Pillar içinde aynı alt yazıya gereksiz tekrar link verilmemelidir.

Hizmet dönüşümü için ana bağlantı /hizmetler/kaynak-kod-analizi olmalıdır.

-->