Как защитить прод от внедрения уязвимостей через LLM-интеграции: автоматизация аудита AI-кода

Denis Shokhirev

02 Jun 2026 — 3 min read

Я — Денис Шохирев, Enterprise AI архитектор из Фрайбурга, Германия, веду DennisCraft AI Studio и внедряю LLM-агентов в проде для B2B-клиентов по DACH. Мой стек за последний год — Claude, Supabase, n8n, Doppler, self-hosted Postgres. На практике вижу одну и ту же боль: через интеграцию LLM в продовую цепочку реально пролетают уязвимости, особенно когда генерация кода автоматизирована или полуавтоматизирована.

Типовые уязвимости через LLM: что реально встречается в проде

Я лично поймал за последние 6 месяцев 4 случая SQL-инъекций в сгенерированном коде DB-слоя (Claude Code, gpt-4, OpenAI cookbook). В 2 случаях — неправильная обработка user input, в 1 — небезопасная работа с Secrets через Doppler, еще 1 — банальная открытая запись в S3 без валидации. Сценарии типовые для интеграций через chain-of-tools (n8n), RAG-агентов и бэкенд-функций на Supabase. LLM не гарантирует secure-by-default, несмотря на промпт-инжиниринг и фильтры.

Почему LLM-код особенно уязвим

Генерируемый код часто не проходит ручной ревью (скорость выше).
LLM не учитывает всю бизнес-логику и ограничения среды.
Изменения могут попадать в прод через CI/CD pipeline автоматически.

Автоматизация аудита: какие инструменты реально работают

Вместо ручного аудита я вывел стабильный паттерн: автоматизировать прогон generated-кода через stateless security-сканеры и policy checks до попадания в staging/prod.

Инструмент	Тип анализа	Что ловит	Интеграция
semgrep	Static Analysis	SQL-инъекции, XSS, hardcoded secrets	CLI, n8n, GitHub Actions
bandit	Python Security	Уязвимости Python-кода	CLI, pre-commit
gitleaks	Secrets Detection	API-ключи, токены	CI/CD, pre-push

semgrep: быстрый статический анализ LLM-кода

semgrep отлично интегрируется в n8n workflow или как отдельный CLI-степ в CI. Правила под LLM-код можно доработать под свой стек:

semgrep --config=auto --include '**/*.py' --json > semgrep-report.json
cat semgrep-report.json | jq '.results[] | select(.extra.severity=="ERROR")'

Так фильтрую критичные ошибки до попадания кода на staging.

bandit: проверка Python-кода, сгенерированного LLM

bandit полезен, если агент генерирует Python-функции для Supabase или Postgres. Встраивается в pre-commit или CI:

bandit -r ./generated_code/ -f json -o bandit-report.json
cat bandit-report.json | jq '.results[] | select(.issue_severity=="HIGH")'

gitleaks: ловим секреты до их утечки

Если LLM случайно вставляет реальные ключи или токены в код (это бывает, когда промпт содержит sample secrets), gitleaks ловит их до пуша:

gitleaks detect --source=./generated_code/ --report-format=json --report-path=gitleaks.json
cat gitleaks.json | jq '.findings[] | select(.rule_id=="GithubToken")'

Интеграция аудита с n8n/Supabase: паттерн из прода

Я строю workflow так: каждый раз, когда LLM-агент генерирует новый кусок кода (скрипт, SQL-запрос, функцию), этот артефакт сразу прогоняется через chain security-сканеров. Если ошибка — код не попадает в staging, агент получает feedback с деталями и пробует регенерировать.

Пример step-флоу в n8n

LLM генерирует python/sql-код → сохраняет в temp storage
n8n запускает semgrep/bandit/gitleaks
Если есть ошибки — workflow кидает summary агенту в Claude/OpenAI для правки
Повтор до "чистого" прохождения

- name: LLM Code Generation
- name: semgrep Scan
  run: semgrep ...
- name: bandit Scan
  run: bandit ...
- name: gitleaks Scan
  run: gitleaks ...
- name: Conditional Feedback
  if: scan-failed
  action: prompt-agent-to-regenerate

Плюсы паттерна

Уязвимости ловятся до попадания в staging/prod.
Нет ручного ревью каждого патча.
Можно логировать и анализировать частые LLM-ошибки.

Мониторинг в проде: что не ловят статические сканеры

Статика — это 80% покрытия, но runtime-инъекции или обход ACL могут проскочить. В проде держу отдельный audit-лог (Postgres), где логируются все генерируемые LLM-запросы и их параметры. Плюс alert-правила на аномальные insert/update/delete (например, массовые изменения, неожиданные схемы).

Пример простого audit-триггера в Postgres

CREATE OR REPLACE FUNCTION audit_func()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO audit_log(table_name, changed_by, change_time)
  VALUES (TG_TABLE_NAME, current_user, NOW());
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER audit_trigger
AFTER INSERT OR UPDATE OR DELETE ON critical_table
FOR EACH ROW EXECUTE FUNCTION audit_func();

FAQ

Статика реально ловит 90% багов LLM-кода?

Нет. Из моего опыта — 60-70%. Остальное — логика, runtime-ошибки, обходы бизнес-правил.

Можно ли доверять LLM-коду без ручного ревью?

Нет. Даже с автоматизацией нужен хотя бы выборочный аудит, особенно для критичных функций.

Какой стек лучше для CI/CD в AI-проектах?

В проде у меня работают GitHub Actions + n8n для оркестрации, Supabase как BaaS, self-hosted Postgres для аудита.

Как мониторить runtime-атаки?

Через audit-логи, anomaly detection по паттернам запросов, алерты на необычные действия.

Какой сканер ловит больше всего багов?

semgrep по количеству находок самый эффективный, особенно для Python/JS-кода.

Вы где чаще всего ловите баги от LLM в проде — на статике, на runtime или уже когда клиент жалуется? Я делаю бесплатный 30-мин аудит AI-стека для B2B-проектов в регуляторных рынках. Пишите мне в LinkedIn или на @ger_dennis_ai.