CI/CD'ye SAST Eklerken En Sık Yapılan 7 Hata

Bir kurum SAST ürününü satın alıyor. Platform ekibi scanner'ı bütün repository'lere bağlayıp pipeline'a yeni bir security stage ekliyor. İlk gün yüzlerce finding oluşuyor. Bazı application'larda build saatlerce uzuyor. Developer'lar kendi değiştirmedikleri legacy code nedeniyle merge yapamıyor. Security ekibi false positive taleplerine yetişemiyor.

İkinci hafta project'ler sırayla exception istemeye başlıyor.

Bir ay sonra SAST job'ı hâlâ pipeline'da görünür durumda. Fakat allow_failure: true benzeri bir ayarla sonucu release'i etkilemiyor. Finding'ler dashboard'da birikiyor, suppression'ların owner'ı bilinmiyor ve kimse güvenlik adımının gerçekten hangi code'u taradığını kontrol etmiyor.

Yönetim tarafında ise tablo farklı görünüyor:

Teknik olarak bu cümle doğrudur. Güvenlik açısından ise neredeyse hiçbir şey söylemez.

CI/CD'ye SAST eklerken en sık yapılan 7 hata, scanner seçiminden çok implementation ve operating model ile ilgilidir. SAST'ın değer üretmesi için doğru code'un doğru context ile taranması, finding'in developer'a zamanında ulaşması, gerçek riskin ayırt edilmesi, quality gate'in güvenilir çalışması ve bütün kararların yaşam döngüsü içinde izlenmesi gerekir.

Bu yazıda yalnızca hangi hataların yapıldığını sıralamayacağız. Her hata için neden oluştuğunu, pipeline'da nasıl göründüğünü, hangi yanlış metric'le saklandığını ve kalıcı çözümün nasıl kurulacağını inceleyeceğiz.

SAST'ı CI/CD'ye eklemek gerçekte ne anlama gelir?

SAST, application çalıştırılmadan source code, bytecode veya ilgili representation üzerinde security weakness arar. Data flow, control flow, taint propagation, syntax pattern, framework behavior ve rule set yaklaşımı kullanılan engine'e göre değişir.

CI/CD integration ise yalnızca scanner binary'sini çalıştırmak değildir. En az altı capability'nin birlikte kurulmasıdır:

1. 1Trigger: Analiz hangi event'te çalışacak?
2. 2Coverage: Hangi repository, language, module ve generated artifact taranacak?
3. 3Context: Scanner code'u doğru build ve framework bilgisiyle anlayabiliyor mu?
4. 4Decision: Hangi finding hangi koşulda merge veya release'i durduracak?
5. 5Workflow: Finding kime, hangi evidence ile ve ne kadar sürede ulaşacak?
6. 6Governance: Suppression, risk acceptance, exception ve metric nasıl yönetilecek?

Bu parçaların biri eksik olduğunda pipeline yeşil olsa bile güvenlik coverage'i oluşmayabilir.

NIST Secure Software Development Framework, human-readable code'un vulnerability tespiti ve security requirement doğrulaması amacıyla review veya analysis edilmesini PW.7 altında ele alır. Buradaki amaç scanner çalıştırmış olmak değil, vulnerability'yi release öncesinde düzeltilebilir hale getirmektir.

SAST neyi bulabilir, neyi tek başına kanıtlayamaz?

CI/CD policy tasarlanırken önce tool boundary anlaşılmalıdır.

SAST aşağıdaki sınıflarda güçlü signal üretebilir:

• Injection'a giden untrusted data flow
• Unsafe API kullanımı
• Hard-coded secret pattern'leri, ürünün capability'sine bağlı olarak
• Path traversal ve file access riskleri
• Weak cryptography kullanımı
• Unsafe deserialization pattern'leri
• SSRF'e giden controllable URL flow'ları
• Output encoding eksiklikleri
• Resource management problemleri
• Language ve framework'e özgü security anti-pattern'ler

Fakat SAST tek başına şu sonuçları garanti edemez:

• Production'da aynı code path'in erişilebilir olması
• Runtime compensating control'ün gerçekten çalışması
• Object-level authorization'ın bütün business relationship'lerde doğru olması
• Multi-step business logic'in kötüye kullanılamaması
• Deployed configuration'ın güvenli olması
• WAF veya API gateway behavior'ı
• Dependency'nin bilinen vulnerability taşımaması
• Container image ve IaC configuration güvenliği
• Secret'ın geçmiş commit'te veya external system'de bulunmaması
• Gerçek exploitability ve business impact

Bu nedenle SAST, SCA, secret scanning, IaC scanning, container scanning, DAST, pentest ve Secure Code Review ile aynı kontrol değildir.

SAST'ın hangi açıkları bulup hangilerini kaçırdığını SAST nedir, hangi açıkları bulur, hangilerini kaçırır? yazımızda ayrıntılı biçimde ele alıyoruz.

SAST pipeline'ın hangi aşamalarında çalışmalı?

Tek bir scan zamanı bütün ihtiyaçları karşılamaz. Hız ve depth farklı katmanlarda dengelenmelidir.

GitHub code scanning documentation, push ve pull request event'lerinde scan'in yeni vulnerability girişini engellemeye yardımcı olduğunu, scheduled scan'in ise yeni geliştirilen query ve araştırmalarla daha önce görünmeyen issue'ları gösterebildiğini belirtir.

Bu katmanların hepsini ilk günde çalıştırmak gerekmez. Ancak yalnızca pull request scan'i yapıp yeni rule set'lerin mevcut code üzerindeki etkisini hiç ölçmemek de coverage gap oluşturur.

Hata 1: İlk günden bütün bulgularla build'i kırmak

En sık görülen implementation hatası budur. SAST açılır, ilk scan'de binlerce existing finding oluşur ve policy High veya üzerindeki her şeyi blocking yapar.

Amaç security'yi zorunlu hale getirmektir. Sonuç çoğu zaman tam tersidir:

• Developer kendi değiştirmediği legacy finding nedeniyle engellenir
• False positive henüz ölçülmeden release durur
• Security ekibi triage queue'sunu yönetemez
• Business-critical hotfix'ler exception talep eder
• Team'ler pipeline job'ını bypass etmeye çalışır
• Genel ve süresiz exemption'lar oluşur
• SAST güvenilir kontrol değil delivery engeli olarak görülür

Neden yanlış çalışır?

Quality gate yalnızca finding severity'sine değil detection confidence, code ownership, change scope ve risk acceptance state'ine ihtiyaç duyar. İlk gün bu context'lerin hiçbiri hazır değildir.

Bir scanner'ın High etiketi, finding'in production'da exploitable olduğunu otomatik olarak kanıtlamaz. Aynı şekilde Medium finding düşük business impact anlamına gelmez.

Doğru rollout nasıl olmalı?

OWASP SAMM automated security testlerin frequency ve code coverage'inin aşamalı artırılmasını önerir. Resmî GitLab application security rollout yaklaşımı da pilot ve genişleme phase'lerini ayırır.

