Secure Code Review ile Otomatik SAST Taraması Farkı

Aynı source code iki farklı güvenlik çalışmasından geçiriliyor. Otomatik SAST taraması yüzlerce finding üretiyor. Bunların önemli bir bölümü false positive veya düşük riskli security hotspot olarak kapanıyor. Secure Code Review ise daha az sayıda bulgu çıkarıyor, fakat içlerinden biri bütün tenant'ları etkileyen merkezi bir authorization hatasını gösteriyor. Bir diğeri ödeme akışında aynı işlemin iki kez tamamlanmasına izin veren race condition'ı, üçüncüsü ise identity provider ulaşılamadığında authentication kontrolünün fail-open davranmasını ortaya koyuyor.

İlk bakışta iki sonuç birbirini tutmuyor gibi görünür.

SAST neden kritik business logic hatasını bulamadı? Manual reviewer yüzlerce riskli API kullanımını nasıl gözden kaçırdı? Hangisinin coverage'ı daha iyi? Hangisine güvenmek gerekir?

Sorun çoğu zaman çalışmalardan birinin başarısız olması değildir. İki yöntem aynı source code'a bakar, fakat aynı kanıtı üretmez.

SAST'ın güçlü tarafı hız, tekrar edilebilirlik ve geniş coverage'dır. Secure Code Review'in güçlü tarafı context, niyet, root cause ve uygulamaya özgü riskleri anlamaktır. SAST aynı unsafe function'ın 350 kullanımını saniyeler veya dakikalar içinde bulabilir. İnsan reviewer ise o function'ın neden çağrıldığını, hangi user role için tehlikeli olduğunu ve başka bir güvenlik kontrolüyle nasıl etkileştiğini yorumlayabilir.

Bu nedenle doğru soru “SAST mı, Secure Code Review mi?” değildir. Doğru soru şudur:

Bu yazıda Secure Code Review ile otomatik SAST taraması farkını yalnızca “insan ve tool” karşılaştırmasıyla ele almayacağız. İki yöntemin nasıl çalıştığını, hangi vulnerability sınıflarında ayrıştığını, raporlarının neden farklı olması gerektiğini, false positive ve false negative problemlerini ve ikisinin birlikte nasıl ölçeklenebileceğini teknik örneklerle inceleyeceğiz.

Önce terimleri birbirinden ayıralım

Piyasada “kaynak kod analizi”, “Secure Code Review”, “SAST”, “code scan” ve “manual review” ifadeleri zaman zaman birbirinin yerine kullanılıyor. Teklifte bu kelimelerin bulunması, hangi faaliyetin gerçekten yapılacağını göstermeyebilir.

Secure Code Review nedir?

Secure Code Review, source code'un security requirement ve threat scenario'lar açısından bir uzman tarafından sistematik biçimde incelenmesidir. Reviewer yalnızca syntax hatası veya bilinen dangerous function aramaz. Uygulamanın hangi varlığı koruduğunu, hangi input'a güvenildiğini, authorization kararının nerede verildiğini ve hata durumlarında güvenlik kontrolünün nasıl davrandığını anlamaya çalışır.

İyi bir Secure Code Review şu alanları ilişkilendirir:

• Architecture ve component sınırları
• Trust boundary'ler
• Authentication ve authorization modeli
• User role, tenant ve object ownership ilişkileri
• Sensitive data flow
• Input validation ve output encoding
• Cryptographic implementation ve key handling
• Session ve token lifecycle
• File, parser ve deserialization işlemleri
• External service ve webhook trust'i
• Error handling ve fail-open davranışı
• Concurrency, transaction ve state transition'lar
• Audit logging ve security event üretimi
• Business rule ve abuse case'ler

Secure Code Review, normal peer review ile de aynı şey değildir. Functional peer review kodun doğru çalışıp çalışmadığını, okunabilirliğini, maintainability'sini ve coding convention'lara uyumunu inceleyebilir. Security-focused review ise kötü niyetli input, yetkisiz kullanıcı, beklenmeyen sequence, bypass ve failure state üzerinden düşünür.

Bir kod parçası functional requirement'ı eksiksiz karşılayıp güvenlik açısından hatalı olabilir. “Kullanıcı belgeyi ID ile indirebiliyor” fonksiyonu çalışıyordur, testleri geçiyordur ve performansı iyidir. Fakat object'in o kullanıcıya ait olup olmadığı doğrulanmıyorsa security requirement karşılanmamıştır.

Otomatik SAST taraması nedir?

SAST, Static Application Security Testing ifadesinin kısaltmasıdır. Uygulama çalıştırılmadan source code, bytecode, intermediate representation veya bazı ürünlerde binary üzerinde otomatik analiz yapar.

SAST engine ürüne göre şu tekniklerin bir bölümünü kullanabilir:

• Pattern matching
• Abstract Syntax Tree analizi
• Semantic analysis
• Control Flow Analysis
• Data Flow Analysis
• Taint Analysis
• Call graph ve interprocedural analysis
• Type inference
• Framework ve library modelling
• Custom rule veya query çalıştırma

Araç riskli bir source ile hassas bir sink arasında güvenli olmayan data flow arayabilir. Örneğin HTTP request'ten gelen input'un SQL execution function'ına parameterization olmadan ulaştığını tespit edebilir. Ayrıca deprecated cryptographic API, hardcoded secret, certificate validation bypass veya unsafe deserialization option gibi pattern'leri işaretleyebilir.

SAST'ın neyi nasıl bulduğunu ayrıntılı incelemek için SAST nedir, hangi açıkları bulur, hangilerini kaçırır? başlıklı rehberimize bakabilirsiniz. Bu yazının odağı SAST'ın çalışma prensibini tekrarlamak değil, onun Secure Code Review ile nerede ayrıştığını göstermektir.

Manual review sırasında SAST kullanılırsa çalışma hâlâ manual mıdır?

Evet. Bir uzman SAST sonucunu review girdisi olarak kullanabilir. Tool'un işaretlediği flow'ları doğrulayabilir, false positive'leri ayıklayabilir ve aynı root cause'un başka örneklerini arayabilir.

Buradaki belirleyici fark şudur:

• SAST, finding üretmek için rule engine ve program modelini kullanır.
• Secure Code Review, güvenlik kararı vermek için insan muhakemesi ve application context'i kullanır.

İnsan reviewer'ın tool kullanması review'i otomatik hale getirmez. Benzer biçimde SAST çıktısına bir analistin severity vermesi de tek başına kapsamlı Secure Code Review yapıldığı anlamına gelmez.

Temel ayrım: Coverage ile context aynı şey değildir

SAST ve Secure Code Review arasındaki en önemli gerilim coverage ile context arasındadır.

Otomasyon aynı rule set'i bütün repository üzerinde tutarlı biçimde çalıştırabilir. Yorulmaz, dosya atlamaz ve her commit'te yeniden çalışabilir. Fakat uygulamanın neden var olduğunu, bir user role'ün hangi işleme izinli olması gerektiğini ve iki endpoint'in birlikte nasıl kötüye kullanılabileceğini kendiliğinden bilemez.

