Kuidas integreerida staatilise koodi analüüsi CI/CD torujuhtmetesse?

IN-COM Juuni 11, 2026 Tehniline vestlus

Iga tootmiskeskkonda jõudva koodirea on kinnitanud keegi, kes uskus, et see on õige. Staatiline koodianalüüs on automatiseeritud süsteem, mis kontrollib, kas see uskumus oli õige, mitte koodi käivitades, vaid lugedes selle struktuuri, jälgides andmevooge ja võrreldes seda teadaolevate haavatavuste, vigade ja kvaliteedirikkumiste mustritega. Küsimus ei ole selles, kas seda käivitada, vaid selles, kus etapis seda käivitada, millist tööriista kasutada, milliseid lävesid rakendada ja kuidas tagasisidet piisavalt kiiresti edastada, et arendajad selle põhjal tegutseksid, mitte ei ignoreeriks seda.

Staatilise analüüsi kui märkeruutude tegevuse ja staatilise analüüsi kui tõelise kvaliteedivärava erinevus seisneb konfiguratsioonis. Skanneerimine, mis käivitab ja loob aruande, mida keegi ei loe, on teater. Kvaliteedivärav, mis nurjub ehituse, kui ilmnevad uued kriitilised haavatavused, blokeerib ühendamise, kui katvus langeb alla läve, ja kuvab pull-taotluse läbivaatamise liideses täpset faili- ja reatagasisidet, on süsteem, mis muudab käitumist otsuste tegemise hetkel.

Sisukord

Kus torujuhtmes staatilise analüüsi käivitada

Staatiline analüüs peaks toimuma mitmes punktis, millest igaühel on erinev eesmärk. Selle käivitamine ainult ühes punktis loob pimeala; selle käivitamine kõikjal võrdselt loob aeglased torujuhtmed, millest arendajad mööda marsruutivad.

Torujuhtme etapp	Mida joosta	Latentsusaja eelarve	Eesmärk
Eelkinnitus (kohalik)	Ainult kiired linterid (ESLint, Clippy, rustfmt)	Alla 5 sekundi	Peatage ilmsed probleemid enne, kui need repositooriumisse jõuavad
Tõmbetaotlus / liitmistaotlus	Täielik linting + SAST + astmeline SonarQube'i skannimine	Alla 3 minuti	Uute kriitiliste probleemide korral ühendamiste blokeerimine
Peaharu ehitus	Täielik analüüs, mis hõlmab katvust, dubleerimist ja tehnilist võlga	Alla 10 minuti	Jälgige kvaliteeditrende, värskendage juhtpaneele
Planeeritud igal õhtul	Süvakontrollid, sõltuvusaudit, vastavuskontrollid	Eelarvet pole	Aeglase ehituse probleemide ja tarneahela riskide tuvastamine

Kõige väärtuslikum etapp on pull request . Analüüs, mis käivitatakse põhikoodile push-päringu alusel, saabub pärast ühendamise otsuse tegemist. Analüüs, mis käivitatakse pull requesti alusel ja postitab tekstisiseseid kommentaare täpse faili- ja reakontekstiga, saabub siis, kui arendaja on veel koodi kallal ja parandamise kulud on madalaimad.

Iga salvestuse eelnev ulatuslik analüüs kahjustab arendaja kogemust. Kiired linterid, mis valmivad alla 5 sekundiga, kuuluvad sinna. Kõik muu kuulub CI-sse.

GitHubi toimingud: töökonfiguratsiooni lõpuleviimine

GitHub Actions on kõige laialdasemalt kasutatav CI platvorm. Järgmine töövoog käitab kihilist kvaliteedikontrolli: vormindamise kontroll, linting, build, SAST turvakontroll ja SonarCloud kvaliteedikontroll.

yaml

# .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 }}

omadused

# 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.js

Selle töövoo peamised konfiguratsiooniotsused:

--max-warnings 0 ESLintis: iga hoiatus on ehitusviga. Meeskonnad, mis lubavad hoiatusi, kuhjavad neid seni, kuni keegi neid ei loe.
fetch-depth: 0 kassas: SonarCloud vajab täielikku giti ajalugu, et tekitatud probleemidele süüd määrata ja uue koodi mõõdikuid õigesti arvutada.
Semgrep töötab lint-skaneerimisel paralleelselt Sonariga: turvalisuse ja kvaliteedi skaneerimine on sõltumatud probleemid; nende paralleelne käivitamine vähendab kogu konveieri aega.
Testid käivitatakse koos lcov Katvuse väljund: SonarCloud loeb seda, et kuvada failide katvust ja jõustada kvaliteediväravas katvuse läviväärtusi.

GitLab CI/CD: kvaliteeditorustik koos kvaliteediväravatega

yaml

# .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"

. artifacts: reports: sast: plokk integreerib Semgrepi SARIF-väljundi otse GitLabi turbe armatuurlauale, kus tulemused kuvatakse ühendamistaotluse turbearuandes, mitte toore CI-logi väljundina.

Jenkins: deklaratiivne torujuhe SonarQube'iga

õnarakujuline

// 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 on kriitiline rida. See küsitleb SonarQube'i, kuni analüüs on lõppenud, ja kui kvaliteedikriteeriumit ei täideta, siis ehitus nurjub. Ilma selleta lõpeb torujuhe analüüsi ajal ja kvaliteedikriteeriumi tulemust ei rakendata kunagi.

Kvaliteediväravate seadistamine, mida meeskonnad tegelikult austavad

Kvaliteedivärav, mis iga commit'i puhul liiga agressiivsete lävede tõttu ebaõnnestub, keelatakse. See, mis kunagi liiga leebete lävede tõttu ebaõnnestub, ei paku mingit väärtust. Eesmärk on värav, mis on kalibreeritud projekti tegeliku riskiprofiiliga.

Uue SonarQube kvaliteedivärava soovitatav algkonfiguratsioon:

meetriline	Tingimus	Künnis
Uued vead	Suurem kui	0
Uued haavatavused	Suurem kui	0
Uued turvapunktid üle vaadatud	Vähem kui	100%
Uus koodi hõlmatus	Vähem kui	80%
Uued dubleeritud read	Suurem kui	3%
Uus kood lõhnab	Suurem kui	10