Pratik bir rollout şu şekilde kurulabilir:

#### Phase 1: Observe

• Temsil gücü yüksek birkaç repository seçilir
• Pipeline non-blocking çalışır
• Language ve framework coverage doğrulanır
• Scan duration ölçülür
• İlk finding'ler manual triage edilir
• Duplicate ve false positive oranı görülür
• Developer feedback toplanır

#### Phase 2: Calibrate

• Rule set application type'a göre düzenlenir
• High-confidence finding'ler belirlenir
• Existing debt baseline'e alınır
• Owner ve SLA modeli kurulur
• Suppression reason ve expiry zorunlu hale getirilir
• Pull request annotation standardize edilir

#### Phase 3: Progressive gate

• Yalnızca yeni ve high-confidence Critical finding'ler blocking olur
• Sonra risk profiline göre yeni High finding'ler eklenir
• Critical module'lerde daha sıkı policy uygulanır
• Exception süreli ve approval'a bağlı olur

#### Phase 4: Scale

• Repository grupları risk tier'ına göre eklenir
• Full ve scheduled scan'ler yaygınlaştırılır
• Custom rule ve framework model'leri geliştirilir
• Metrics üzerinden policy düzenli iyileştirilir

Gate hiçbir zaman blocking olmamalı mı?

Olmalı. Fakat güvenilir finding seti ve işletilebilir exception modeli oluştuğunda.

Örnek başlangıç policy'si:

Quality gate'in amacı sıfır finding göstermek değil, kabul edilemez yeni riskin doğrulanmadan ilerlemesini engellemektir.

Hata 2: Existing security debt ile yeni finding'i ayırmamak

Yıllardır geliştirilen bir repository'de SAST ilk kez çalıştığında çok sayıda finding çıkması normaldir. Bunların tamamını aynı sprint içinde kapatmaya çalışmak gerçekçi değildir. Hiçbirini gate'e bağlamamak da mevcut borcun süresiz kalmasına yol açar.

İki uç yaklaşım da başarısızdır:

• “Önce bütün eski finding'ler kapanmadan merge yok”
• “Bunlar legacy, hiçbirini dikkate almayalım”

Baseline ne işe yarar?

Baseline, belirli bir commit ve tarihte bilinen finding setini kaydeder. Yeni change sonrasında şu soruyu cevaplamayı sağlar:

Baseline finding'i riskten muaf tutmaz. Yalnızca new-code gate ile existing-debt programını birbirinden ayırır.

Kötü baseline nasıl görünür?

• Bütün finding'ler tek tıkla kabul edilir
• Owner atanmaz
• Severity ve asset criticality değerlendirilmez
• Baseline tarihi bilinmez
• Branch değişince finding identity kaybolur
• Code taşındığında eski finding yeni gibi görünür
• Yeni rule eklendiğinde bütün sonuçlar plansız biçimde debt'e atılır
• Baseline hiçbir zaman küçülmez

Bu durumda baseline risk yönetimi değil görünmezlik mekanizması olur.

Existing debt nasıl yönetilmeli?

Finding'ler application criticality ve risk context'iyle gruplandırılabilir:

1. 1Internet-facing ve exploitable görünümü yüksek Critical path'ler
2. 2Authentication, authorization ve secret handling code'u
3. 3Shared library ve platform component'leri
4. 4Frequently changed hot spot'lar
5. 5Decommission planı olan legacy module'ler

Her grup için owner, remediation target ve validation yöntemi belirlenir.

New code policy nasıl kurulmalı?

New code yalnızca yeni eklenen satır değildir. Değiştirilen function'ın existing unsafe sink'i, yeni caller nedeniyle reachable hale gelebilir. Refactor data flow'u değiştirebilir. Dependency upgrade generated code'u etkileyebilir.

Bu nedenle diff-aware analysis yararlıdır, fakat full context analysis'in yerine geçmemelidir. Pull request hızlı feedback üretirken default branch ve scheduled scan daha geniş code graph'ı incelemelidir.

Baseline ne zaman yenilenmeli?

Baseline şu durumlarda kontrollü olarak yeniden değerlendirilebilir:

• Scanner engine veya major rule set değiştiğinde
• Repository büyük ölçüde yeniden yapılandırıldığında
• Branching model değiştiğinde
• Application ownership değiştiğinde
• False positive deduplication logic'i değiştiğinde

Baseline reset işlemi toplu risk kabulüne dönüşmemelidir. Eski ve yeni finding seti arasında mapping ve delta raporu üretilmelidir.

Hata 3: Yanlış code ve build context'i tarayıp coverage var sanmak

Pipeline job'ının success dönmesi scanner'ın application'ı doğru analiz ettiği anlamına gelmez.

Sahada görülen coverage problemleri şunlardır:

• Monorepo içinde yalnızca root directory taranır
• Submodule'ler checkout edilmez
• Shallow clone nedeniyle diff veya history analizi bozulur
• Generated source analysis öncesinde üretilmez
• Compiled language doğru build edilemez
• Private package registry erişimi olmadığı için dependency resolution başarısız olur
• Custom framework source ve sink model'i bulunmaz
• Exclusion pattern kritik directory'yi dışarıda bırakır
• Test code ile production code ayrımı yanlış yapılır
• Unsupported language sessizce atlanır
• Scan container'ında gerekli SDK bulunmaz
• Scanner timeout sonrasında partial result gönderir
• Pull request fork context'inde farklı permission ile çalışır

En tehlikeli durum job'ın başarısız olması değil, partial analysis'in başarılı gibi görünmesidir.

Coverage hangi katmanlarda ölçülmeli?

#### Repository coverage

Hangi repository'ler SAST policy'ye bağlı? Archived, fork, template ve experimental project'ler nasıl sınıflandırılıyor?

#### Language coverage

Repository'deki hangi language ve version'lar scanner tarafından destekleniyor? Unsupported file sayısı görünür mü?

#### Module coverage

Hangi application module, package, service ve generated component analize girdi?

#### Build coverage

Compilation veya dependency resolution tamamlandı mı? Build flag'leri production'a benziyor mu?

#### Rule coverage

Relevant vulnerability class'ları için hangi query suite veya rule pack etkin? Default rule set application'ın framework'ünü biliyor mu?

#### Trigger coverage

Pull request, default branch, release branch ve scheduled scan beklenen event'lerde gerçekten çalışıyor mu?

Query suite seçimi neden önemlidir?

GitHub CodeQL documentation'da extended query suite'in daha fazla query içerdiği, fakat daha düşük precision nedeniyle daha fazla false positive üretebileceği belirtilir. Bu, basit bir trade-off'u gösterir:

Pull request gate için high-precision rule set, scheduled deep scan için daha geniş query seti kullanılabilir. İki sonuç aynı workflow ile yönetilmek zorunda değildir.

Custom framework problemi

Kurumun kendi ORM wrapper'ı, HTTP client'ı, template engine'i veya authorization helper'ı varsa generic scanner data flow'u anlayamayabilir.