İnsan reviewer business context'i anlayabilir, beklenmeyen abuse case üretebilir ve code path'in arkasındaki security assumption'ı sorgulayabilir. Buna karşılık milyonlarca satırı her değişiklikte aynı yoğunlukta okuyamaz. Dikkat, süre ve uzmanlık sınırlıdır.

Bu farkı şu iki soruyla özetleyebiliriz:

SAST'ın sorusu:

Secure Code Review'in sorusu:

Birinci soru ölçeklenebilir ve tekrar edilebilirdir. İkinci soru context gerektirir.

Secure Code Review ve SAST karşılaştırması

Tablo iki yöntemin rakip değil, farklı evidence üreten kontroller olduğunu gösterir. SAST broad signal üretir. Secure Code Review bu sinyalin anlamını ve araçların göremediği security assumption'ları inceler.

Secure Code Review nasıl yürütülür?

Kaliteli manual review, reviewer'ın repository açıp rastgele dosya okuması değildir. İnceleme risk modeline ve izlenebilir bir yönteme dayanmalıdır.

1. Security context oluşturulur

Reviewer önce uygulamanın ne yaptığını öğrenir. Aşağıdaki bilgiler olmadan code line'ların güvenlik anlamı eksik kalır:

• Architecture diagram
• Component ve service inventory
• User role ve permission matrix
• Tenant modeli
• Data classification
• Authentication flow
• External integration ve trust boundary'ler
• Kritik business workflow'lar
• Security requirement'lar
• Threat model ve abuse case'ler
• Deployment modeli
• Önceki pentest ve incident bulguları

Bir payment approval function'ının güvenli olup olmadığı, kimlerin hangi tutara kadar onay verebildiği bilinmeden değerlendirilemez. Reviewer kodu görür, fakat beklenen business rule'ü bilmezse implementation'ın yanlış olduğunu söyleyemez.

2. Attack surface kod üzerinden haritalanır

Route, controller, resolver, handler, consumer, scheduled job, CLI command, webhook ve administrative interface'ler belirlenir. Yalnızca public HTTP endpoint'leri değil, application'a veri sokan bütün giriş yolları dikkate alınır.

Örneğin bir order kaydı şu kaynaklardan değiştirilebilir:

• REST API
• GraphQL mutation
• Admin panel
• Message queue consumer
• Batch import
• Webhook
• Support tool
• Database migration script

Authorization yalnızca REST controller'da uygulanıyorsa diğer entry point'ler aynı security control'ü bypass edebilir.

3. Security control'ler ve trust boundary'ler izlenir

Reviewer authentication, authorization, validation, encoding, cryptography, logging ve secret access gibi kontrollerin nerede uygulandığını belirler.

Sorulan sorular şunlardır:

• Kontrol merkezi mi, dağınık mı?
• Bütün entry point'ler aynı control path'i kullanıyor mu?
• User-controlled value trusted context'e dönüşürken ne oluyor?
• Tenant ID request'ten mi, authenticated session'dan mı geliyor?
• Service-to-service çağrıda user context korunuyor mu?
• Background job aynı policy'yi yeniden uyguluyor mu?
• Error ve timeout sırasında default karar nedir?
• Cache key security boundary'yi koruyor mu?
• Legacy API version aynı kontrolü içeriyor mu?

4. Positive ve negative flow birlikte incelenir

Functional test çoğunlukla doğru input ile beklenen sonuca odaklanır. Secure Code Review negative ve adversarial state'leri de arar:

• Input eksikse
• Birden fazla field birbiriyle çelişiyorsa
• Request sırası değiştiriliyorsa
• Onay sonrası data değiştiriliyorsa
• Dependency timeout oluyorsa
• Token expire sınırındaysa
• Aynı işlem eşzamanlı çağrılıyorsa
• User role işlem ortasında değişiyorsa
• Object başka tenant'a taşınıyorsa
• Retry aynı işlemi ikinci kez çalıştırıyorsa

Bir security control normal akışta çalışıp exception path'te atlanabilir.

5. Finding tek satırda bırakılmaz

Reviewer vulnerable line'ı bulduktan sonra call site'ları, sibling function'ları ve aynı helper'ı kullanan module'leri araştırır. Amaç yalnızca bir bug raporlamak değil, root cause ve yayılımı belirlemektir.

Örneğin findById(id) method'u tenant filter uygulamıyorsa şu sorular sorulur:

• Method kaç yerde çağrılıyor?
• Read, update ve delete işlemleri aynı repository'yi kullanıyor mu?
• Admin bypass yanlışlıkla standard user'a ulaşıyor mu?
• Aynı anti-pattern başka entity'lerde tekrar ediyor mu?
• Güvenli repository abstraction tasarlanabilir mi?
• Regression test bütün object-level authorization kuralını kapsayabilir mi?

Bu sistemik yaklaşım, tek endpoint fix'inin ardından aynı vulnerability'nin başka yerde kalmasını engeller.

Otomatik SAST taraması nasıl yürütülür?

SAST'ın “tool kuruldu, repository tarandı” şeklinde ele alınması sonuç kalitesini düşürür. Doğru bir SAST programında tool capability kadar configuration ve operasyon modeli önemlidir.

1. Language ve build coverage doğrulanır

Araç repository'deki bütün language'leri gerçekten destekliyor mu? Generated code, template, Infrastructure as Code, serverless function ve frontend bundle analiz ediliyor mu? Build gerektiren mode çalışıyor mu?

Bir scan job'ın exit code 0 dönmesi, bütün codebase'in analiz edildiği anlamına gelmeyebilir. Parser error, unresolved dependency, skipped module ve timeout bilgileri ayrıca kontrol edilmelidir.

2. Rule set ve framework model seçilir

Default rule set her uygulama için yeterli değildir. Programming language, framework, data access layer ve kurumsal secure coding standard'a uygun configuration gerekir.

Örneğin custom HTTP wrapper input source olarak tanınmıyorsa taint flow başlamaz. Kuruma özgü query helper sink olarak modellenmediyse SQL injection kaçabilir. Güvenli sanitizer araca tanıtılmamışsa aynı flow false positive üretebilir.

3. Baseline oluşturulur

Legacy repository ilk taramada binlerce finding üretebilir. Hepsini bir gecede pipeline gate yapmak development'ı durdurur ve ekiplerin tool'u devre dışı bırakmasına yol açar.

Sağlıklı modelde mevcut finding'ler triage edilir, riskli olanlar remediation planına alınır ve yeni code change'lerin yeni High veya Critical finding üretmesi engellenir. Baseline, geçmiş borcu görünmez yapmak için değil yeni borcun büyümesini durdurmak için kullanılır.

4. Finding'ler insan tarafından doğrulanır

OWASP ve NIST kaynakları da otomatik static analysis sonucunun insan review'iyle ele alınmasını vurgular. Tool'un verdiği source, sink, trace ve confidence bilgisi application context ile karşılaştırılır.

Triage sırasında şu sorular sorulur:

• Input gerçekten attacker-controlled mı?
• Code path reachable mı?
• Sanitizer doğru context için etkili mi?
• Başka bir control exploitation'ı engelliyor mu?
• Finding production code içinde mi?
• Test fixture veya sample credential mı?
• Runtime configuration riski aktive ediyor mu?
• Aynı root cause başka yerde var mı?

5. Sonuç development workflow'una girer

Finding PDF içinde kalmamalıdır. Repository, commit, owner, SLA, severity, suppression gerekçesi ve verification kaydı issue tracking sisteminde izlenmelidir.

“SAST bütün kodu tarar” cümlesi ne kadar doğru?

Bu ifade teknik olarak şartlıdır. Tool dosyaların tamamını görmüş olabilir, fakat hepsini aynı derinlikte analiz etmiş olmayabilir.

SAST coverage'ını etkileyen unsurlar şunlardır:

• Desteklenmeyen programming language
• Parser error
• Eksik dependency
• Build'in tamamlanmaması
• Generated source'un oluşmaması
• Dynamic language feature'ları
• Reflection ve runtime binding
• Framework magic
• Cross-service data flow
• Database veya message queue sınırı
• Native code ve managed code geçişi
• Analysis timeout
• Monorepo içinde yanlış root seçimi
• Exclude pattern'leri
• Rule'ın kapalı olması
• Source veya sink model'inin eksikliği
• Incremental scan'in yanlış baseline ile karşılaştırılması

Bu nedenle SAST raporunda finding sayısından önce scan health değerlendirilmelidir.

Sağlıklı bir scan özeti şunları göstermelidir:

• Taranması beklenen ve gerçekten taranan repository/module
• Analiz edilen language ve file sayısı
• Parse veya compile error'ları
• Skipped file ve exclusion'lar
• Çalışan rule pack'ler
• Timeout ve resource limit'leri
• Full scan veya incremental scan bilgisi
• Commit hash
• Tool ve rule version'ı

Yüzde 100 dosya erişimi, yüzde 100 vulnerability detection anlamına gelmez. SAST coverage bir test coverage yüzdesi gibi yorumlanmamalıdır.

“Manual reviewer bütün kodu okur” cümlesi ne kadar doğru?

Bu ifade de çoğu büyük proje için gerçekçi değildir. Milyonlarca satırlık codebase'in her satırını aynı dikkatle okumak hem ekonomik hem bilişsel açıdan mümkün olmayabilir.

Secure Code Review coverage'ı şu ölçütlerle tanımlanmalıdır:

• Kritik component'ler
• Trust boundary'ler
• Sensitive data flow'lar
• Authentication ve authorization control'leri
• High-risk function ve module'ler
• Public ve privileged entry point'ler
• Security-sensitive change'ler
• Threat model'deki yüksek riskli scenario'lar
• SAST ve pentest bulgularının işaret ettiği alanlar
• Representative implementation pattern'leri

Review “kaç satır okundu?” yerine “hangi güvenlik iddiası hangi code path üzerinden doğrulandı?” sorusuyla ölçülmelidir.

Örneğin 700 bin satırlık bir uygulamada bütün generated DTO'ları okumak yerine tenant isolation'ın controller, service, repository, cache ve background job boyunca nasıl korunduğunu incelemek daha değerlidir.

Aynı vulnerability sınıfında iki yöntem nasıl ayrışır?

Farkı en net biçimde teknik senaryolar gösterir.

Senaryo 1: Multi-tenant IDOR

Bir endpoint invoice ID alıyor ve kaydı döndürüyor.

SAST ne görür?

Tool, framework için özel authorization annotation eksikliğini rule olarak biliyorsa finding üretebilir. Ancak authorization service layer'da custom bir helper ile uygulanıyorsa veya requirement “kullanıcı yalnızca kendi tenant'ındaki invoice'u görebilir” şeklindeyse tool bunu çoğu zaman bilemez.

Secure Code Review ne görür?

Reviewer tenant ID'nin request parameter'dan mı, authenticated context'ten mi geldiğini inceler. Repository query'nin invoiceId yanında tenantId ile sınırlandırılıp sınırlandırılmadığını kontrol eder. Admin bypass, export endpoint, attachment download ve background job gibi alternatif path'leri araştırır.

Ayrım nerede oluşur?

SAST explicit missing check pattern'i arar. Reviewer ise hangi check'in business açısından gerekli olduğunu bilir.

Senaryo 2: SQL injection ve custom query wrapper

Uygulama kurum içinde geliştirilmiş bir database wrapper kullanıyor.

SAST ne görür?

Wrapper'ın execute method'u sink olarak tanımlanmışsa user input'tan query'ye kadar yüzlerce flow taranabilir. Tanımlanmamışsa ciddi SQL injection'lar görünmeyebilir. Güvenli parameterization method'u sanitizer olarak yanlış modellenirse false negative oluşabilir.

Secure Code Review ne görür?

Reviewer wrapper implementation'ını ve çağrı contract'ını inceler. Query fragment'ın hangi argument ile birleştirildiğini, parameter list'in gerçekten binding yapıp yapmadığını ve identifier allowlist'inin doğru uygulanıp uygulanmadığını kontrol eder.

Ayrım nerede oluşur?

SAST doğru model olduğunda geniş coverage sağlar. Reviewer modelin doğru olup olmadığını ve custom abstraction'ın güvenlik garantisini anlar.

Senaryo 3: SSRF allowlist bypass

Uygulama kullanıcıdan URL alıyor ve yalnızca izinli partner domain'lerine request göndermesi gerekiyor.

SAST ne görür?

User input'un HTTP client sink'ine ulaştığını bulabilir. Arada validatePartnerUrl() çağrısı varsa tool bunu sanitizer kabul edebilir veya tanımadığı için false positive üretebilir.

Secure Code Review ne görür?

Reviewer validation'ın string prefix ile mi, parse edilmiş hostname ile mi yapıldığını kontrol eder. Redirect sonrası destination'ın yeniden doğrulanıp doğrulanmadığını, DNS resolution ile private IP kontrolünün sırasını, userinfo, mixed encoding ve port davranışını inceler.

Ayrım nerede oluşur?

SAST “validation function çağrıldı” bilgisini görür. Reviewer validation'ın security requirement'ı gerçekten karşılayıp karşılamadığını değerlendirir.

Senaryo 4: Coupon kullanımında race condition

İş akışı coupon'ın kullanılmadığını kontrol ediyor, discount uyguluyor ve ardından coupon'ı kullanılmış olarak işaretliyor.

SAST ne görür?

Bazı gelişmiş analyzer'lar shared state ve concurrency problemine ilişkin sinyal üretebilir. Fakat database transaction isolation, distributed service ve business invariant kombinasyonu çoğu genel SAST rule'unun kapsamı dışındadır.

Secure Code Review ne görür?

Reviewer “coupon yalnızca bir kez kullanılabilir” invariant'ını bilir. Check ve update'in aynı atomic transaction içinde olmadığını, unique constraint bulunmadığını ve iki parallel request'in aynı state'i okuyabildiğini görür.

