Как защитить код, написанный LLM: настройка SAST, Quality Gate и CI/CD пайплайн

Проблема: AI генерирует уязвимости быстрее, чем вы их находите

Вы ставите AI-ассистента разработчику, он радуется скорости написания кода, а через месяц у вас в продакшене SQL-инъекция, которую придумал не хакер, а ваша же подписка на GitHub Copilot. Звучит как плохой анекдот? Это реальность, с которой столкнулись десятки команд в 2025 году. К февралю 2025 года более 40% утечек данных в стартапах происходили из-за кода, сгенерированного или предложенного AI-ассистентами. Самый свежий пример — взлом Moltbook через дыру в Supabase, где уязвимость появилась в коде, написанном с помощью AI.

Три главные ловушки AI-кодинга мы разобрали в статье «Вайб-кодинг и безопасность». Если коротко: модель галлюцинирует безопасные паттерны, не видит контекст всей архитектуры и подвержена промпт-инъекциям. Результат — код, который вроде работает, но содержит бомбы замедленного действия.

Решение: автоматизированный DevSecOps на стероидах

Золотая пуля — настроить SAST (Static Application Security Testing), Quality Gate и завернуть их в CI/CD пайплайн. Но не абы как, а с учётом специфики AI-кода. Разработчики любят жать «merge» не читая, а AI любит генерировать eval() в критичных местах. Ваша задача — сделать так, чтобы такой код не прошёл дальше dev ветки.

Нам понадобятся инструменты последнего поколения: SonarQube 10.x, Semgrep v1.80+, CodeQL v2.19+, Checkmarx 2026. Все они активно обновляли правила для AI-генерированного кода в 2025-2026. Также стоит смотреть в сторону Snyk и Dependency Check для анализа зависимостей, но это уже лишнего не бывает.

Я покажу пошаговую настройку на примере GitLab CI/CD и GitHub Actions. Вы сможете адаптировать под себя.

Пошаговый план: от zero до героя DevSecOps

1 Выберите SAST-инструмент и настройте правила

Не берите один сканер — используйте связку. Semgrep хорош кастомными правилами и скоростью, CodeQL — глубиной анализа и поиском сложных уязвимостей, а SonarQube — как единое окно качества. Для AI-кода добавьте правила, ловящие типичные ошибки: использование exec/eval, неправильная конкатенация SQL, уязвимости в криптографии.

Пример правила Semgrep для Python, детектящего опасное eval:

rules:
  - id: dangerous-eval
    pattern: eval($X)
    message: "AI-generated code often uses eval without sanitization"
    languages: [python]
    severity: ERROR

Загрузите такое в репозиторий с правилами. В 2026 году Semgrep поддерживает Semgrep Registry for AI CWE — подключите его через semgrep --config p/ai-cwe.

2 Интегрируйте SAST в CI/CD

Добавьте этап сканирования в ваш пайплайн. Вот пример для GitLab CI (на основе свежих шаблонов 2026 года):

include:
  - template: Jobs/SAST.gitlab-ci.yml  # встроенный SAST с Semgrep
  - template: Jobs/Code-Quality.gitlab-ci.yml

sast:
  stage: test
  variables:
    SAST_EXCLUDED_PATHS: "tests, mocks"
    SAST_DISABLE_DIND: "true"
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Для GitHub Actions используем CodeQL:

name: "CodeQL Advanced"
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript, python, go
      - uses: github/codeql-action/analyze@v3
        with:
          category: "/language:javascript"

Обратите внимание: AI-код часто содержит несколько языков в одном проекте, поэтому укажите все нужные языки. CodeQL v2.19 добавил детекцию уязвимостей, характерных для LLM-агентов (например, генерация промптов, которые могут быть инъектированы) — это теперь встроено.

3 Настройте Quality Gate с учётом AI-фактора

Классический gate (покрытие 80%, 0 critical блокеров) не работает, когда 90% кода написано нейросетью. У AI другая плотность ошибок. Используйте следующие пороги:

В SonarQube создайте новый Quality Gate под названием AI-Safe. Привяжите его к проектам, где активно используется LLM. В 2026 году SonarQube позволяет динамически менять gate в зависимости от тега проекта — поставьте тег aigenerated на такие проекты.

4 Сканирование секретов и зависимостей

AI может случайно включить реальный API-ключ в код (например, из обучающих данных). Обязательно добавьте сканер секретов. GitLeaks и truffleHog обновлены до версий, которые ищут даже шаблонные ключи от LLM-провайдеров (OpenAI, Anthropic, Google AI).

Пример запуска truffleHog в GitLab CI:

secrets:
  stage: test
  script:
    - trufflehog filesystem --directory=$CI_PROJECT_DIR --fail --exclude-paths=.truffleignore
  allow_failure: false

Не забудьте настроить .truffleignore для сгенерированных папок (например, .venv, node_modules).

5 Обучите разработчиков и промпт-инжиниринг

Технические средства — половина дела. Разработчики должны понимать, как формулировать промпты, чтобы получать безопасный код. Подробно об этом мы писали в статье «Защита от prompt injection в продакшне». Главное правило: «Не проси AI написать фичу, проси написать фичу с учётом XSS защиты и проверкой ввода». Добавьте в ваш код-ревью с LLM автоматическую проверку безопасности — об этом отдельная статья.

6 Периодический аудит и обновление правил

AI-модели эволюционируют, и их ошибки тоже. Раз в месяц обновляйте правила SAST. Подпишитесь на CWE для AI, используйте фиды SonarQube. В 2026 году появился стандарт OWASP AI Top 10 — ваши SAST-правила должны его покрывать. Создайте custom rule для SonarQube на Python:

# custom_rule_eval.py (пример)
import ast

class EvalDetector(ast.NodeVisitor):
    def visit_Call(self, node):
        if isinstance(node.func, ast.Name) and node.func.id == 'eval':
            raise Exception("Use of eval detected")

Этот скрипт можно встроить в кастомный плагин SonarQube или использовать через SonarLint.

Нюансы и частые ошибки

Отдельного упоминания заслуживает проблема зелёного CI, когда пайплайн зелёный, а код архитектурно небезопасен. Об этом мы говорили в статье «Зелёный CI и пустая архитектура». Quality Gate не заменит человеческого ревью, но он отсечёт большую часть глупых ошибок.

Неочевидный совет: SAST + LLM-ревью

В 2026 году набирает обороты практика «AI-ревью кода, написанного AI». Например, настроить Claude Code на проверку кода после SAST. Запускаете сканер, получаете список проблем, скормите их LLM с контекстом — она даст рекомендации по безопасному рефакторингу. Это не замена человека, но отличный второй эшелон. Описание такого подхода — в статье «Код-ревью умерло? Да здравствует код-ревью с LLM».

Главное — не зацикливаться на инструментах. Пайплайн без культуры безопасности — просто декорация. Если команда слепо доверяет AI коду, никакой SAST не спасёт. Но если выстроить процесс: промпт -> код -> SAST -> Gate -> ревью — шанс пропустить уязвимость падает до статистической погрешности.

Подписаться на канал