Örneğin scanner standard SQL sink'ini tanır, fakat kurumun executeBusinessQuery() wrapper'ını sink olarak modellemez. Sonuçta injection path görünmez. Diğer yönde güvenli wrapper sanitizer olarak tanınmadığı için çok sayıda false positive oluşur.

Çözüm custom source, sink, sanitizer ve summary model'leridir. Bu modeller product security ile platform engineering tarafından version control altında yönetilmelidir.

Coverage acceptance kriteri

Her scan aşağıdaki telemetry'yi üretmelidir:

• Analyzed repository ve commit SHA
• Scanner ve rule set version'ı
• Detected language'ler
• Supported ve unsupported file sayısı
• Analyzed line veya file count
• Excluded path'ler
• Build ve extraction status
• Timeout ve partial analysis durumu
• Finding upload status
• Baseline karşılaştırma sonucu

Bu bilgi yoksa “SAST çalıştı” iddiası yalnızca job status'üne dayanır.

Hata 4: Scanner severity'sini gerçek risk sanmak

SAST finding'i genellikle vulnerability class, data flow, confidence ve tool-defined severity ile gelir. Bu değerler triage için başlangıçtır. Release kararı için tek başına yeterli değildir.

Aynı rule tarafından bulunan iki path farklı risk taşıyabilir:

• Birinci path yalnızca local developer utility içinde, production build'e girmeyen bir command execution pattern'idir.
• İkinci path internet-facing admin API'de, unauthenticated input'u operating system command'ına taşır.

İkisi de tool ekranında Command Injection - Critical görünebilir. Gerçek exposure aynı değildir.

Tersi durum da mümkündür. Medium olarak işaretlenen predictable token, password reset flow'unda account takeover üretebilir. Düşük severity'li information exposure başka bir vulnerability için gerekli secret veya identifier'ı açığa çıkarabilir.

Risk triage hangi context'i kullanmalı?

En az şu boyutlar değerlendirilmelidir:

• Application criticality
• Code path'in production build'e girip girmediği
• Entry point'in external, internal veya privileged olması
• Authentication precondition
• Required role
• Untrusted input'un gerçek kontrol seviyesi
• Sink'e kadar sanitizer ve validation behavior'ı
• Runtime configuration
• Data sensitivity
• Tenant crossing ihtimali
• Attack complexity
• Blast radius
• Existing compensating control
• Chained impact
• Finding confidence

Bu context'in tamamını scanner otomatik üretemeyebilir. Application inventory, architecture metadata ve manual review ile zenginleştirilmesi gerekir.

Severity, confidence ve priority aynı şey değildir

Bu üç kavram ayrılmalıdır:

High severity, low confidence finding pull request'i otomatik block etmek yerine hızlı security review gerektirebilir. Medium severity, high confidence ve internet-facing critical path finding'i daha yüksek remediation priority alabilir.

Reachability ne kadar güvenilir?

Reachability ve exploitability analysis faydalıdır. Fakat “reachable değil” sonucu süresiz risk kabulü olmamalıdır. Feature flag, routing, configuration, reflection, dependency injection ve gelecekteki caller değişikliği code path'i erişilebilir hale getirebilir.

Reachability kararı şu evidence ile tutulmalıdır:

• İncelenen commit
• Build configuration
• Entry point seti
• Caller graph
• Feature state
• Environment varsayımı
• Karar tarihi
• Yeniden değerlendirme trigger'ı

Compensating control ne zaman dikkate alınmalı?

WAF, input validation gateway veya internal network boundary exploitation olasılığını azaltabilir. Ancak source code weakness yine vardır. Control devre dışı kalabilir veya başka entry point aynı sink'e ulaşabilir.

Finding şu şekilde kapatılmamalıdır:

Bu false positive değildir. Risk treatment kararıdır. Compensating control'ün owner'ı, coverage'i ve validity period'u kaydedilmelidir.

Doğru gate policy nasıl görünür?

Örnek karar matrix'i:

Bu matrix kuruma özgü threat model ve risk appetite'a göre düzenlenmelidir. Hazır vendor default'u governance yerine geçmez.

Hata 5: Triage, suppression ve risk acceptance yaşam döngüsü kurmamak

SAST implementation'ının sürdürülebilirliği finding sayısından çok karar kalitesine bağlıdır.

Bir developer finding'e baktığında dört temel sonuçtan biri oluşur:

1. 1True positive ve fix edilecek
2. 2True positive fakat risk geçici olarak kabul edilecek
3. 3False positive
4. 4Duplicate veya başka finding altında yönetiliyor

Bu kararların yalnızca tool ekranındaki Dismiss butonuna bırakılması kontrol kaybı yaratır.

Suppression ile risk acceptance aynı şey değildir

Suppression, scanner sonucunun belirli reason ile gösterim veya gate dışında tutulmasıdır.

Risk acceptance, gerçek bir weakness'in belirli süre ve business authority ile açık kalmasına izin verilmesidir.

True positive finding'i “used in tests”, “won't fix” veya “false positive” etiketiyle kapatmak metric'i iyileştirir, riski azaltmaz.

False positive kararı hangi evidence'ı içermeli?

• Rule ID
• Finding location ve data flow
• Neden exploitable olmadığı
• İncelenen validation veya sanitizer
• İlgili code ve configuration version'ı
• Reviewer
• Karar tarihi
• Yeniden açılma koşulu

Örnek iyi açıklama:

Örnek kötü açıklama:

Inline suppression neden risklidir?

Developer code içine scanner-specific ignore annotation ekleyebilir. Bu hızlıdır, fakat kontrolsüz kullanılırsa finding daha security review'a gelmeden görünmez olur.

Inline suppression için şu koşullar uygulanabilir:

• Reason zorunlu
• Ticket veya review reference zorunlu
• Security-sensitive rule'larda code owner approval
• Scope tek finding veya line ile sınırlı
• Wildcard rule disable yasak
• Suppression test ile korunuyor
• Code değiştiğinde yeniden değerlendirme

Risk acceptance nasıl yönetilmeli?

Her acceptance kaydı en az şunları içermelidir:

• Finding ve affected version
• Technical impact
• Business gerekçesi
• Compensating control
• Risk owner
• Approval authority
• Başlangıç ve expiry tarihi
• Remediation planı
• Revalidation trigger'ı

Süresiz exception güvenlik policy'si değildir. Expiry geldiğinde finding otomatik olarak yeniden triage veya gate kapsamına alınmalıdır.

Duplicate yönetimi

Aynı root cause birden fazla file ve tool tarafından raporlanabilir. Deduplication yalnızca aynı satırı birleştirmek değildir.

Şu seviyeler ayrılmalıdır:

• Aynı tool'un aynı finding'i
• Farklı tool'ların aynı data flow'u
• Aynı unsafe helper'dan doğan farklı sink'ler
• Aynı security requirement eksikliğinin farklı manifestation'ları