Ayrım nerede oluşur?

Tool genel code pattern'i analiz eder. İnsan, concurrency akışının finansal anlamını ve doğru atomicity sınırını yorumlar.

Senaryo 5: Webhook signature fail-open

Payment provider'dan gelen webhook, signature verification service'i timeout olduğunda işlenmeye devam ediyor.

SAST ne görür?

Riskli catch veya empty exception block rule'u finding üretebilir. Ancak timeout sonrası business operation'ın neden güvenli olmadığını ve fake payment confirmation'a dönüşebileceğini bilmez.

Secure Code Review ne görür?

Reviewer verification başarısız olduğunda default kararın reject olması gerektiğini belirler. Retry, duplicate event, idempotency ve order state transition'larını birlikte inceler.

Ayrım nerede oluşur?

SAST exception handling smell'i bulabilir. Reviewer bunun authentication boundary ve payment integrity üzerindeki etkisini kanıtlar.

Senaryo 6: Cryptographic API doğru, protocol yanlış

Uygulama modern bir encryption algorithm kullanıyor, fakat aynı nonce birden fazla message için tekrar ediliyor.

SAST ne görür?

Known unsafe algorithm kullanılmadığı için finding üretmeyebilir. Rule nonce'ın constant olduğunu görürse sinyal çıkarabilir, fakat nonce'ın distributed node'lar arasında tekrarlandığı durum runtime ve architecture context'i gerektirebilir.

Secure Code Review ne görür?

Reviewer nonce üretim kaynağını, uniqueness garantisini, node restart davranışını, key scope'unu ve storage modelini birlikte değerlendirir.

Ayrım nerede oluşur?

SAST API kullanımını doğrular. Reviewer cryptographic protocol'ün güvenlik özelliğini doğrular.

Senaryo 7: Mass assignment

Request body doğrudan domain model'e bind ediliyor. Model içinde role, isApproved veya creditLimit gibi user-controlled olmaması gereken field'lar bulunuyor.

SAST ne görür?

Framework için mass assignment rule'u varsa geniş bir candidate listesi çıkarabilir. Ancak hangi field'ın kullanıcı tarafından değiştirilebilir olması gerektiğini bilmediği için false positive üretebilir veya custom binder'ı kaçırabilir.

Secure Code Review ne görür?

Reviewer writable field'ları business role ve workflow'a göre değerlendirir. Approval state'in yalnızca başka bir service tarafından değiştirilebilmesi gerektiğini anlar ve explicit request DTO kullanımını önerir.

Ayrım nerede oluşur?

SAST technical binding pattern'ini görür. Reviewer field-level authorization requirement'ını bilir.

Senaryo 8: Second-order data flow

Kullanıcıdan alınan bir değer database'e kaydediliyor. Günler sonra başka bir service bu değeri spreadsheet export içinde formula olarak işliyor.

SAST ne görür?

Source ve sink farklı service, repository veya scan unit içindeyse data flow kopabilir. İki module aynı codebase içinde olsa bile persistence boundary ilişkiyi zorlaştırır.

Secure Code Review ne görür?

Reviewer data lineage'ı ve output context'i izler. İlk girişte zararsız görünen değerin export sırasında formula injection'a dönüştüğünü belirler.

Ayrım nerede oluşur?

SAST analiz sınırları içinde flow arar. İnsan farklı zaman ve component'lerdeki işleme adımlarını business workflow üzerinden birleştirir.

Senaryo 9: Gizli administrative bypass

Belirli bir header ve sabit değer geldiğinde support kullanıcısına geçici admin yetkisi veren unutulmuş test kodu bulunuyor.

SAST ne görür?

Hardcoded secret veya suspicious comparison rule'u finding üretebilir. Fakat değer obfuscate edilmişse, birkaç function'a bölünmüşse veya davranış custom ise tool bunu sıradan code olarak görebilir.

Secure Code Review ne görür?

Reviewer authorization modelinde dokümante edilmemiş branch'i fark eder. Bu branch'in neden var olduğunu, hangi route'larda çalıştığını ve audit log üretip üretmediğini araştırır.

Ayrım nerede oluşur?

SAST bilinen suspicious pattern'i arar. İnsan kodun beklenen ürün davranışıyla uyuşmayan niyetini sorgular.

Senaryo 10: Hassas verinin log'a yazılması

Application error durumunda request object'in tamamını logluyor.

SAST ne görür?

Sensitive field isimleri veya taint flow biliniyorsa password, token ya da personal data'nın log sink'ine ulaştığını bulabilir. Custom object serialization tool tarafından modellenmiyorsa kaçırabilir.

Secure Code Review ne görür?

Reviewer hangi field'ların data classification açısından hassas olduğunu, masking'in hangi katmanda yapıldığını ve exception sırasında normal logging policy'nin bypass edilip edilmediğini değerlendirir.

Ayrım nerede oluşur?

SAST veri akışını, reviewer ise verinin kurumsal ve hukuki anlamını yorumlar.

SAST hangi alanlarda Secure Code Review'den daha avantajlıdır?

Manual review'in daha derin olması her alanda daha verimli olduğu anlamına gelmez.

Tekrarlanan unsafe pattern'ler

Deprecated API, unsafe random function, certificate validation bypass, command execution ve weak cryptographic primitive gibi açık biçimde rule'a dönüştürülebilen pattern'ler otomasyon için uygundur.

Tool aynı pattern'i bütün repository boyunca tutarlı biçimde arar. İnsan reviewer bir örneği bulduktan sonra diğer kullanımları manual search ile bulabilir, fakat SAST bu işi sürekli ve daha hızlı yapar.

Büyük codebase ve monorepo

Yüzlerce service ve milyonlarca satır içeren repository'de broad visibility için SAST gereklidir. Her module'e aynı manual review eforunu ayırmak mümkün değildir.

SAST burada final karar değil, risk haritası sağlar. Hotspot, data flow ve yeni code change'ler reviewer önceliklendirmesine girdi olur.

Her commit'te tekrar

Secure Code Review yüksek riskli change'lerde ve belirli checkpoint'lerde yapılabilir. SAST ise pull request, merge, nightly build ve release pipeline içinde otomatik çalıştırılabilir.

Bu tekrar edilebilirlik regression yakalamak için değerlidir. Daha önce kaldırılan unsafe function yeni bir branch'te yeniden kullanılırsa rule aynı gün finding üretebilir.

Standard enforcement

Kuruma özgü secure coding standard makine tarafından kontrol edilebilir kurallara dönüştürüldüğünde SAST policy enforcement sağlar.

Örnekler:

• Raw SQL kullanımını yasaklamak
• Belirli cryptographic API'leri engellemek
• Direct file access yerine approved wrapper zorunluluğu
• Certificate verification disable option'ını yasaklamak
• Sensitive class'ların generic logger'a verilmesini engellemek
• Internal authorization helper dışında privilege change yapılmasını engellemek

Human reviewer policy'nin tasarımını ve istisnalarını yönetir. SAST tekrarlanan enforcement işini üstlenir.

