Как интегрировать статический анализ кода в конвейеры CI/CD?

ИН-КОМ 11 июня 2026 Tech Talk

Каждая строка кода, попадающая в продакшн, была написана кем-то, кто считал её правильной. Статический анализ кода — это автоматизированная система, которая проверяет правильность этого убеждения не путём запуска кода, а путём чтения его структуры, отслеживания потоков данных и сравнения с известными шаблонами уязвимостей, ошибок и нарушений качества. Вопрос не в том, запускать ли его, а в том, где в конвейере его запускать, какой инструмент использовать, какие пороговые значения установить и как обеспечить достаточно быструю обратную связь, чтобы разработчики действительно реагировали на неё, а не игнорировали.

Разница между статическим анализом как формальностью и статическим анализом как настоящим контролем качества заключается в конфигурации. Сканер, который запускается и выдает отчет, который никто не читает, — это показуха. Контроль качества, который прерывает сборку при обнаружении новых критических уязвимостей, блокирует слияние, когда покрытие кода падает ниже порогового значения, и отображает точную информацию о файлах и строках в интерфейсе проверки запросов на слияние, — это система, которая меняет свое поведение в момент принятия решений.

Содержание

На каком этапе конвейера следует запускать статический анализ?

Статический анализ следует запускать в нескольких точках, каждая из которых служит разным целям. Запуск только в одной точке создает «слепые зоны»; запуск везде одинаково часто приводит к замедлению конвейеров разработки, которые разработчики вынуждены обходить.

Стадия трубопровода	Что бежать	Бюджет задержки	Цель
Предварительное подтверждение (локальное)	Только быстрые линтеры (ESLint, Clippy,rustfmt)	До 5 секунд	Предотвращайте очевидные проблемы до того, как они попадут в репозиторий.
Запрос на слияние / запрос на добавление изменений	Полная проверка синтаксиса + SAST + инкрементальное сканирование SonarQube	Менее 3 минут	Блоковые слияния по новым критически важным вопросам
сборка основной ветки	Полный анализ, включая охват, дублирование, технический долг.	Менее 10 минут	Отслеживайте тенденции качества, обновляйте панели мониторинга.
Запланировано на ночь	Глубокое сканирование, аудит зависимостей, проверки на соответствие требованиям.	Нет бюджета	Выявление проблем, связанных с медленным темпом производства, и рисков в цепочке поставок.

Наиболее ценным этапом является запрос на слияние (pull request) . Анализ, запускаемый при отправке изменений в основную ветку (main), поступает после принятия решения о слиянии. Анализ, запускаемый при запросе на слияние и добавляющий встроенные комментарии с точным контекстом файла и строки, поступает, когда разработчик еще работает с кодом и стоимость исправления минимальна.

Запуск ресурсоемкого анализа перед каждым сохранением убивает удобство работы разработчиков. Быстрые линтеры, выполняющиеся менее чем за 5 секунд, должны быть реализованы в системе непрерывной интеграции (CI). Все остальное должно быть реализовано в CI.

GitHub Actions: Полная рабочая конфигурация

GitHub Actions — наиболее широко используемая платформа непрерывной интеграции (CI). Следующий рабочий процесс запускает многоуровневый конвейер проверки качества: проверка форматирования, линтинг, сборка, сканирование безопасности с помощью SAST и проверка качества SonarCloud.

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

свойствами

# 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

Ключевые решения по настройке в этом рабочем процессе:

--max-warnings 0 В ESLint: любое предупреждение — это ошибка сборки. Команды, которые допускают предупреждения, накапливают их до тех пор, пока никто их не прочитает.
fetch-depth: 0 При оформлении заказа: SonarCloud требуется полная история Git, чтобы определить ответственных за внесенные изменения и корректно рассчитать метрики нового кода.
Semgrep работает после проверки синтаксиса параллельно с Sonar: проверка безопасности и качества являются независимыми задачами; их параллельное выполнение сокращает общее время выполнения конвейера.
Тесты, выполненные с помощью lcov Вывод данных о покрытии: SonarCloud считывает эти данные, чтобы показать покрытие для каждого файла и установить пороговые значения покрытия в окне контроля качества.

GitLab CI/CD: конвейер контроля качества с контрольными точками качества.

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: Этот блок интегрирует выходные данные SARIF из Semgrep непосредственно в панель безопасности GitLab, где результаты отображаются в отчете о безопасности запроса на слияние, а не в виде необработанных логов CI.

Jenkins: декларативный конвейер с SonarQube

заводной

// 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 Это критически важная строка. Она опрашивает SonarQube до завершения анализа и завершает сборку с ошибкой, если не соблюдены критерии качества. Без нее конвейер завершается, пока анализ еще не завершен, и результат проверки качества никогда не будет соблюден.