Root cause düzeyinde parent finding açılabilir. Yine de affected location'lar kaybedilmemelidir. Parent kapandığında bütün child path'lerin gerçekten düzeldiği doğrulanmalıdır.

Closed finding yeniden neden açılır?

• Code geri geldi
• Sanitizer kaldırıldı
• Caller değişti
• Rule precision iyileşti
• Framework model'i güncellendi
• Risk acceptance expired oldu
• Application internet-facing hale geldi
• Compensating control kaldırıldı

Finding identity ve history korunmuyorsa bu değişiklikler yeni olay gibi görünür, eski karar context'i kaybolur.

Defect tracking neden merkezi olmalı?

OWASP SAMM, security defect'lerin erişilebilir bir yerde izlenmesini, false positive ve duplicate stratejisinin bulunmasını önerir. SAST findings yalnızca scanner dashboard'unda kalırsa engineering backlog, release plan ve risk register ile bağlantı kurulamaz.

Scanner system of detection olabilir. Finding yaşam döngüsünün system of record'u issue tracker veya AppSec platform olabilir. Hangi sistemin authoritative olduğu açıkça belirlenmelidir.

Hata 6: SAST entegrasyonunun kendisini yeni bir attack surface'e dönüştürmek

Security scanner source code'un tamamını okur. Bazı ürünler build yapar, dependency indirir, artifact üretir ve sonucu external service'e gönderir. Pipeline job'ı repository token'ı, package registry credential'ı veya cloud secret'ına erişebilir.

Yanlış tasarlanmış SAST integration'ı korumaya çalıştığı codebase için supply chain riski oluşturabilir.

En kritik riskler

• Scanner job gereksiz write permission taşır
• Third-party action mutable tag ile çağrılır
• Untrusted pull request privileged runner üzerinde çalışır
• Fork'tan gelen code secret erişebilen pipeline'da execute edilir
• Scanner image doğrulanmadan latest tag ile kullanılır
• Analysis artifact source snippet ve secret içerir
• Debug log token veya environment variable yazdırır
• SaaS scanner'a confidential source code policy kontrolü olmadan gönderilir
• Plugin ve extension'lar vetting yapılmadan kurulur
• Self-hosted runner project'ler arasında isolation sağlamaz
• Finding upload token'ı repository write yetkisine sahiptir
• Cache poisoning ile başka branch'in artifact'ı kullanılır

Read-only analysis gerçekten read-only mi?

SAST source code'u analiz ederken build script, compiler plugin, annotation processor veya package lifecycle hook çalıştırabilir. Repository içeriği attacker-controlled ise analysis job içinde arbitrary code execution ihtimali doğar.

Özellikle public contribution veya fork modelinde şu ayrım yapılmalıdır:

• Untrusted code analysis
• Trusted branch analysis
• Secret erişimi gereken build
• Internal runner kullanımı

Untrusted pull request'lerde secret verilmemeli, write token kullanılmamalı ve ephemeral isolated runner tercih edilmelidir.

Pipeline permission modeli

Minimum permission yaklaşımı uygulanmalıdır:

SAST job production deployment credential'ına erişebiliyorsa stage isolation hatalıdır.

Third-party action ve scanner image güvenliği

GitHub secure use guidance, third-party action'ların full-length commit SHA ile pin edilmesini immutable reference bakımından en güçlü seçenek olarak gösterir. Benzer yaklaşım container image digest ve verified artifact için uygulanabilir.

Kontroller:

• Action veya plugin source'u değerlendirilir
• Full commit SHA veya immutable digest kullanılır
• Scanner update controlled process ile yapılır
• Image signature ve provenance doğrulanır
• Vulnerability ve end-of-life takibi yapılır
• Default outbound network access sınırlandırılır
• Update sonrası rule delta ve performance regression test edilir

Source code data governance

SaaS SAST kullanılıyorsa şu sorular cevaplanmalıdır:

• Hangi source file ve metadata dışarı gönderiliyor?
• Data hangi region'da işleniyor?
• Retention süresi nedir?
• Model training veya service improvement amacıyla kullanılıyor mu?
• Subprocessor listesi nedir?
• Encryption ve access control nasıl sağlanıyor?
• Customer-managed key seçeneği var mı?
• Deletion nasıl doğrulanıyor?
• Incident notification süresi nedir?
• Secret bulunduğunda result payload nasıl korunuyor?

“Scanner yalnızca hash gönderiyor” veya “source code saklanmıyor” beyanı architecture evidence ve contract ile doğrulanmalıdır.

Artifact ve log güvenliği

SARIF, JSON report, code snippet, path, commit author ve secret-like value içerebilir. Pipeline artifact'ı public veya bütün developer'lara açık olmamalıdır.

• Artifact access role-based olmalı
• Retention ihtiyaca göre sınırlanmalı
• Log masking test edilmeli
• Raw result ile developer annotation ayrılmalı
• Sensitive finding notification güvenli kanaldan yapılmalı
• Test sonrasında temporary workspace temizlenmeli

OWASP CI/CD Security Cheat Sheet, plugin ve integration'ların attack surface'i artırdığını, extension kurma yetkisinin least privilege ile sınırlandırılması ve integration'ların acquisition süreci gibi değerlendirilmesi gerektiğini vurgular.

Hata 7: Finding'i engineering workflow'a ve ölçülebilir sonuca bağlamamak

SAST finding'i doğru olsa bile doğru kişiye doğru zamanda ulaşmıyorsa güvenlik sonucu üretmez.

Yaygın başarısız model şudur:

1. 1Scanner scheduled job'da çalışır
2. 2Findings merkezi dashboard'a düşer
3. 3Security ekibi Excel export alır
4. 4Ay sonunda development manager'a gönderir
5. 5Finding oluşturulan code'dan haftalar sonra ele alınır
6. 6Developer context'i hatırlamaz
7. 7Ticket başka sprint'e ötelenir

Shift-left yalnızca scan'in erken çalışması değildir. Actionable feedback'in change sahibine decision anında ulaşmasıdır.

Developer finding'de ne görmeli?

• Rule ve vulnerability class
• Affected line ve data flow
• Source ile sink
• Neden security risk olduğu
• Application context
• Güvenli ve güvensiz code örneği
• Kurumun approved remediation pattern'i
• Severity ve confidence
• Gate kararı
• False positive veya exception request yolu
• Security contact

“CWE-89 bulundu” tek başına developer guidance değildir.

Ownership nasıl belirlenmeli?

Finding owner şu kaynaklardan türetilebilir:

• CODEOWNERS
• Repository ownership
• Service catalog
• Application inventory
• Module maintainer
• Son değişikliği yapan team

Son commit author'ını otomatik owner yapmak her zaman doğru değildir. Developer yalnızca refactor yapmış olabilir. Accountability team ve application owner seviyesinde kurulmalıdır.

AppSec ekibinin rolü

AppSec bütün finding'leri tek başına kapatan queue operator olmamalıdır. Görevleri şunları içermelidir:

• Policy ve rule governance
• High-risk finding triage
• Custom rule development
• Framework modeling
• Developer enablement
• Secure pattern ve reusable library üretimi
• Exception review
• Metrics ve systemic root cause analizi
• Manual Secure Code Review escalation'ı

Routine high-confidence findings doğrudan owning team'e gidebilmelidir.

Feedback süresi neden kritiktir?

Pull request açıldıktan iki saat sonra gelen finding ile iki hafta sonra gelen finding aynı remediation cost'a sahip değildir. Developer zihinsel context'i kaybetmeden feedback almalıdır.

Ölçülebilecek süreler:

• Commit'ten scan başlangıcına kadar süre
• Scan duration
• Scan bitişinden annotation'a kadar süre
• Finding'den ilk triage'a kadar süre
• Triage'dan fix'e kadar süre
• Fix'ten validation'a kadar süre

Sadece total scan sayısı bu gecikmeleri göstermez.

Finding'den root cause'a geçmek

Aynı injection pattern'i on repository'de görülüyorsa on ayrı ticket açmak yeterli değildir. Ortak root cause şu olabilir:

• Unsafe internal helper
• Eksik secure coding standard
• Framework default'u
• Code template
• Developer training gap'i
• Approved library eksikliği
• Threat model'de atlanan trust boundary

Kalıcı çözüm unsafe helper'ı değiştirmek, secure wrapper sunmak ve custom SAST rule ile eski kullanımı yasaklamak olabilir.

SAST ile Secure Code Review nasıl birleşmeli?

SAST scalable pattern detection sağlar. Manual Secure Code Review authorization, business rule, trust boundary, race condition, cryptographic design ve application-specific context'i değerlendirir.

High-risk finding, custom framework veya critical code change manual review'a escalation edilebilir. İki yaklaşımın farkını Secure Code Review ile otomatik SAST taraması farkı yazımızda ayrıntılı ele alıyoruz.

Program hangi metric'lerle yönetilmeli?

İyi metric'ler:

• SAST-enabled active repository oranı
• Başarılı full analysis oranı
• Supported language ve module coverage
• Median feedback time
• New high-confidence finding rate
• Time to triage
• Time to remediate
• Reopened finding oranı
• Expired risk acceptance sayısı
• Suppression age ve owner coverage
• Repeat root cause oranı
• Gate bypass frequency
• Scan timeout ve partial result oranı
• Developer tarafından kabul edilen recommendation oranı

Yanlış veya eksik metric'ler:

• Toplam scan sayısı
• Toplam finding sayısı
• Dashboard'daki açıkların her ay azalması
• Pipeline'da security stage bulunması
• Suppression sonrası sıfır Critical görünmesi

Finding sayısının düşmesi güvenli code arttığı için olabilir. Rule'lar kapatıldığı veya scan coverage'i bozulduğu için de olabilir. Metric daima coverage ve policy değişiklikleriyle birlikte yorumlanmalıdır.

Doğru CI/CD SAST operating model'i nasıl kurulmalı?

Yedi hatayı tek tek düzeltmek yeterli değildir. SAST'ın pipeline içinde hangi güvenlik kararını verdiği uçtan uca tanımlanmalıdır.

İyi bir operating model şu zinciri kurar:

Bu zincirde scanner yalnızca detection engine'dir.

1. Application inventory ve risk tier oluşturun

Her repository aynı policy ile yönetilmemelidir. Marketing site ile payment authorization service aynı risk profiline sahip değildir.

Inventory en az şu alanları içerebilir:

• Application ve service adı
• Repository
• Owning team
• Business owner
• Internet exposure
• Data classification
• Authentication ve authorization önemi
• Tenant modeli
• Regulatory scope
• Supported language ve framework
• Deployment environment
• Criticality tier
• SAST profile
• Security contact

Örnek risk tier modeli:

Tier değeri sabit değildir. Internal service internet-facing hale gelirse veya sensitive data işlemeye başlarsa policy güncellenmelidir.

2. Language ve framework coverage matrix hazırlayın

Tool lisansı alınmadan önce kurumun technology inventory'si çıkarılmalıdır.

“Tool language'i destekliyor” ifadesi yeterli değildir. Version, framework, build system ve cross-file analysis capability'si doğrulanmalıdır.

Proof repository kullanın

Her önemli technology stack için bilinen güvenli ve güvensiz örnekler içeren internal validation repository hazırlanabilir. Scanner veya rule set update'inde şu kontroller çalışır:

• Beklenen true positive bulunuyor mu?
• Güvenli implementation false positive üretiyor mu?
• Custom source ve sink model'i çalışıyor mu?
• Finding severity ve metadata korunuyor mu?
• Gate doğru sonucu veriyor mu?
• Scan duration kabul edilebilir mi?

Bu test, production application'da finding sayısına bakmaktan daha kontrollü rule regression kanıtı sağlar.

3. Scan profile'larını ayırın

Tek rule set'i bütün event'lerde çalıştırmak speed ve precision dengesini bozar.

Pull request profile

• Hızlı
• High precision
• Diff-aware
• Yeni finding odaklı
• Inline developer feedback
• Güvenilir blocking rules

Default branch profile

• Full module context
• Cross-file ve cross-project analysis
• Merge sonrası yeni call graph
• Baseline update değil delta verification

Scheduled deep profile

• Extended rule ve query suite
• Yeni vulnerability pattern'leri
• Daha uzun timeout
• Existing code debt discovery
• Trend ve rule performance analizi

Release profile

• Critical application requirement'ları
• Unresolved gate finding kontrolü
• Expired exception kontrolü
• Coverage ve scanner health doğrulaması
• Release artifact ile commit eşleşmesi

Her profile'ın output'u aynı gate'e bağlı olmak zorunda değildir. Scheduled deep scan finding'i önce triage queue'ya girebilir.

4. Quality gate policy'sini code olarak yönetin

Gate ayarı admin panelinde kimin değiştirdiği bilinmeyen birkaç checkbox olmamalıdır.

Policy-as-code yaklaşımında şu alanlar version control altında tutulabilir:

• Application tier mapping
• Blocking severity ve confidence
• Rule allowlist veya denylist
• Branch ve event policy'si
• Baseline reference
• Exception requirement'ları
• Expiry behavior
• Required reviewer
• Scan timeout ve failure behavior
• Minimum coverage kriteri

Policy change pull request review'undan geçmeli, owner onayı taşımalı ve audit log bırakmalıdır.

Scanner çalışmazsa ne olmalı?

En kritik sorulardan biri budur. Finding çıkmaması ile scan'in çalışmaması aynı sonuç olmamalıdır.

Failure state'leri ayrılmalıdır:

• Scanner infrastructure unavailable
• Build extraction failed
• Unsupported language
• Result upload failed
• Timeout
• Partial analysis
• Policy engine unavailable
• License limit