Differential feedback

SAST yalnızca yeni veya değişen satırların ürettiği finding'leri gösterebilir. Developer pull request aşamasında hızlı feedback alır. Sorun henüz context tazeyken düzeltilir.

Bu model, bütün legacy finding'leri her pull request'te tekrar gösterip signal-to-noise oranını düşürmekten daha etkilidir.

Secure Code Review hangi alanlarda SAST'tan daha avantajlıdır?

Business logic ve state transition

Tool, bir işlemin teknik olarak nasıl yapıldığını görür. İnsan, o işlemin hangi sırada ve kim tarafından yapılması gerektiğini anlayabilir.

Discount, payment, approval, refund, invite, subscription ve entitlement akışları bu nedenle manual review gerektirir.

Custom authentication ve authorization

Framework annotation kullanan standart kontrol SAST tarafından modellenebilir. Kuruma özgü policy engine, tenant rule, delegated access ve object ownership mantığı insan context'i gerektirir.

MITRE CWE kayıtları da custom authorization ve authentication mekanizmalarında manual static analysis'in önemine işaret eder.

Security requirement doğrulaması

SAST finding odaklıdır. Secure Code Review requirement odaklı olabilir.

Örneğin requirement şudur:

Reviewer bu requirement'ı API response, admin UI, export, log, cache ve background notification path'leri boyunca doğrular. Tool'un bunu anlaması için hassas data type, role ve allowed representation model'lerinin özel olarak tanımlanması gerekir.

Design ve trust boundary hataları

Security control yanlış component'e yerleştirilmiş olabilir. Internal service request'i otomatik trusted kabul edebilir. Queue consumer message authentication yapmayabilir. Cache tenant boundary'yi taşımayabilir.

Bu problemler tek bir unsafe line değil, yanlış security assumption'dır.

Fail-open ve exceptional state

Dependency failure, timeout, parser error veya policy service kesintisi sırasında ne olduğu manual review ile daha anlamlı değerlendirilir.

SAST empty catch block bulabilir. Fakat bunun inventory sayfasında minor, payment authorization akışında critical olabileceğini business context belirler.

Root cause ve systemic remediation

Tool finding'e yakın fix önerebilir. İnsan reviewer sorunun neden tekrarlandığını ve hangi abstraction'ın değiştirilmesi gerektiğini belirleyebilir.

Örneğin 40 endpoint'te authorization eksikse çözüm 40 ayrı if eklemek olmayabilir. Tenant-scoped repository, centralized policy enforcement veya safe-by-default framework extension daha kalıcı çözüm olabilir.

False positive farkı nasıl yönetilmeli?

SAST'ın false positive üretmesi tool'un işe yaramadığı anlamına gelmez. Static analysis belirsizlik altında çalışır. Runtime value, external component ve custom sanitizer hakkında yeterli bilgi olmadığında güvenli tarafta kalıp finding üretebilir.

Yaygın false positive nedenleri şunlardır:

• Tool'un trusted source'u untrusted sayması
• Güvenli sanitizer'ı tanımaması
• Framework auto-escaping davranışını bilmemesi
• Infeasible code path'i reachable kabul etmesi
• Test veya sample code'u production sanması
• Compensating control'ü görmemesi
• Type veya alias çözümlemesinin eksik olması
• Cross-module flow'u yanlış kurması
• Generated code'u gerçek source gibi değerlendirmesi

False positive yönetiminin yanlış biçimi finding'i “not exploitable” etiketiyle gerekçesiz kapatmaktır.

Doğru triage kaydı şunları içermelidir:

• Finding neden false positive?
• Hangi code evidence bunu gösteriyor?
• Hangi sanitizer veya control etkili?
• Control değişirse suppression geçersiz olur mu?
• Suppression yalnızca bu instance'a mı, rule geneline mi uygulanıyor?
• Kararı kim ve ne zaman verdi?
• Sonraki tool veya framework version'ında yeniden kontrol edilecek mi?

Secure Code Review finding'leri de yanlış olabilir. Reviewer security requirement'ı yanlış anlamış, framework'ün korumasını gözden kaçırmış veya unreachable path'i riskli kabul etmiş olabilir. Human analysis otomatik olarak doğru değildir. Peer validation ve developer walkthrough önemlidir.

False negative farkı nasıl yönetilmeli?

False negative, gerçek vulnerability'nin yöntem tarafından bulunmamasıdır. Güvenlik açısından false positive'den daha sessiz ve daha tehlikelidir.

SAST false negative nedenleri

• Vulnerability için rule yoktur
• Custom source veya sink modellenmemiştir
• Language veya framework tam desteklenmiyordur
• Data flow service veya storage sınırında kopmuştur
• Analysis depth yetersizdir
• Sanitizer yanlış biçimde trusted kabul edilmiştir
• File scan dışında kalmıştır
• Build başarısızdır
• Dynamic dispatch çözülememiştir
• Business context gereklidir

Secure Code Review false negative nedenleri

• Riskli component scope dışında kalmıştır
• Reviewer ilgili framework'e yeterince hâkim değildir
• Threat model eksiktir
• Business requirement paylaşılmamıştır
• Süre nedeniyle code path incelenmemiştir
• Çok büyük diff dikkat dağılmasına yol açmıştır
• SAST'ın bulabileceği tekrarlanan pattern manual olarak kaçmıştır
• Review checklist yanlış güven alanlarına odaklanmıştır
• Developer açıklaması sorgulanmadan kabul edilmiştir

Bu nedenle hiçbir yöntem için “bulgu yoksa açık yoktur” denemez. Assurance, farklı verification yöntemlerinin sonuçlarını birleştirerek artırılır.

SAST bulgusu ile Secure Code Review bulgusu nasıl raporlanmalı?

İki rapor aynı template'e zorlanmamalıdır.

İyi bir SAST finding kaydı

• Repository ve commit hash
• Tool ve rule version'ı
• Rule ID ve CWE
• File ve line
• Source ve sink
• Data flow trace
• Confidence
• Reachability değerlendirmesi
• Framework ve sanitizer context'i
• Triage kararı
• Suppression gerekçesi
• Suggested code-level remediation
• Verification scan sonucu

İyi bir Secure Code Review bulgusu

• İhlal edilen security requirement
• Etkilenen business workflow
• Trust boundary
• Entry point ve code path
• Precondition ve user role
• Root cause
• Vulnerable implementation
• Abuse scenario
• Aynı pattern'in diğer örnekleri
• Technical ve business impact
• Systemic remediation
• Negative security test önerisi
• Fix review ve retest yöntemi

Örnek birleşik bulgu kaydı

Bu modelde SAST finding'i reviewer'a sinyal verir. Reviewer root cause'u anlar. Bulunan systemic pattern daha sonra custom SAST rule'a çevrilir. İnsan bilgisi otomasyona geri kazandırılır.

En güçlü model: İnsan bulur, otomasyon kalıcılaştırır

Secure Code Review ile SAST'ın birlikte kullanımındaki en yüksek değer, iki yönlü feedback loop'tan gelir.