Настройка контрольных точек качества, которые команды действительно уважают.

Контрольный пункт качества, который проваливается при каждом коммите из-за слишком агрессивных пороговых значений, отключается. Тот, который никогда не проваливается из-за слишком либеральных пороговых значений, не представляет никакой ценности. Цель — контрольный пункт, откалиброванный в соответствии с фактическим профилем риска проекта.

Рекомендуемая начальная конфигурация для нового контрольного фильтра качества SonarQube:

Метрика	Состояние	порог
Новые ошибки	Больше	0
Новые уязвимости	Больше	0
Рассмотрены новые уязвимости системы безопасности.	Менее	100%
Новое покрытие кода	Менее	80%
Новые дублирующиеся строки	Больше	3%
Новые запахи кода	Больше	10

Применяйте эти пороговые значения только к новому коду (период «нового кода» в SonarQube). Не применяйте их ко всей кодовой базе устаревшего проекта, поскольку сбои при каждой сборке из-за накопленного за пять лет технического долга приводят к тому, что команды полностью отключают этот контроль. Подход с использованием нового кода позволяет остановить утечку кода, пока существующий долг решается отдельно.

Постепенно повышайте пороговые значения. Начните с консервативных пороговых значений, а затем ужесточайте их каждый квартал по мере того, как команда обрабатывает накопившиеся задачи. Если сегодня этап пройден с 75% охвата, то после достижения базового уровня он может быть повышен до 80%. Постепенное ужесточение более устойчиво, чем стремление к совершенству.

Управление производительностью статического анализа в больших кодовых базах

Наиболее распространенная причина, по которой команды отключают или обходят статический анализ в CI, заключается в том, что он слишком замедляет конвейеры. 15-минутная проверка качества при каждом изменении в ветке разработки замедляет работу разработчиков. Существует несколько стратегий, позволяющих ускорить анализ:

Поэтапный анализ (только для нового кода). SonarQube и большинство корпоративных инструментов статического анализа поддерживают анализ только измененных файлов в запросе на слияние, а не всего кода. Настройте sonar.pullrequest.base, sonar.pullrequest.branch и sonar.pullrequest.key Параметры для включения инкрементального сканирования, специфичного для запросов на слияние. Полный анализ по-прежнему выполняется при слиянии с основной веткой; сканирование запросов на слияние занимает менее 2 минут в большинстве кодовых баз.

Кэширование. Самая затратная часть многих запусков статического анализа — это загрузка инструмента и определений правил. Кэшируйте исполняемый файл сканера, базу данных правил и все разрешенные зависимости между запусками:

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

Параллелизм. Проверка синтаксиса, сканирование на безопасность и анализ качества являются независимыми задачами. Запускайте их параллельно, а не последовательно. Общее время выполнения конвейера определяется самой медленной задачей, а не суммой всех задач.

Выборочная активация инструментов. Не каждый инструмент должен запускаться на каждой ветке. Полное сканирование безопасности и проверки соответствия могут выполняться для запросов на слияние и основной ветки, в то время как для веток, предшествующих слиянию, запускаются только быстрые линтеры. Используйте фильтры веток в конфигурации CI для применения различных профилей анализа.

Статический анализ в конвейерах, ориентированных на безопасность: SAST и сканирование зависимостей

Конвейеры тестирования, ориентированные на безопасность, добавляют два уровня к стандартному анализу качества: статическое тестирование безопасности приложений (SAST) для выявления уязвимостей в коде приложений и сканирование зависимостей на наличие известных CVE в сторонних библиотеках.

Инструменты SAST (Semgrep, CodeQL, Snyk Code, Checkmarx) анализируют, как ненадежные данные проходят через код приложения, чтобы получить доступ к конфиденциальным операциям. Они обнаруживают SQL-инъекции, XSS-атаки, внедрение команд, небезопасную десериализацию и жестко закодированные учетные данные, которые стандартные линтеры качества не могут обнаружить.

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"

Сканирование зависимостей проверки package.json, pom.xml, requirements.txtи эквивалентные файлы манифеста для баз данных уязвимостей:

YAML

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

Многоуровневая модель безопасности включает в себя быстрое семантическое тестирование на основе шаблонов (Semgrep) для каждого запроса на слияние (PR) для немедленной обратной связи от разработчиков, а также углубленное семантическое тестирование на основе шаблонов (CodeQL) по расписанию для тщательного анализа. Сканирование зависимостей выполняется при каждой сборке, поскольку новые уязвимости CVE публикуются ежедневно.

Распространенные ошибки интеграции и как их избежать