Rakenda neid lävendeid ainult uuele koodile (SonarQube'is „uue koodi“ periood). Ära rakenda neid kogu pärandprojekti koodibaasile, sest iga ehituse ebaõnnestumine viie aasta jooksul kogunenud tehnilise võla tõttu paneb meeskonnad värava täielikult keelama. Uue koodi lähenemine võimaldab sul verejooksu peatada, samal ajal kui olemasolevat võlga eraldi käsitletakse.

Muutke lävendeid aja jooksul. Alustage konservatiivsetest lävedest ja seejärel karmistage neid igal kvartalil, kui meeskond oma mahajäämust likvideerib. Täna 75% katvusega läbitud läve saab uuendada 80%-ni, kui baasjoon on sellest mugavalt kõrgemal. Järkjärguline karmistamine on jätkusuutlikum kui täiuslikkuse poole hüppamine.

Staatilise analüüsi jõudluse käsitlemine suurtes koodibaasides

Kõige levinum põhjus, miks meeskonnad CI-s staatilise analüüsi keelavad või sellest mööda suunavad, on see, et see muudab torujuhtmed liiga aeglaseks. 15-minutiline kvaliteedikontroll iga funktsiooniharu suunamise kohta peatab arendaja töövoo. Analüüsi kiirena hoidmiseks on mitu strateegiat:

Inkrementaalne analüüs (ainult uus kood). SonarQube ja enamik ettevõtte staatilise analüüsi tööriistu toetavad ainult muudetud failide analüüsimist pull requestis, mitte kogu koodibaasi. sonar.pullrequest.base, sonar.pullrequest.branchja sonar.pullrequest.key parameetrid PR-spetsiifilise astmelise skaneerimise lubamiseks. Täielik analüüs töötab endiselt põhikoodiga ühendamisel; PR-skannimine kestab enamikus koodibaasides alla 2 minuti.

Vahemällu salvestamine. Paljude staatilise analüüsi käivitamiste kõige kallim osa on tööriista ja selle reeglite definitsioonide allalaadimine. Vahemällu salvestage skanneri binaarfail, reeglite andmebaas ja kõik lahendatud sõltuvused käivitamiste vahel:

yaml

# 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 }}-sonar

Paralleelsus. Linting, turvaskannimine ja kvaliteedivärava analüüs on sõltumatud ülesanded. Käivitage neid paralleelsetes töödes, mitte järjestikku. Torujuhtme koguaeg määratakse kõige aeglasema töö, mitte kõigi tööde summa järgi.

Valikuline tööriista aktiveerimine. Kõik tööriistad ei pea töötama igas harus. Täielik turvaskannimine ja vastavuskontrollid saavad töötada nii pull requestidel kui ka põhiharudel, samas kui ühendamiseelsed harud käitavad ainult kiireid lintereid. Erinevate analüüsiprofiilide rakendamiseks kasutage CI konfiguratsioonis harufiltreid.

Staatiline analüüs turvalisuspõhistes torujuhtmetes: SAST ja sõltuvuste skaneerimine

Turvalisusele keskendunud torujuhtmed lisavad tavapärasele kvaliteedianalüüsile kaks kihti: SAST (staatiline rakenduste turvalisuse testimine) rakenduskoodi haavatavuste jaoks ja sõltuvuste skaneerimine teadaolevate CVE-de leidmiseks kolmandate osapoolte teekides.

SAST-tööriistad (Semgrep, CodeQL, Snyk Code, Checkmarx) analüüsivad, kuidas ebausaldusväärsed andmed rakenduse koodis tundlike toiminguteni jõuavad. Nad leiavad SQL-süstimist, XSS-i, käskude süstimist, ebaturvalist deserialiseerimist ja kõvakodeeritud volitusi, mida standardkvaliteediga linterid ei suuda tuvastada.

yaml

# 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"

Sõltuvuste skaneerimine kontrolli package.json, pom.xml, requirements.txtja samaväärsed manifestifailid haavatavuste andmebaaside vastu:

yaml

# Dependency audit in the pipeline
- name: Dependency audit
  run: |
    npm audit --audit-level=high
    # Fail if high or critical vulnerabilities are found

Kihiline turvamudel paigutab igale PR-ile kiire mustripõhise SAST-i (Semgrep), et anda arendajale kohest tagasisidet, ja ajakava alusel sügava semantilise SAST-i (CodeQL), et tagada põhjalik katvus. Sõltuvuste skannimine toimub igal järkul, kuna uusi CVE-sid avaldatakse iga päev.

Levinud integratsioonivead ja kuidas neid vältida

Analüüsi käivitamine ainult peaharul. Staatilise analüüsi väärtus seisneb probleemide tuvastamises enne nende ühendamist, mitte pärast. Analüüs, mis käivitatakse alles pärast ühendamist, toimib aruandena, mitte väravana.

Kvaliteediväravate seadistamine hoiatama, mitte ebaõnnestuma. Hoiatus, mis ei blokeeri torujuhet, on teade, mida arendajad õpivad ignoreerima. Väravad, mis ei ebaõnnestu, ei loo kvaliteedikultuuri.

Testfaile ei jäeta katvuslävedest välja. Testimiskoodi testimine teiste testimiskoodidega annab paisutatud katvusnumbreid. Tootmiskoodi katvuse täpsete mõõtmiste saamiseks jätke testkataloogid katvusarvutustest välja.

Pärandkoodibaaside analüüsi mahajäämuse ignoreerimine. SonarQube'i esmakordne sisselülitamine miljoni rea pikkusel pärandkoodibaasil ja 40 000 probleemi saamine on demotiveeriv ja kahjulik. Kasutage uue koodi baasjoone lähenemisviisi: määrake „uue koodi” alguskuupäev, rakendage piire ainult pärast seda kuupäeva kirjutatud koodile ja käsitlege olemasolevat probleemide mahajäämust eraldi tehnilise võla vähendamise programmina.

Tulemusi ei lisata pull request'i kommentaaridesse. Arendajate külastatavale eraldi armatuurlauale postitatud analüüsitulemusi ignoreeritakse. Pull Request'i läbivaatamise liideses probleeme tekitanud ridadele kommentaaridena postitatud analüüsitulemustega tegeletakse. sonar.pullrequest.* GitHubi, GitLabi või Bitbucketi integratsiooni parameetrid, et leiud ilmuksid seal, kus toimub koodi läbivaatamine.

Kuidas SMART TS XL Integreerub CI/CD torujuhtmetega

Enamik CI/CD torujuhtmete staatilise analüüsi tööriistu näeb korraga ühte keelt. ESLint näeb JavaScripti. SonarQube näeb Javat, Pythoni, JavaScripti ja C#-d. Ükski neist ei näe COBOLi, JCL-i, RPG-d ega keeltevahelisi sõltuvusi, mis ühendavad suurarvuti pakktöötlusprogrammi Java mikroteenusega, mis selle väljundit tarbib, mis omakorda loob ühenduse JavaScripti esiotsaga, mis seda kuvab.

SMART TS XL integreerub CI/CD torujuhtmetesse keelteülese staatilise analüüsi kihina, mis hõlmab samaaegselt kõiki ettevõtte keskkonnas olevaid keeli. Kui Java-teenust muudetakse, SMART TS XL'S mõju analüüs Jälgib sõltuvusgraafikut, et tuvastada enne muudatuse juurutamist, milliseid COBOL-programme, andmebaasiskeeme ja allavoolu teenuseid see muudatus mõjutab. Kui COBOL-i käsiraamatut muudetakse, tuvastab see kõik programmid kogu rakenduste portfellis, mis seda käsiraamatut sisaldavad ja vajavad valideerimist.

See keelteülene sõltuvuste teadlikkus on võime, mis teeb SMART TS XLCI/CD integratsioon erineb SonarQube'ile uue keele lisamisest. See ei seisne ainult muudetud faili koodi analüüsimises. See seisneb ka selles, et mõista, mida süsteemis veel see muudatus mõjutab, ehk arhitektuurianalüüsis, mis määrab muudatuse tegeliku ulatuse enne selle tegemist.

Ettevõtte arendusmeeskondadele, kes töötavad nii vanade kui ka moodsate platvormide vahel, SMART TS XL'S DevOpsi integratsioon See võimekus integreerib selle struktuurianalüüsi torujuhtme ülevaatuse töövoogu, pakkudes arhitektuurilist nähtavust, mida keelepõhised tööriistad ei suuda pakkuda. Tulemuseks on kvaliteediväravad, mis jõustavad standardeid mitte ainult keelepiiride piires, vaid kogu süsteemis, tagades, et ühegi komponendi muutmine ei too kaasa ootamatuid tõrkeid sellest sõltuvates komponentides.

Staatiline analüüs kui püsiv torujuhtme kodanik

Meeskonnad, kes teevad staatilise analüüsi õigesti, käsitlevad seda samamoodi nagu testimist: mitte kui läbitavat etappi, vaid kui pidevat praktikat, mis on igasse commit'i sisse põimitud. Analüüs toimub iga pull requesti puhul. Kvaliteedikontrolli tulemused kuvatakse koodi läbivaatamise käigus. Läviväärtused vähenevad koodibaasi paranedes. Uusi analüüsikategooriaid lisatakse meeskonna turvalisuse ja kvaliteedi küpsuse kasvades.

Selles artiklis olevad torujuhtme konfiguratsioonimallid on lähtepunktid. Konkreetsed tööriistad, läviväärtused ja väravatingimused tuleks kalibreerida vastavalt projekti keelevalikule, riskiprofiilile ja meeskonna küpsusele. Põhimõte ei tohiks muutuda: analüüs, mis ei arvesta liitmistega, ei muuda käitumist ja käitumine on see, mida koodikvaliteedi programmid püüavad muuta.