SAST reviewer'ı yönlendirir

• Riskli data flow'ları gösterir
• High-risk API kullanımlarını listeler
• Büyük codebase içinde hotspot çıkarır
• Tekrarlanan pattern'i bulur
• Yeni diff içindeki regression'ı işaretler

Reviewer SAST'ı geliştirir

• Custom source ve sink tanımlar
• Güvenli sanitizer model'ini doğrular
• Kuruma özgü anti-pattern'i custom rule'a çevirir
• False positive suppression politikasını iyileştirir
• Tool'un kaçırdığı framework davranışını modeller
• Severity'yi business context ile yeniden belirler

Örneğin reviewer bir payment method'unda “user-provided amount server-side yeniden hesaplanmıyor” hatasını buldu. Bu business logic finding'inin tamamı genel SAST ile otomatikleşmeyebilir. Ancak riskli helper'ın doğrudan çağrılması, trusted pricing service yerine request amount kullanılması veya belirli validation function'ının eksikliği kuruma özgü rule'a dönüştürülebilir.

Her manual bulgu otomasyona uygun değildir. Yine de tekrar edebilir code property'ler rule, unit test, integration test veya policy-as-code haline getirilebilir.

Secure Code Review ne zaman zorunlu hale gelir?

Her küçük change için kapsamlı third-party review gerçekçi değildir. Risk bazlı trigger'lar tanımlanmalıdır.

Manual security review özellikle şu değişikliklerde güçlü biçimde gereklidir:

• Authentication veya session management değişikliği
• Authorization, role veya permission modeli değişikliği
• Multi-tenant isolation
• Payment, refund, balance ve financial transaction
• Cryptographic implementation veya key management
• File upload, archive extraction ve document processing
• Deserialization ve dynamic code execution
• Webhook ve service-to-service authentication
• Sensitive data storage, export ve logging
• Administrative ve support function
• Password reset, account recovery ve MFA flow
• New external integration
• Custom protocol veya security control
• Concurrency ve distributed transaction
• CI/CD, deployment ve secret management code'u
• Önceki incident ile ilişkili component
• SAST'ın desteklemediği language veya framework

Bu alanlarda “SAST clean” sonucu manual review ihtiyacını kaldırmaz.

SAST ne zaman mutlaka çalıştırılmalı?

SAST ise seçili checkpoint'lerle sınırlanmamalıdır. Uygun tool ve pipeline yapısı varsa şu aşamalarda çalışabilir:

• Developer IDE veya local pre-commit aşaması
• Pull request
• Merge öncesi quality gate
• Main branch full scan
• Nightly veya scheduled deep scan
• Release candidate
• Rule pack veya tool version güncellemesi
• Yeni vulnerability pattern'i öğrenildiğinde repo-wide tarama
• Incident sonrası benzer code pattern araması
• Remediation verification

Hızlı rule set developer feedback için, daha derin interprocedural analysis ise nightly veya release pipeline için ayrılabilir.

Baseline Review ve Diff-Based Review farkı

Secure Code Review tek formatta yapılmaz.

Baseline Review

Application veya kritik component'in mevcut durumunu kapsamlı biçimde inceler. Şu durumlarda uygundur:

• Yeni ürün ilk kez değerlendiriliyorsa
• Legacy application AppSec programına alınıyorsa
• Büyük architecture değişikliği yapıldıysa
• Acquisition sonrası codebase devralındıysa
• Incident sonrası root cause ve yayılım araştırılıyorsa
• Kritik compliance veya customer assurance ihtiyacı varsa

Baseline Review riskli module, control ve data flow'ların haritasını çıkarır. Her satırın aynı yoğunlukta okunması anlamına gelmez.

Diff-Based Review

Pull request, commit veya release arasındaki değişikliklere odaklanır. Günlük development'a daha iyi entegre olur.

Ancak diff tek başına context değildir. Beş satırlık değişiklik eski bir unsafe helper'ı reachable hale getirebilir. Reviewer değişen satırların caller ve callee ilişkisini, permission modelini ve ilgili testleri de incelemelidir.

Hybrid model

Önce baseline ile kritik architecture ve security control'ler anlaşılır. Sonra high-risk diff'ler sürekli review edilir. SAST bütün change'lerde çalışır ve yeni sinyalleri reviewer'a taşır.

Bu model hem context'i korur hem ölçeklenebilirlik sağlar.

CI/CD içinde iki yöntem nasıl konumlandırılmalı?

İyi tasarlanmış pipeline her finding'i aynı gate'e bağlamaz.

Developer feedback katmanı

Hızlı SAST rule'ları IDE veya pull request üzerinde çalışır. Yüksek confidence yeni finding doğrudan developer'a gösterilir. Feedback süresi kısa tutulur.

Merge gate katmanı

Yeni Critical ve High finding, hardcoded active secret, unsafe cryptographic disable veya banned API gibi net policy ihlalleri merge'i durdurabilir.

Gate uygulanırken şu bilgiler bulunmalıdır:

• Finding yeni mi?
• Confidence yeterli mi?
• Rule ekip için tune edildi mi?
• Owner ve exception workflow'u belli mi?
• Tool başarısızsa fail-open mı, fail-closed mu davranacak?

SAST job teknik olarak çalışmazken pipeline'ın “temiz” kabul edilmesi ciddi bir süreç hatasıdır.

Manual review gate katmanı

Repository label, changed path, data classification veya threat model'e göre high-risk change'ler security reviewer onayına gider.

Örnek trigger'lar:

• /auth/, /payments/, /crypto/, /admin/ path'leri
• Permission schema değişikliği
• New public endpoint
• Sensitive data model değişikliği
• Infrastructure veya IAM policy değişikliği
• SAST'ta belirli high-risk rule
• Büyük dependency veya framework migration

Nightly ve release assurance katmanı

Full SAST, deeper analysis, SCA, secret scanning ve gerekirse DAST birlikte çalışır. Kritik release öncesinde odaklı Secure Code Review ve sızma testi eklenir.

Kaynak kod analizi ile runtime doğrulamanın neden farklı olduğunu Kaynak kod analizi ile sızma testi aynı problemi çözmez: nerede ayrışır? yazımızda ayrıntılı ele aldık.

Pipeline gate nasıl seçilmeli?

Her SAST finding merge'i durdurursa ekip kısa sürede alert fatigue yaşar. Hiçbir finding gate değilse SAST yalnızca dashboard üretir.

Gate kararı şu unsurlara dayanmalıdır:

• Rule precision geçmişi
• Finding confidence
• Vulnerability class
• Değişikliğin risk seviyesi
• Asset criticality
• Reachability
• New code veya legacy code olması
• Active secret gibi acil durum
• Compensating control
• Exception expiry tarihi

Örnek gate politikası:

SAST aracı seçerken Secure Code Review ekibi neden sürece katılmalı?

Tool seçimi yalnızca procurement ve DevOps kararı olmamalıdır. Uygulamanın language, framework ve vulnerability profile'ını bilen reviewer'lar pilot sürece katılmalıdır.