Анализ выполняется только в основной ветке. Ценность статического анализа заключается в выявлении проблем до их слияния, а не после. Анализ, выполняемый только после слияния, служит отчетом, а не контролирующим фактором.

Настройка контрольных точек качества таким образом, чтобы они выдавали предупреждения, а не завершались с ошибкой. Предупреждение, которое не блокирует конвейер, — это уведомление, которое разработчики учатся игнорировать. Контрольные точки, которые не завершаются с ошибкой, не способствуют формированию культуры качества.

Не исключайте тестовые файлы из пороговых значений покрытия. Тестирование кода, тестирующего другой тестовый код, приводит к завышенным показателям покрытия. Исключите тестовые каталоги из расчетов покрытия, чтобы получить точные измерения покрытия кода в производственной среде.

Игнорирование накопившихся задач анализа устаревшего кода. Первый запуск SonarQube на коде объемом в миллион строк и получение 40 000 проблем демотивирует и контрпродуктивен. Используйте подход с базовым уровнем нового кода: определите дату начала разработки «нового кода», применяйте ограничения только к коду, написанному после этой даты, и рассматривайте существующий список задач как отдельную программу сокращения технического долга.

Не включайте результаты в комментарии к запросам на слияние. Результаты анализа, размещенные на отдельной панели мониторинга, которую должны посещать разработчики, игнорируются. Результаты анализа, размещенные в виде встроенных комментариев к конкретным строкам, вызвавшим проблемы, в интерфейсе проверки запросов на слияние, обрабатываются. Настройка sonar.pullrequest.* Параметры для интеграции с GitHub, GitLab или Bitbucket, чтобы результаты отображались там, где происходит проверка кода.

Как SMART TS XL Интегрируется с конвейерами CI/CD.

Большинство инструментов статического анализа в конвейерах CI/CD видят только один язык программирования за раз. ESLint видит JavaScript. SonarQube видит Java, Python, JavaScript и C#. Ни один из них не видит COBOL, JCL, RPG или кросс-языковые зависимости, которые связывают пакетную программу мэйнфрейма с микросервисом Java, который обрабатывает ее выходные данные, а тот, в свою очередь, подключается к JavaScript-интерфейсу, отображающему эти данные.

SMART TS XL Интегрируется в конвейеры CI/CD в качестве кросс-языкового слоя статического анализа, охватывающего одновременно все языки корпоративной среды. При изменении Java-сервиса, SMART TS XLАвтора анализ воздействия Отслеживает граф зависимостей, чтобы определить, какие программы COBOL, схемы баз данных и нижестоящие сервисы затронуты этим изменением, прежде чем оно будет развернуто. При изменении COBOL-копибука он идентифицирует каждую программу во всем портфеле приложений, которая включает этот копибук и нуждается в проверке.

Именно это понимание межъязыковой зависимости и является той способностью, которая делает возможным SMART TS XLИнтеграция CI/CD в SonarQube отличается от добавления еще одного языка в SonarQube. Речь идет не просто об анализе кода в измененном файле. Речь идет о понимании того, на что еще в системе повлияет это изменение, а именно об архитектурном анализе, который определяет истинный масштаб изменения до его внесения.

Для команд разработчиков, работающих с устаревшими и современными технологиями, SMART TS XLАвтора Интеграция DevOps Эта возможность интегрирует структурный анализ в рабочий процесс проверки конвейера, обеспечивая архитектурную прозрачность, недоступную для инструментов, специфичных для конкретного языка программирования. В результате создаются контрольные точки качества, которые обеспечивают соблюдение стандартов не только в рамках одного языка, но и во всей системе, гарантируя, что изменение любого компонента не приведет к неожиданным сбоям в компонентах, зависящих от него.

Статический анализ как постоянный участник конвейера

Команды, которые правильно организуют статический анализ, относятся к нему так же, как и к тестированию: не как к этапу, который нужно пройти, а как к непрерывной практике, встроенной в каждый коммит. Анализ выполняется для каждого запроса на слияние (pull request). Результаты проверки качества отображаются одновременно с результатами проверки кода. Пороговые значения ужесточаются по мере улучшения кодовой базы. Новые категории анализа добавляются по мере роста уровня зрелости команды в области безопасности и качества.

Представленные в этой статье шаблоны конфигурации конвейера являются отправными точками. Конкретные инструменты, пороговые значения и условия контроля должны быть откалиброваны в соответствии с языковым стеком проекта, профилем риска и уровнем зрелости команды. Неизменным должен оставаться принцип: анализ, не контролирующий слияния, не меняет поведения, а именно поведение и стремятся изменить программы обеспечения качества кода.