Critical application'da fail-open release ciddi risk oluşturabilir. Ancak bütün repository'lerde fail-closed uygulamak da scanner outage sırasında kurumsal delivery'yi durdurabilir.

Risk bazlı model:

Emergency bypass sonrasında rescan zorunlu olmalı ve hangi release'in security check olmadan geçtiği kaydedilmelidir.

5. Finding workflow'unu pull request ile issue tracker arasında tasarlayın

Her finding için ticket açmak binlerce duplicate oluşturabilir. Hiç ticket açmamak da release sonrası ownership'i kaybettirir.

Önerilen model:

• Pull request finding'i inline annotation olarak gösterilir
• Blocking finding PR içinde çözülür veya approved exception alır
• Merge öncesi kapanmayan accepted finding issue tracker'a taşınır
• Existing baseline findings risk-based campaign olarak gruplanır
• Critical systemic root cause program-level epic altında yönetilir
• Scanner finding ID ile ticket ID birbirine bağlanır
• Fix commit ve validation sonucu kaydedilir

Developer fix'i nasıl doğrulanmalı?

Finding'in scanner ekranından kaybolması üç anlama gelebilir:

• Vulnerability gerçekten düzeltildi
• Code yolu taşındı ve finding identity kayboldu
• Rule veya scan coverage'i değişti

Bu nedenle high-risk fix için code diff, security requirement ve gerektiğinde manual validation yapılmalıdır.

6. Rule governance kurun

Rule'lar da production control'dür. Owner, version, test ve change process gerektirir.

Her custom rule için:

• Rule ID
• Vulnerability class
• Amaç ve threat scenario
• Supported language ve framework
• Source, sink, sanitizer definition
• Positive test case
• Negative test case
• Expected severity ve confidence
• Owner
• Version
• Review tarihi
• Performance etkisi

Rule ne zaman kapatılabilir?

• Systemic false positive kanıtlandıysa
• İlgili technology artık kullanılmıyorsa
• Daha precise rule tarafından kapsanıyorsa
• Performance impact kabul edilemez ve alternate control varsa
• Rule yanlış vulnerability class'ını temsil ediyorsa

“Çok finding üretiyor” tek başına rule disable gerekçesi değildir. Çok finding gerçek unsafe pattern'in yaygın olduğunu da gösterebilir.

Custom rule ne zaman yazılmalı?

• Pentest veya incident aynı pattern'in tekrarını gösterdiğinde
• Internal unsafe helper keşfedildiğinde
• Framework'e özgü authorization check atlandığında
• Kuruma ait secure wrapper kullanılmadığında
• Secret veya sensitive logging pattern'i tekrarlandığında
• Approved cryptographic API dışına çıkıldığında

Pentest finding'ini custom SAST rule'a dönüştürmek tek seferlik bulguyu preventive control haline getirir.

7. Developer experience tasarlayın

Security feedback anlaşılmaz ve geç gelirse bypass davranışı artar.

İyi developer experience bileşenleri:

• Pull request içinde kısa ve doğru açıklama
• Tek tıkla data flow görünümü
• Kuruma özgü fix örneği
• Approved secure library link'i
• IDE feedback seçeneği
• False positive request için kolay fakat denetlenebilir akış
• Security office hour veya hızlı destek kanalı
• Team bazlı training
• Fix validation'ın otomatik çalışması

Finding mesajı geliştiriciyi suçlamamalıdır. Ama riski belirsiz de bırakmamalıdır.

Örnek zayıf mesaj:

Örnek etkili mesaj:

SAST rollout için 90 günlük uygulama planı

Gün 1–15: Inventory ve hedef

• Active repository inventory çıkarın
• Application criticality tier belirleyin
• Language, framework ve build system'leri sayın
• Data residency ve source code policy'sini netleştirin
• Pilot project'leri seçin
• Başarı metric'lerini tanımlayın

Gün 16–30: Pilot ve coverage validation

• Non-blocking scan açın
• Build extraction ve module coverage'i doğrulayın
• Rule set ve scan time ölçün
• İlk true positive ve false positive setini manual inceleyin
• Pipeline permission ve artifact erişimini test edin
• Developer feedback toplayın

Gün 31–45: Baseline ve triage

• Existing debt snapshot oluşturun
• Critical findings için urgent review yapın
• Finding states ve reason taxonomy belirleyin
• Ownership mapping kurun
• Risk acceptance ve suppression workflow'u tanımlayın
• SLA ve escalation hazırlayın

Gün 46–60: Progressive gate

• Yeni high-confidence Critical finding'leri block edin
• Tier 1 application'larda seçili High rule'ları ekleyin
• Scanner failure policy'sini etkinleştirin
• Break-glass ve post-bypass rescan akışını deneyin
• Pull request annotation'ı standardize edin

Gün 61–75: Scale

• Benzer stack'e sahip repository gruplarını ekleyin
• Default branch full scan'i yaygınlaştırın
• Scheduled deep scan başlatın
• Issue tracker integration'ını kurun
• Platform ve AppSec support model'ini yayınlayın

Gün 76–90: Ölç ve düzelt

• Coverage ve feedback time metric'lerini inceleyin
• En çok suppression alan rule'ları analiz edin
• En sık tekrar eden root cause'ları bulun
• Custom framework model ihtiyacını belirleyin
• Developer remediation rehberlerini güncelleyin
• İkinci rollout wave için policy'yi kalibre edin

Bu plan takvime göre değil evidence'a göre ilerlemelidir. Pilot coverage doğrulanmadıysa gate phase'ine geçilmemelidir.

SAST quality gate için örnek policy matrix

Policy matrix static kalmamalıdır. False positive rate, bypass frequency ve remediation capacity'ye göre düzenli gözden geçirilmelidir.

SAST programı nasıl doğrulanmalı?

Security control'ün varlığı değil etkinliği test edilmelidir.

Synthetic test cases

Controlled vulnerable ve safe code örnekleri pipeline'dan geçirilir. Expected gate behavior otomatik test edilir.

Rule regression

Scanner veya rule update öncesi ve sonrası finding delta, performance ve false positive seti karşılaştırılır.

Coverage audit

Repository, language, module, branch ve trigger coverage'i periyodik olarak inventory ile karşılaştırılır.

Suppression audit

Expired, ownerless, wildcard ve açıklamasız suppression'lar aranır. Random sample manual review edilir.

Pipeline security review

Runner isolation, token permission, third-party action, image pinning, artifact access ve outbound connection incelenir.

Finding-to-fix sampling

Kapalı finding'lerden örnek seçilip gerçekten güvenli fix yapılıp yapılmadığı Secure Code Review ile doğrulanır.

Pentest correlation

Pentest ve incident findings içinde SAST tarafından yakalanabilecek pattern'ler belirlenir. Neden kaçtığı incelenir:

• Rule yoktu
• Coverage yoktu
• Data flow model'i eksikti
• Finding suppressed edilmişti
• Scan failed olmuştu
• Finding vardı fakat fix edilmemişti
• Vulnerability yalnızca runtime veya business context'te görünüyordu