Değerlendirme kriterleri şunlardır:

• Kullanılan language ve framework için gerçek analiz derinliği
• Build-required ve buildless mode farkı
• Interprocedural ve cross-file data flow
• Custom source, sink ve sanitizer tanımı
• Custom rule/query desteği
• Incremental scan ve full scan davranışı
• Monorepo desteği
• IDE, repository ve issue tracker entegrasyonu
• Scan health ve coverage görünürlüğü
• False positive suppression yönetimi
• Audit trail
• On-premise veya air-gapped çalışma seçeneği
• Source code retention ve data residency
• Rule update sıklığı
• API ve automation capability
• License model ve gerçek pipeline maliyeti

Vendor'ın demo repository'sindeki başarı, kurumun custom framework'ünde aynı sonucu garanti etmez. NIST SATE çalışmaları da static analysis aracının kurumun kendi codebase'i ve use case'i üzerinde değerlendirilmesinin önemine işaret eder.

Pilot sırasında seeded test case, geçmiş gerçek finding ve bilinen safe pattern'ler kullanılabilir. Amaç yalnızca daha çok finding üreten tool'u seçmek değil, yararlı signal-to-noise oranını ölçmektir.

Secure Code Review hizmeti alırken ne sorulmalı?

“Manual review dahildir” ifadesi tek başına yeterli değildir.

Teklifte şu soruların cevabı bulunmalıdır:

• Baseline mi, diff-based mi review yapılacak?
• Hangi repository, branch ve commit incelenecek?
• Hangi component ve data flow öncelikli?
• Architecture ve threat model review'e dahil mi?
• SAST tool'u kullanılacak mı?
• Tool çıktıları manual doğrulanacak mı?
• Reviewer hangi language ve framework deneyimine sahip?
• Business logic ve authorization özel olarak incelenecek mi?
• Review coverage nasıl raporlanacak?
• Bulgu için file, function ve code path verilecek mi?
• Root cause ve systemic pattern araştırılacak mı?
• Fix review dahil mi?
• Source code nerede işlenecek?
• Local copy ve temporary artifact ne zaman silinecek?
• Review sırasında bulunan secret nasıl bildirilecek?
• Rapor code snippet'leri nasıl korunacak?

Sadece SAST scanner çalıştırılıp analyst tarafından export edilen sonuç, kapsamlı Secure Code Review olarak sunulmamalıdır.

Efor nasıl hesaplanmalı?

SAST tarama süresi ile Secure Code Review eforu aynı ölçütle hesaplanamaz.

SAST eforunu etkileyen faktörler

• Repository sayısı
• Language ve framework çeşitliliği
• Build complexity
• LOC ve module sayısı
• Scan mode
• Tool deployment modeli
• Rule tuning ihtiyacı
• Initial finding hacmi
• Integration sayısı
• Triage ownership

Secure Code Review eforunu etkileyen faktörler

• Architecture karmaşıklığı
• Kritik business workflow sayısı
• Authentication ve authorization modeli
• Tenant ve role matrisi
• Sensitive data flow sayısı
• Custom framework ve security control'ler
• Code quality ve documentation seviyesi
• Language ve framework uzmanlığı
• Review türü
• Önceki finding ve incident geçmişi
• İncelenecek change büyüklüğü

LOC yardımcı bir kapasite ölçüsüdür, fakat tek başına fiyatlandırma veya coverage ölçütü olmamalıdır. Bin satırlık custom token verifier, yüz bin satırlık generated CRUD code'dan daha fazla güvenlik eforu gerektirebilir.

Başarı nasıl ölçülmeli?

Finding sayısı başarı metriği değildir. Çok finding üreten tool daha iyi, daha az finding çıkaran reviewer daha zayıf kabul edilemez.

SAST için anlamlı metrikler

• Scan success ve health oranı
• Desteklenen repository ve language coverage'ı
• New code finding sayısı
• Manual validation sonrası precision
• False positive oranı
• Finding yaş ortalaması
• Mean time to remediate
• Suppression sayısı ve expiry durumu
• Tekrarlayan vulnerability class
• Custom rule adoption
• Pipeline feedback süresi
• Tool failure'ın temiz sonuç sayılma oranı

Secure Code Review için anlamlı metrikler

• İncelenen security requirement sayısı
• Kapsanan critical component ve data flow
• Bulunan systemic root cause sayısı
• Aynı root cause'a bağlı ek instance sayısı
• Regression test'e çevrilen finding oranı
• Custom SAST rule'a çevrilen pattern sayısı
• Fix review başarı oranı
• Production'a kaçan vulnerability oranı
• Aynı vulnerability class'ın tekrarı
• Review feedback lead time

Birleşik program için anlamlı metrikler

• SAST'ın işaretleyip reviewer'ın doğruladığı finding oranı
• Reviewer'ın bulduğu, SAST'ın kaçırdığı vulnerability sınıfları
• Manual bulgudan üretilen otomatik control sayısı
• False positive tuning sonrası developer kabul oranı
• Release öncesi ve production sonrası bulgu dağılımı
• Root cause remediation sonrası tekrar oranı

Metriklerin amacı ekipleri finding üretmeye zorlamak değil, unknown risk'i ve tekrar eden hatayı azaltmaktır.

LLM ve AI destekli code review bu ayrımı değiştirir mi?

LLM tabanlı code review araçları source code'u açıklayabilir, suspicious logic önerebilir, finding triage'ına yardımcı olabilir ve klasik rule'ların yakalamadığı pattern'ler hakkında hypothesis üretebilir. Bu kabiliyet değerlidir, fakat “AI kullanan tool artık Secure Code Review yapıyor” sonucu otomatik olarak çıkmaz.

Değerlendirilmesi gereken sınırlar şunlardır:

• Context window bütün code path'i kapsıyor mu?
• Model repository'nin tamamını mı, seçili snippet'i mi görüyor?
• Architecture ve business requirement modele verildi mi?
• Üretilen finding deterministic ve tekrar edilebilir mi?
• Data flow gerçekten kanıtlanmış mı, tahmin mi edilmiş?
• Hallucinated API veya code path var mı?
• Source code external model provider'a gönderiliyor mu?
• Prompt, response ve artifact retention nasıl yönetiliyor?
• Model version değiştiğinde sonuç nasıl karşılaştırılacak?
• Finding uzman reviewer tarafından doğrulanıyor mu?

LLM, SAST ile manual review arasında yeni bir yardım katmanı oluşturabilir. Fakat security ownership, evidence ve validation ihtiyacını kaldırmaz. AI-generated finding de source, sink, precondition, code path ve impact kanıtı taşımalıdır.

Source code gizliliği iki yöntemde nasıl değişir?

SAST platformu cloud-hosted ise repository içeriği veya derived representation kurum dışına çıkabilir. Manual reviewer da local clone alabilir. İki yöntemde de data handling açıkça tanımlanmalıdır.

Kontrol listesi şunları içermelidir:

• Source code hangi environment'ta analiz ediliyor?
• Cloud upload var mı?
• Data hangi ülkede tutuluyor?
• Tool training veya telemetry için kod kullanıyor mu?
• Retention süresi ne?
• Repository erişimi named account ve MFA ile mi?
• Least privilege uygulanıyor mu?
• Log ve temporary artifact'lar ne zaman siliniyor?
• Reviewer'ın cihazı ve storage alanı şifreli mi?
• Rapor içindeki snippet'ler maskeleniyor mu?
• Secret finding için secure communication channel var mı?
• On-premise veya air-gapped mode gerekiyor mu?

Yüksek hassasiyetli source code için hem SAST engine hem manual review müşteri ortamında çalıştırılabilir.

Compliance açısından hangisi gerekir?

Compliance requirement'ı kullanılan standarda, scope'a ve assurance seviyesine göre değişir. Ancak modern çerçeveler genellikle tek bir tekniğe güvenmez.

NIST SSDF, code review ve code analysis yöntemlerinin software lifecycle aşamasına göre seçilmesini, static analysis finding'lerinin insan tarafından review edilmesini ve sonuçların development workflow'unda triage edilmesini örnekler. NISTIR 8397 ise threat modeling, automated testing, static scanning, heuristic secret detection ve human review dahil birden fazla developer verification tekniğini birlikte ele alır.

OWASP ASVS 5.0.0, application security requirement'larını sözleşme ve verification kapsamı için kullanılabilir hale getirir. ASVS bir SAST rule listesi değildir. Requirement'ın hangi yöntemle doğrulanacağı uygulamanın riskine ve kontrolün yapısına göre seçilir.

Compliance için tool report sunmak, security requirement'ın karşılandığını her zaman kanıtlamaz. Benzer biçimde “manual review yapıldı” ifadesi de scope, version, reviewer coverage ve evidence olmadan yeterli değildir.

Karar tablosu: Hangi durumda hangisi öncelikli?

Yaygın hatalar

Ham SAST çıktısını Secure Code Review raporu olarak sunmak

Tool finding'lerine analyst severity eklenmesi değerli triage'dır. Fakat architecture, trust boundary, business logic ve sistematik code path incelemesi yapılmadıysa hizmetin kapsamı açıkça “SAST ve manual validation” olarak adlandırılmalıdır.

SAST temizse manual review'e gerek olmadığını düşünmek

Clean scan yalnızca tool'un etkin rule, model ve coverage'ı içinde finding bulunmadığını gösterir. Custom authorization, business logic, race condition ve fail-open riskleri devam edebilir.

Manual review varsa SAST'ı gereksiz görmek

İnsan reviewer context konusunda güçlüdür, fakat büyük codebase'deki tekrarlanan pattern'i her commit'te aynı tutarlılıkla tarayamaz. SAST genişlik ve süreklilik sağlar.

Tool finding'lerini doğrulamadan developer'a göndermek

False positive hacmi developer güvenini azaltır. Bir süre sonra gerçek finding'ler de gürültü olarak görülür. Security team triage, tuning ve owner desteği sağlamalıdır.

Yalnızca OWASP Top 10 label'ına bakmak

Bir tool'un “OWASP Top 10 coverage” iddiası her requirement ve vulnerability instance'ını bulduğu anlamına gelmez. Kategoriler geniştir ve bazıları design ile business context gerektirir.

Scan health'i kontrol etmemek

Build fail, parser error veya skipped module varken raporun düşük finding üretmesi yanlış güven yaratır. Scan completeness ayrı control olmalıdır.

Review scope'unu yalnızca LOC ile tanımlamak

Security-sensitive code yoğunluğu her module'de aynı değildir. Scope critical flow, component ve requirement üzerinden yazılmalıdır.

Suppression'ları süresiz bırakmak

Bugün güvenli olan flow, sanitizer değiştiğinde riskli hale gelebilir. Suppression owner, rationale ve expiry taşımalıdır.

Manual bulguyu otomasyona geri taşımamak

Aynı bug class bir kez bulunduğunda repository genelinde aranmalı ve mümkünse custom rule veya regression test'e dönüştürülmelidir.

Sonuç: SAST genişliği, Secure Code Review anlamı sağlar

Secure Code Review ile otomatik SAST taraması arasındaki fark “insan daha akıllı, tool daha hızlı” cümlesinden daha derindir.

SAST, önceden tanımlı güvenlik bilgisini geniş codebase üzerinde tekrar edilebilir hale getirir. Riskli API, unsafe pattern ve source-to-sink data flow'ları sürekli arar. Yeni code change'lere hızlı feedback verir ve daha önce öğrenilen vulnerability pattern'inin yeniden ortaya çıkmasını engellemeye yardımcı olur.

Secure Code Review ise kodun neden güvenli olması gerektiğini sorar. User role, tenant, business invariant, trust boundary, failure state ve architecture ilişkisini değerlendirir. Bir finding'in yalnızca hangi satırda olduğunu değil, hangi security assumption'ın kırıldığını ve aynı root cause'un nerelere yayıldığını gösterir.

İki yöntemin de tek başına eksik kaldığı alan vardır.

Sadece SAST kullanan kurum, tool'un rule ve model dünyasının dışında kalan business risk'leri kaçırabilir. Sadece manual review kullanan kurum, büyük repository'deki tekrarlanan code pattern'leri ve her commit'teki regression'ları sürdürülebilir biçimde izleyemeyebilir.

Doğru model şudur:

1. 1Security requirement ve threat scenario'ları tanımlayın.
2. 2SAST'ı her code change için hızlı ve ölçülebilir feedback katmanına dönüştürün.
3. 3Scan health, rule coverage ve false positive tuning'i yönetin.
4. 4High-risk component ve değişiklikleri Secure Code Review'e alın.
5. 5SAST finding'lerini application context ve insan muhakemesiyle doğrulayın.
6. 6Manual bulguların benzerlerini repository genelinde arayın.
7. 7Tekrarlanabilir pattern'leri custom rule ve regression test'e çevirin.
8. 8Fix'i source code üzerinde ve gerekiyorsa runtime'da yeniden doğrulayın.

Secnodex, Secure Code Review çalışmalarını ham scanner çıktısı olarak sunmaz. SAST görünürlüğünü manual data flow, authorization, business logic ve root cause analiziyle birleştirerek bulgunun hangi security requirement'ı ihlal ettiğini ve nasıl sistemik biçimde giderileceğini ortaya koyar. Uygulamanız için SAST, Manual Source Code Review veya birleşik kaynak kod analizi kapsamı oluşturmak üzere Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• OWASP Secure Code Review Cheat Sheet
• OWASP Code Review Guide
• OWASP Static Code Analysis
• OWASP Application Security Verification Standard 5.0.0
• OWASP Top 10:2025 – Establishing a Modern Application Security Program
• NIST SP 800-218: Secure Software Development Framework
• NISTIR 8397: Guidelines on Minimum Standards for Developer Verification of Software
• NIST SATE VI Report
• MITRE CWE-862: Missing Authorization
• MITRE CWE-863: Incorrect Authorization