AI-инструменты для анализа уязвимостей кода

Когда мы начали внедрять LLM в продуктовые сценарии, ожидание было довольно простым: основная сложность будет в моделях (в качестве ответов, стабильности, промптах).

На практике всё оказалось иначе.

Проблемы начали появляться не в самой LLM, а там, где она впервые стала взаимодействовать с кодом, API и данными внутри системы. В этих местах привычные подходы к code review перестали работать так, как мы привыкли.

И самое неприятное: часть рисков вообще не попадала в ревью. Код выглядел корректным, тесты проходили, но поведение системы в реальных сценариях начинало расходиться с ожиданиями.

Статический анализ кода – довольно зрелая история.

Он хорошо справляется с ошибками в логике, типах, работе с API и безопасностью на уровне приложения.

Но с LLM есть нюанс. Мы это заметили на обычных задачах: код проходит ревью, всё выглядит нормально, но система ведёт себя иначе.

И почти всегда причина одна: часть логики уходит из кода в модель.

С LLM уязвимости начинают выглядеть не как ошибки в коде, а как сценарии поведения системы. И это довольно быстро ломает привычное восприятие безопасности.

В классическом приложении всё линейно: вход → обработка → результат. В LLM-интеграции между этим появляется слой, который ведёт себя не детерминированно.

В этот момент начинают происходить странные вещи.

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

Самое сложное здесь не баги как таковые. А то, что с точки зрения кода все выглядит нормально.

Изначально у нас была довольно прикладная задача: автоматически проверять pull request’ы на LLM-риски.

Это был внутренний инструмент, скорее вспомогательный слой к обычному ревью. Он просто подсвечивал подозрительные места в коде.

Но довольно быстро стало понятно, что этого недостаточно.

Со временем инструмент превратился в AI-агента для code review.

Вместе с этим поменялась глубина анализа. Он начал:

Постепенно агент стал частью обычного CI-процесса.

Чем больше AI-функций появляется в продуктах, тем сильнее размывается граница между кодом и поведением модели.

В какой-то момент становится очевидно: классического code review уже недостаточно. Не потому что он плохой, а потому что система стала другой.

Самый важный сдвиг здесь даже не технический. Мы перестали воспринимать LLM как отдельный компонент. И начали воспринимать её как часть архитектуры, которая требует отдельного слоя контроля.

Следующий шаг – наблюдаемость поведения модели в продакшене:

Фактически это уже новый слой инженерии (AI-observability).

Одна из базовых проблем LLM-систем — слишком прямой переход от модели к действиям.

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

Поэтому между LLM и системой всегда должен быть детерминированный слой проверки, который валидирует результат до выполнения.

Промпт-инъекции почти никогда не выглядят как атака.

Чаще это обычный текст внутри документа, письма или пользовательского ввода.

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

Один из самых недооценённых рисков – слишком широкие права у AI-агента.

Если агент работает с правами администратора, любая ошибка модели автоматически превращается в системную.

Поэтому уровень доступа должен быть строго ограничен.

Полная автономность LLM на критических действиях почти всегда создаёт операционные риски.

Особенно в финансах, юридических процессах и внешних коммуникациях.

В таких сценариях модель должна не выполнять действие, а только готовить его.

Отдельный класс рисков появляется, когда LLM начинает генерировать и исполнять код.

Без изоляции это означает прямой доступ к системе и данным.

Поэтому среда исполнения должна быть sandbox по умолчанию.

LLM в продакшене быстро перестаёт быть просто «фичей с AI».

Она становится частью системы: со своими ограничениями, правилами и рисками.

И чем раньше это учитывается на уровне архитектуры, тем меньше неожиданностей появляется уже в проде.