Bu analiz SAST'ın limitini ve geliştirme fırsatını aynı anda gösterir.

SAST, SCA, secret scanning ve IaC scanning neden ayrılmalı?

CI/CD'de bütün security scanner'ları “SAST” adı altında toplamak ownership ve gate hatası oluşturur.

Her kontrolün false positive modeli, update cadence'i, owner'ı ve remediation path'i farklıdır. Tek bir “High ve üzeri block” kuralı bütün scanner'lar için doğru olmayabilir.

Örneğin secret finding için ilk action yalnızca code'dan silmek değil secret'ı revoke etmektir. Dependency finding için upgrade ve compatibility testi gerekir. IaC finding environment context'iyle değerlendirilir.

Tool seçerken sorulması gereken sorular

SAST ürün demosunda bulunan toplam vulnerability sayısı kalite ölçütü değildir.

Coverage

• Kurumun language ve framework version'ları destekleniyor mu?
• Cross-file ve cross-function analysis var mı?
• Monorepo ve multi-module build nasıl ele alınıyor?
• Custom source, sink ve sanitizer tanımlanabiliyor mu?
• Generated code ve template language desteği nedir?

Precision ve triage

• Confidence bilgisi sunuluyor mu?
• Data flow açıklanabiliyor mu?
• Duplicate yönetimi nasıl çalışıyor?
• Baseline ve new-code karşılaştırması var mı?
• Suppression reason, owner ve expiry tutulabiliyor mu?

CI/CD integration

• Pull request annotation ne kadar hızlı?
• Scanner failure ve partial result ayırt ediliyor mu?
• Policy-as-code destekleniyor mu?
• Self-hosted ve SaaS seçenekleri neler?
• Result API ve issue tracker integration'ı var mı?

Security ve privacy

• Source code nerede işleniyor ve saklanıyor?
• Runner hangi permission'ları istiyor?
• Scanner image veya action nasıl doğrulanıyor?
• Artifact ve result encryption nasıl sağlanıyor?
• Data deletion ve subprocessor policy'si nedir?
• Audit log ve role-based access var mı?

Operating cost

• Scan duration ve compute ihtiyacı nedir?
• Developer başına triage yükü ne olur?
• Custom rule bakım maliyeti nedir?
• Rule update regression imkânı var mı?
• Lisans sınırı scan failure'a nasıl yansır?

Proof of concept sırasında yalnızca finding sayısı değil bilinen test corpus'u üzerindeki precision, coverage, runtime ve integration behavior karşılaştırılmalıdır.

CI/CD SAST entegrasyonunda yanlış başarı kabulleri

“Pipeline yeşilse code güvenlidir”

Yeşil sonuç, yalnızca configured policy'nin block edecek finding üretmediğini gösterebilir. Scan partial çalışmış, ilgili language desteklenmemiş, rule kapatılmış veya vulnerability SAST'ın göremediği business logic sınıfında olabilir.

“Finding yoksa false negative yoktur”

False negative görünmezdir. Bilinen vulnerable test case, pentest correlation ve manual review olmadan ölçülemez.

“Daha çok rule daha yüksek güvenliktir”

Precision düşerse developer güveni ve gate sustainability bozulabilir. Rule profile event ve application riskine göre seçilmelidir.

“Bütün High findings merge'i durdurmalıdır”

Severity tek başına confidence, reachability, application criticality ve business context'i taşımaz. Blocking policy risk-based olmalıdır.

“Baseline'e alınan finding artık sorun değildir”

Baseline yalnızca new-code gate'i mevcut borçtan ayırır. Existing findings owner ve remediation planıyla yönetilmeye devam etmelidir.

“False positive'i developer kapatabilir”

Developer teknik context sağlayabilir. Security-sensitive rule suppression'ı evidence, reason ve uygun approval gerektirir. Aksi halde baskı altındaki delivery kararı risk kararına dönüşür.

“SAST varsa Secure Code Review'a gerek yoktur”

SAST tekrarlanabilir pattern'leri ölçekli biçimde arar. Manual review business authorization, trust boundary, design, race condition ve custom framework davranışını inceler. Otomasyon expert review'un tamamını karşılamaz.

“SAST varsa pentest ihtiyacı azalır”

Bazı code-level weakness'ler daha erken bulunabilir. Ancak deployed configuration, runtime integration, authentication behavior ve end-to-end exploitability için pentest gerekir. İki kontrol farklı evidence üretir.

“SAST job'ı security ekibinin sorumluluğudur”

Platform ekibi pipeline reliability ve runner security'yi, AppSec policy ve rule governance'i, development team remediation'ı, product owner business priority'yi yönetir. Tek ekip bütün zinciri taşıyamaz.

SAST programı için responsibility matrix

Gerçek organization yapısına göre role adları değişebilir. Kritik olan responsibility gap bırakmamaktır.

SAST entegrasyonu için acceptance checklist

Bir project'in pipeline'ında SAST stage görünmesi “entegrasyon tamamlandı” kabulü için yeterli değildir. Aşağıdaki checklist, production-grade kabul kriteri olarak kullanılabilir.

Coverage

• Active repository inventory içinde project kaydı var
• Application criticality tier atanmış
• Primary ve secondary language'ler doğru detect ediliyor
• Kullanılan language version'ları destekleniyor
• Monorepo içindeki ilgili module'ler analize giriyor
• Submodule ve generated source yaklaşımı tanımlı
• Build extraction başarıyla tamamlanıyor
• Private dependency resolution çalışıyor
• Unsupported file ve module'ler görünür
• Exclusion path'leri owner tarafından onaylı
• Pull request, default branch ve scheduled trigger'lar doğrulanmış
• Partial analysis başarılı scan gibi raporlanmıyor

Finding quality

• Finding location ve data flow developer tarafından anlaşılabiliyor
• Severity ve confidence ayrı gösteriliyor
• New ve existing finding ayrımı güvenilir
• Duplicate yönetimi çalışıyor
• Application-specific source ve sink'ler modellenmiş
• High-noise rule'lar sample triage ile incelenmiş
• Safe implementation negative testte finding üretmiyor
• Known vulnerable implementation positive testte yakalanıyor

Quality gate

• Blocking policy application tier'a bağlı
• İlk günden bütün existing findings merge'i durdurmuyor
• Yeni high-confidence Critical findings blocking
• Scanner failure ile sıfır finding birbirinden ayrılıyor
• Timeout ve partial result policy'si tanımlı
• Emergency bypass owner ve expiry gerektiriyor
• Bypass edilen release post-scan queue'ya otomatik giriyor
• Policy değişiklikleri version control ve review altında

Workflow

• Pull request annotation zamanında geliyor
• Finding owning team'e atanabiliyor
• False positive request yolu tanımlı
• Suppression reason zorunlu
• Risk acceptance owner ve expiry taşıyor
• Expired exception yeniden açılıyor
• Issue tracker ile scanner finding ID bağlantısı korunuyor
• Fix commit ve validation sonucu kaydediliyor
• Critical finding için hızlı notification kanalı var

