Üretime ulaşan her kod satırı, doğru olduğuna inanan biri tarafından yazılmıştır. Statik kod analizi, kodu çalıştırmak yerine yapısını okuyarak, veri akışlarını izleyerek ve bilinen güvenlik açığı, hata ve kalite ihlali kalıplarıyla karşılaştırarak bu inancın doğru olup olmadığını kontrol eden otomatik bir sistemdir. Soru, çalıştırılıp çalıştırılmayacağı değil, işlem hattının neresinde çalıştırılacağı, hangi aracın kullanılacağı, hangi eşiklerin uygulanacağı ve geliştiricilerin görmezden gelmek yerine harekete geçebilmeleri için geri bildirimin nasıl yeterince hızlı tutulacağıdır.
Statik analizi bir onay kutusu etkinliği olarak görmekle, gerçek bir kalite kontrol noktası olarak görmek arasındaki fark yapılandırmadır. Çalışan ve kimsenin okumadığı bir rapor üreten bir tarayıcı tiyatrodur. Yeni kritik güvenlik açıkları ortaya çıktığında derlemeyi başarısız kılan, kapsama oranı eşik değerinin altına düştüğünde birleştirmeyi engelleyen ve çekme isteği inceleme arayüzünde kesin dosya ve satır geri bildirimi sunan bir kalite kontrol noktası ise, kararlar alındığı anda davranışını değiştiren bir sistemdir.
Statik Analiz İşlem Hattının Hangi Aşamasında Çalıştırılmalı?
Statik analiz, her biri farklı bir amaca hizmet eden birden fazla noktada çalıştırılmalıdır. Sadece bir noktada çalıştırmak kör noktalar yaratır; her yerde eşit şekilde çalıştırmak ise geliştiricilerin etrafından dolaşmak zorunda kaldığı yavaş işlem hatları oluşturur.
| Boru Hattı Aşaması | Ne Koşmalı | Gecikme Bütçesi | Amaç |
|---|---|---|---|
| Ön taahhüt (yerel) | Yalnızca hızlı linterler (ESLint, Clippy, Rusfmt) | 5 saniyenin altında | Bariz sorunların depoya ulaşmadan önce önlenmesini sağlayın. |
| Çekme isteği / birleştirme isteği | Tam lintleme + SAST + artımlı SonarQube taraması | 3 dakikadan az | Blok birleştirmeleri yeni kritik sorunlar üzerine |
| Ana dal derlemesi | Kapsam, mükerrerlik ve teknik borç dahil olmak üzere tam analiz | 10 dakikadan az | Kalite trendlerini takip edin, gösterge panellerini güncelleyin. |
| Her gece planlanmıştır | Derin taramalar, bağımlılık denetimi, uyumluluk kontrolleri | Bütçe yok | Yavaş üretim sorunlarını ve tedarik zinciri risklerini tespit edin. |
En değerli aşama çekme isteğidir.Ana dala yapılan push işleminde çalışan analiz, birleştirme kararı verildikten sonra gerçekleşir. Pull request işleminde çalışan ve dosya ve satır bağlamını tam olarak belirten satır içi yorumlar gönderen analiz ise geliştirici hala kod üzerinde çalışırken ve düzeltme maliyeti en düşük seviyedeyken gerçekleşir.
Her kaydetme işleminden önce ağır analiz çalıştırmak geliştirici deneyimini mahvediyor. 5 saniyeden kısa sürede tamamlanan hızlı linter'lar oraya ait. Geri kalan her şey CI'ya ait.
GitHub Actions: Tam Çalışır Durumda Yapılandırma
GitHub Actions en yaygın kullanılan sürekli entegrasyon (CI) platformudur. Aşağıdaki iş akışı, katmanlı bir kalite kontrol hattı çalıştırır: biçimlendirme kontrolü, kod denetimi (linting), derleme, SAST güvenlik taraması ve SonarCloud kalite kontrol kapısı.
tatlım
# .github/workflows/quality.yml
name: Code Quality
on:
push:
branches: [main, develop]
pull_request:
branches: [main, develop]
jobs:
# ── Layer 1: Fast checks (under 60 seconds) ─────────────────────────────
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- run: npm ci
- name: Lint (fail on warnings)
run: npx eslint src/ --max-warnings 0
- name: Format check
run: npx prettier --check src/
- name: TypeScript type check
run: npx tsc --noEmit
# ── Layer 2: Security SAST (Semgrep) ────────────────────────────────────
sast:
runs-on: ubuntu-latest
needs: lint
steps:
- uses: actions/checkout@v4
- name: Semgrep SAST scan
uses: semgrep/semgrep-action@v1
with:
config: p/javascript p/nodejs p/owasp-top-ten
env:
SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}
# ── Layer 3: SonarCloud quality gate ────────────────────────────────────
sonar:
runs-on: ubuntu-latest
needs: lint
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # full history required for blame data
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- run: npm ci
- name: Run tests with coverage
run: npm test -- --coverage --coverageReporters=lcov
- name: SonarCloud scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}özellikleri
# sonar-project.properties
sonar.projectKey=my-org_my-project
sonar.organization=my-org
sonar.sources=src
sonar.tests=tests
sonar.javascript.lcov.reportPaths=coverage/lcov.info
sonar.coverage.exclusions=**/*.test.js,**/*.spec.jsBu iş akışındaki temel yapılandırma kararları:
--max-warnings 0ESLint'te: Herhangi bir uyarı, derleme hatası anlamına gelir. Uyarıları kabul eden ekipler, kimse okumayana kadar bu uyarıları biriktirir.fetch-depth: 0Ödeme sırasında: SonarCloud, ortaya çıkan sorunlara sorumluluk atamak ve yeni kod metriklerini doğru şekilde hesaplamak için tam git geçmişine ihtiyaç duyar.- Semgrep, lint işleminden sonra Sonar ile paralel olarak çalışır: güvenlik ve kalite taraması bağımsız konulardır; bunların paralel olarak çalıştırılması toplam işlem süresini azaltır.
- Testler şu şekilde çalıştırıldı:
lcovKapsama alanı çıktısı: SonarCloud, dosya başına kapsama alanını göstermek ve kalite kontrol noktasında kapsama alanı eşiklerini uygulamak için bunu okur.
GitLab CI/CD: Kalite Kapılarıyla Kalite Süreci
tatlım
# .gitlab-ci.yml
stages:
- lint
- test
- analyze
- security
variables:
SONAR_HOST_URL: "https://sonarcloud.io"
lint:
stage: lint
image: node:20
cache:
paths: [node_modules/]
script:
- npm ci
- npx eslint src/ --max-warnings 0
- npx prettier --check src/
- npx tsc --noEmit
rules:
- if: $CI_MERGE_REQUEST_IID
- if: $CI_COMMIT_BRANCH == "main"
test:
stage: test
image: node:20
script:
- npm ci
- npm test -- --coverage --coverageReporters=lcov cobertura
coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
sonarcloud:
stage: analyze
image:
name: sonarsource/sonar-scanner-cli:latest
entrypoint: [""]
variables:
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
GIT_DEPTH: "0"
cache:
key: "${CI_JOB_NAME}"
paths: [.sonar/cache]
script:
- sonar-scanner
rules:
- if: $CI_MERGE_REQUEST_IID
- if: $CI_COMMIT_BRANCH == "main"
semgrep:
stage: security
image: returntocorp/semgrep:latest
script:
- semgrep scan --config=p/owasp-top-ten --config=p/javascript
--sarif --output=semgrep.sarif src/
artifacts:
reports:
sast: semgrep.sarif
rules:
- if: $CI_MERGE_REQUEST_IID
- if: $CI_COMMIT_BRANCH == "main"MKS artifacts: reports: sast: Bu blok, Semgrep'ten gelen SARIF çıktısını doğrudan GitLab'ın Güvenlik Panosuna entegre eder; böylece bulgular ham CI günlük çıktısı olarak değil, birleştirme isteği güvenlik raporunda görünür.
Jenkins: SonarQube ile Bildirimsel İşlem Hattı
harika
// Jenkinsfile
pipeline {
agent any
tools {
nodejs "NodeJS-20"
}
environment {
SONAR_TOKEN = credentials('sonar-token')
}
stages {
stage('Lint') {
steps {
sh 'npm ci'
sh 'npx eslint src/ --max-warnings 0'
sh 'npx tsc --noEmit'
}
}
stage('Test') {
steps {
sh 'npm test -- --coverage --coverageReporters=lcov'
}
post {
always {
publishHTML([
allowMissing: false,
reportDir: 'coverage/lcov-report',
reportFiles: 'index.html',
reportName: 'Coverage Report'
])
}
}
}
stage('SonarQube Analysis') {
steps {
withSonarQubeEnv('SonarQube') {
sh '''
npx sonar-scanner \
-Dsonar.projectKey=my-project \
-Dsonar.sources=src \
-Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
'''
}
}
}
stage('Quality Gate') {
steps {
timeout(time: 5, unit: 'MINUTES') {
waitForQualityGate abortPipeline: true
}
}
}
}
post {
failure {
emailext(
subject: "Quality Gate FAILED: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
body: "Build failed quality gate. Review: ${env.BUILD_URL}",
to: "${env.CHANGE_AUTHOR_EMAIL}"
)
}
}
}waitForQualityGate abortPipeline: true Bu, kritik satırdır. Analiz tamamlanana kadar SonarQube'u sorgular ve kalite eşiği karşılanmazsa derlemeyi başarısız kılar. Bu satır olmadan, analiz devam ederken işlem hattı tamamlanır ve kalite eşiği sonucu asla uygulanmaz.
Ekiplerin Gerçekten Saygı Duyacağı Kalite Kontrol Noktalarının Yapılandırılması
Eşik değerleri çok agresif ayarlandığı için her commit'te başarısız olan bir kalite kontrol noktası devre dışı bırakılır. Eşik değerleri çok gevşek ayarlandığı için asla başarısız olmayan bir kontrol noktası ise hiçbir değer sağlamaz. Amaç, projenin gerçek risk profiline göre kalibre edilmiş bir kontrol noktası oluşturmaktır.
Yeni bir SonarQube kalite kapısı için önerilen başlangıç yapılandırması:
| metrik | Şart | Eşik |
|---|---|---|
| Yeni hatalar | Daha harika | 0 |
| Yeni güvenlik açıkları | Daha harika | 0 |
| Yeni güvenlik noktaları incelendi. | Küçüktür | 100% |
| Yeni kod kapsamı | Küçüktür | 80% |
| Yeni yinelenen satırlar | Daha harika | 3% |
| Yeni kod kokuları | Daha harika | 10 |
Bu eşikleri aşağıdakilere uygulayın: yalnızca yeni kod (SonarQube'deki "yeni kod" dönemi). Bunları eski bir projedeki tüm kod tabanına uygulamayın; beş yıldan fazla bir süredir biriken teknik borç nedeniyle her derleme başarısız olursa, ekipler bu özelliği tamamen devre dışı bırakır. Yeni kod yaklaşımı, mevcut borç ayrı olarak ele alınırken kanamayı durdurmanıza olanak tanır.
Zaman içinde kademeli eşik artışı. Önce daha temkinli eşiklerle başlayın, ardından ekip birikmiş işlerini temizledikçe her çeyrekte eşikleri sıkılaştırın. Bugün %75 kapsama oranıyla geçen bir aşama, temel seviye rahatlıkla bunun üzerine çıktığında %80'e güncellenebilir. Aşamalı sıkılaştırma, mükemmelliğe doğrudan ulaşmaktan daha sürdürülebilirdir.
Büyük Kod Tabanlarında Statik Analiz Performansının Yönetimi
Ekiplerin CI'da statik analizi devre dışı bırakmasının veya atlatmasının en yaygın nedeni, işlem hatlarını çok yavaşlatmasıdır. Bir özellik dalına yapılan her itme işleminde 15 dakikalık bir kalite taraması, geliştirici akışını öldürür. Analizi hızlı tutmak için çeşitli stratejiler mevcuttur:
Artımlı analiz (sadece yeni kodlar için). SonarQube ve çoğu kurumsal statik analiz aracı, tüm kod tabanı yerine yalnızca bir çekme isteğindeki değiştirilmiş dosyaları analiz etmeyi destekler. Yapılandır sonar.pullrequest.base, sonar.pullrequest.branch, ve sonar.pullrequest.key PR'ye özgü artımlı taramayı etkinleştirmek için parametreler. Tam analiz, ana dala birleştirme işleminde çalışmaya devam eder; PR taraması çoğu kod tabanında 2 dakikadan kısa sürede tamamlanır.
Önbelleğe almak. Birçok statik analiz çalışmasının en maliyetli kısmı, aracın ve kural tanımlarının indirilmesidir. Çalışmalar arasında tarayıcı ikili dosyasını, kural veritabanını ve çözümlenmiş tüm bağımlılıkları önbelleğe alın:
tatlım
# GitHub Actions: cache SonarCloud scanner
- name: Cache SonarCloud packages
uses: actions/cache@v4
with:
path: ~/.sonar/cache
key: ${{ runner.os }}-sonar
restore-keys: ${{ runner.os }}-sonarParalellik. Kod denetimi, güvenlik taraması ve kalite kontrol analizi birbirinden bağımsız işlemlerdir. Bunları ardışık olarak değil, paralel işler olarak çalıştırın. İşlem hattının toplam süresi, tüm işlerin toplamına değil, en yavaş işe göre belirlenir.
Seçici araç aktivasyonu. Her aracın her dalda çalışması gerekmez. Tam güvenlik taraması ve uyumluluk kontrolleri çekme isteklerinde ve ana dalda çalıştırılabilirken, birleştirme öncesi dallarda yalnızca hızlı linter'lar çalıştırılabilir. Farklı analiz profilleri uygulamak için CI yapılandırmasında dal filtrelerini kullanın.
Güvenlik Odaklı İşlem Hatlarında Statik Analiz: SAST ve Bağımlılık Taraması
Güvenlik odaklı işlem hatları, standart kalite analizinin ötesinde iki katman daha ekler: Uygulama kodu güvenlik açıkları için SAST (Statik Uygulama Güvenlik Testi) ve üçüncü taraf kütüphanelerdeki bilinen CVE'ler için bağımlılık taraması.
SAST araçları (Semgrep, CodeQL, Snyk Code, Checkmarx) güvenilmeyen verilerin uygulama kodu üzerinden hassas işlemlere nasıl ulaştığını analiz eder. Standart kalite kontrol araçlarının tespit edemediği SQL enjeksiyonu, XSS, komut enjeksiyonu, güvensiz seri hale getirme ve sabit kodlanmış kimlik bilgilerini bulurlar.
tatlım
# GitHub Actions: CodeQL analysis for deep vulnerability detection
- name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v3
with:
category: "/language:javascript-typescript"Bağımlılık taraması çekler package.json, pom.xml, requirements.txtve güvenlik açığı veritabanlarına karşı eşdeğer bildirim dosyaları:
tatlım
# Dependency audit in the pipeline
- name: Dependency audit
run: |
npm audit --audit-level=high
# Fail if high or critical vulnerabilities are foundKatmanlı güvenlik modeli, geliştiricilerden anında geri bildirim almak için her çekme isteğine hızlı kalıp tabanlı SAST (Semgrep) ve kapsamlı bir kapsama alanı için düzenli aralıklarla derin anlamsal SAST (CodeQL) uygular. Yeni CVE'ler günlük olarak yayınlandığı için bağımlılık taraması her derlemede çalışır.
Entegrasyonda Yapılan Sık Yapılan Hatalar ve Bunlardan Nasıl Kaçınılır
Analiz yalnızca ana dalda yürütülüyor. Statik analizin değeri, sorunları birleşmeden sonra değil, birleşmeden önce yakalamasındadır. Birleşmeden sonra çalışan analiz, bir kontrol noktası değil, bir rapor görevi görür.
Kalite kontrol noktalarını hata yerine uyarı verecek şekilde ayarlamak. İşlem hattını engellemeyen bir uyarı, geliştiricilerin görmezden gelmeyi öğrendiği bir bildirimdir. Başarısız olmayan kontrol noktaları, kalite kültürü oluşturmaz.
Test dosyalarını kapsama eşiklerinden hariç tutmamak. Başka test kodlarını test eden test kodları, şişirilmiş kod kapsamı sayıları üretir. Üretim kodu kod kapsamının doğru ölçümlerini elde etmek için test dizinlerini kapsam hesaplamalarından hariç tutun.
Eski kod tabanlarındaki analiz birikimini göz ardı etmek. Bir milyon satırlık eski bir kod tabanında SonarQube'u ilk kez çalıştırdığınızda 40,000 sorunla karşılaşmak moral bozucu ve verimsizdir. Yeni kod tabanı yaklaşımını kullanın: "Yeni kod" başlangıç tarihini tanımlayın, kontrolleri yalnızca bu tarihten sonra yazılan koda uygulayın ve mevcut sorun birikimini ayrı bir teknik borç azaltma programı olarak ele alın.
Kablolama işleminin sonuçlarını çekme isteği yorumlarına dahil etmemek Geliştiricilerin ziyaret etmesi gereken ayrı bir kontrol paneline gönderilen analiz sonuçları dikkate alınmaz. Çekme isteği inceleme arayüzünde, sorunlara yol açan belirli satırlara satır içi yorum olarak gönderilen analiz sonuçları ele alınır. Yapılandır sonar.pullrequest.* GitHub, GitLab veya Bitbucket entegrasyonu için parametreler, böylece bulgular kod incelemesinin yapıldığı yerde görünür.
Ne kadar SMART TS XL CI/CD işlem hatlarıyla entegre olur.
CI/CD işlem hatlarındaki statik analiz araçlarının çoğu aynı anda yalnızca bir dili görür. ESLint JavaScript'i görür. SonarQube Java, Python, JavaScript ve C#'ı görür. Ancak bunların hiçbiri COBOL, JCL, RPG veya bir ana bilgisayar toplu iş programını çıktısını tüketen Java mikroservisine ve bu mikroservisin çıktıyı görüntüleyen JavaScript ön ucuna bağlayan diller arası bağımlılıkları görmez.
SMART TS XL Kurumsal ortamdaki her dili aynı anda kapsayan, diller arası statik analiz katmanı olarak CI/CD işlem hatlarına entegre olur. Bir Java servisi değiştirildiğinde, SMART TS XL'S etki analizi Değişiklik dağıtılmadan önce, bağımlılık grafiğini izleyerek hangi COBOL programlarının, veritabanı şemalarının ve alt hizmetlerin bu değişiklikten etkilendiğini belirler. Bir COBOL copybook'u değiştirildiğinde, bu copybook'u içeren ve doğrulama gerektiren tüm uygulama portföyündeki her programı tanımlar.
Diller arası bağımlılık farkındalığı, onu mümkün kılan yetenektir. SMART TS XL'ın CI/CD entegrasyonu, SonarQube'a başka bir dil eklemekten farklıdır. Sadece değiştirilen dosyadaki kodu analiz etmekle ilgili değildir. Değişikliğin sistemde başka neleri etkileyeceğini anlamakla ilgilidir; bu da bir değişiklik yapılmadan önce gerçek kapsamını belirleyen mimari analizdir.
Hem eski hem de modern teknoloji yığınlarında faaliyet gösteren kurumsal geliştirme ekipleri için, SMART TS XL'S DevOps entegrasyonu Bu özellik, yapısal analizi işlem hattı inceleme iş akışına entegre ederek, dile özgü araçların sağlayamadığı mimari görünürlüğü sunar. Sonuç olarak, yalnızca bir dil sınırı içinde değil, tüm sistem genelinde standartları uygulayan kalite kontrol noktaları oluşturulur ve herhangi bir bileşendeki bir değişikliğin, ona bağlı bileşenlerde beklenmedik arızalara yol açmaması sağlanır.
Statik Analiz, Sürekli Gelişen Bir Bileşen Olarak
Statik analizi doğru yapan ekipler, onu test etme süreciyle aynı şekilde ele alırlar: geçilmesi gereken bir aşama olarak değil, her commit'e entegre edilmiş sürekli bir uygulama olarak. Analiz her pull request'te çalıştırılır. Kalite kontrol sonuçları kod incelemesiyle eş zamanlı olarak görünür. Kod tabanı geliştikçe eşikler daralır. Ekibin güvenlik ve kalite olgunluğu arttıkça yeni analiz kategorileri eklenir.
Bu makaledeki işlem hattı yapılandırma şablonları başlangıç noktalarıdır. Belirli araçlar, eşikler ve kontrol koşulları, projenin dil yığınına, risk profiline ve ekip olgunluğuna göre ayarlanmalıdır. Değişmemesi gereken şey ise ilkedir: Birleştirmeleri kontrol etmeyen analiz, davranışı değiştirmez ve kod kalitesi programlarının değiştirmeye çalıştığı şey de davranıştır.