Pipeline security

• SAST token'ı minimum permission taşıyor
• Production deployment secret'ları scanner job'a verilmiyor
• Untrusted pull request isolated runner'da çalışıyor
• Third-party action veya image immutable reference ile pin edilmiş
• Scanner artifact'ının access control'ü var
• Log masking doğrulanmış
• Source code data residency ve retention onaylı
• Temporary workspace ve cache temizliği tanımlı
• Plugin ve scanner update süreci governance altında

Measurement

• Repository, language ve module coverage ölçülüyor
• Scan success ile full analysis success ayrılıyor
• Median feedback time takip ediliyor
• Time to triage ve time to remediate ölçülüyor
• Gate bypass sayısı görünür
• Expired ve ownerless acceptance raporlanıyor
• Repeat root cause oranı izleniyor
• Pentest ve incident findings SAST coverage'iyle karşılaştırılıyor

Bu kriterlerin tamamı ilk rollout gününde hazır olmak zorunda değildir. Ancak eksikler kayıtlı olmalı, owner ve target state taşımalıdır.

SAST entegrasyonunun etkisizleştiğini gösteren kırmızı bayraklar

Aşağıdaki belirtiler pipeline job'ı çalışsa bile programın güvenlik sonucu üretmediğini gösterebilir:

• Bütün project'lerde allow failure kalıcı hale gelmiş
• Son altı ayda hiç merge block oluşmamış
• Finding sayısı bir gecede sıfıra düşmüş, fakat rule değişikliği incelenmemiş
• Repository sayısı artarken analyzed line sayısı sabit kalmış
• Scanner update aylarca pinli kalmış veya kontrolsüz latest kullanılıyor
• Suppression'ların çoğunda reason yalnızca “false positive”
• Risk acceptance kayıtlarının expiry tarihi yok
• Security ekibi finding queue'suna haftalar sonra bakıyor
• Developer'lar code annotation yerine aylık spreadsheet alıyor
• Pipeline timeout olduğunda job success dönüyor
• Tool unsupported language'leri raporlamıyor
• Admin, payment veya identity repository'leri normal application policy'sinde
• Pentest'te bulunan tekrar eden code pattern'i SAST'ta görünmüyor
• Scanner runner production credential taşıyor
• False positive oranı ölçülmeden rule set sürekli genişletiliyor
• Baseline iki yıldır küçülmemiş
• Fix sonrası finding kaybolduğu için otomatik olarak closed sayılıyor
• Gate bypass sonrasında rescan yapılmıyor

Tek bir işaret bütün programın başarısız olduğunu kanıtlamaz. Birkaçının birlikte görülmesi control health assessment gerektirir.

Yıllık SAST maturity review hangi soruları sormalı?

Tool renewal toplantısı yalnızca lisans kullanımı ve scan sayısını değerlendirmemelidir.

Review şu sorulara cevap vermelidir:

1. 1Technology inventory'nin ne kadarı gerçek full analysis coverage'ine sahip?
2. 2Son bir yılda hangi vulnerability class'ları en çok tekrar etti?
3. 3Hangi findings production incident veya pentest ile correlate oldu?
4. 4Hangi rule'lar en fazla false positive ve suppression üretti?
5. 5Hangi team'lerde feedback ve remediation süresi belirgin biçimde yüksek?
6. 6Gate kaç kez bypass edildi ve neden?
7. 7Accepted risk'lerin ne kadarı expiry öncesinde kapandı?
8. 8Custom framework model'leri güncel mi?
9. 9Scanner ve integration supply chain riski yeniden değerlendirildi mi?
10. 10Tool maliyeti hangi prevent edilmiş veya daha erken düzeltilmiş risklerle ilişkilendirilebiliyor?

Bu review sonunda yalnızca daha fazla repository ekleme hedefi çıkmamalıdır. Rule precision, developer feedback, secure library, training, manual review ve architecture improvement action'ları da oluşmalıdır.

Sonuç: Pipeline'a scanner değil, güvenilir bir karar mekanizması eklenmelidir

CI/CD'ye SAST eklemek teknik olarak kolaydır. Bir template import edilir, scanner image çalıştırılır ve result dashboard'a gönderilir.

Zor olan şu sorulara güvenilir cevap vermektir:

1. 1Doğru repository, module ve build context gerçekten analiz edildi mi?
2. 2Finding yeni mi, existing debt'in parçası mı?
3. 3Severity, confidence ve application risk'i birlikte değerlendirildi mi?
4. 4Gate hangi evidence ile merge'i durdurdu veya izin verdi?
5. 5False positive ve risk acceptance kararı owner, reason ve expiry taşıyor mu?
6. 6Scanner job source code ve pipeline için yeni risk oluşturuyor mu?
7. 7Finding doğru team'e düzeltilebilecek zamanda ulaştı mı?
8. 8Fix gerçekten doğrulandı mı?
9. 9Aynı root cause'un tekrarı önlendi mi?

Başarılı SAST programı en çok finding üreten program değildir. Developer'ın güvenebildiği, AppSec ekibinin yönetebildiği, delivery'yi gereksiz yere durdurmadan kabul edilemez yeni riskleri engelleyen ve zamanla codebase içindeki tekrar eden weakness'leri azaltan programdır.

NIST SSDF'in yaklaşımı da tool kullanımından önce security outcome'a odaklanır. Human-readable code analizinin amacı vulnerability'lerin release öncesinde düzeltilebilmesidir. OWASP SAMM ise automation'ın coverage ve frequency'sinin aşamalı gelişmesini, manual security testing'in gerekli alanlarda devam etmesini öngörür.

Secnodex, SAST entegrasyonunu yalnızca scanner kurulumu olarak ele almaz. Repository ve technology inventory, language-framework coverage, quality gate policy, baseline, rule tuning, false positive workflow, custom rule, pipeline security ve finding-to-fix metric'lerini birlikte değerlendirir. Critical code path'lerde Secure Code Review ile tool sonuçlarını doğrular, pentest findings'lerini kalıcı detection rule'larına dönüştürür. CI/CD SAST modelinizi kurmak veya mevcut entegrasyonun gerçekten coverage üretip üretmediğini değerlendirmek için Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• NIST SP 800-218 – Secure Software Development Framework Version 1.1
• OWASP DevSecOps Guideline
• OWASP DevSecOps Guideline – Latest
• OWASP SAMM – Security Testing, Scalable Baseline
• OWASP SAMM – Security Testing, Deep Understanding
• OWASP SAMM – Defect Tracking
• OWASP CI/CD Security Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• GitHub Docs – Workflow Configuration Options for Code Scanning
• GitHub Docs – CodeQL Query Suites
• GitHub Docs – Secure Use Reference for GitHub Actions
• GitLab Docs – Static Application Security Testing
• GitLab Docs – Roll Out Application Security Testing
• GitLab Docs – SAST Rules
• CISA – Secure by Design