Генеративный код и массовые уязвимости
Внедрение инструментов на базе искусственного интеллекта в процесс разработки программного обеспечения привело к парадоксальной ситуации. С одной стороны, разработчики получили возможность писать код значительно быстрее. Модели вроде GitHub Copilot или локальные LLM генерируют готовые фрагменты, функции и даже целые модули по текстовому описанию. Однако у этой скорости есть обратная сторона — генеративные модели склонны повторять паттерны, которые они видели во время обучения. Если в обучающих данных присутствовали небезопасные практики (например, использование устаревших функций без проверки входных данных), ИИ будет воспроизводить их массово.
Это приводит к эффекту «уязвимостей пачками». Вместо единичных ошибок человеческий фактор заменяется системным. Одна логическая ошибка в запросе к нейросети или одна слабая закономерность в её весах может породить десятки одинаковых дыр в безопасности в разных частях приложения. Код выглядит рабочим, он проходит тесты на функциональность, но содержит скрытые бреши, такие как SQL-инъекции, незащищенное хранение секретов или неправильная настройка прав доступа.
Проблема шума от SAST-сканеров
Традиционным ответом индустрии на рост числа уязвимостей стали статические анализаторы кода (SAST). Эти инструменты автоматически сканируют кодовую базу в поисках известных сигнатур проблем. Но когда разработчик начинает использовать ИИ для написания кода, количество срабатываний SAST возрастает экспоненциально. Инструменты начинают выдавать сотни предупреждений.
Здесь возникает главная проблема AppSec-процессов — информационная перегрузка. До 90% отчетов SAST-систем могут составлять ложноположительные срабатывания (false positives). Разработчик тратит часы на разбор отчета, чтобы найти одну реальную угрозу среди сотен несуществующих. В условиях жестких дедлайнов это приводит к «усталости от алертов» (alert fatigue): команда начинает игнорировать отчеты целиком или отключает строгие правила анализа, что сводит безопасность к нулю.
Использование локальных LLM для фильтрации сработок
Решением проблемы переизбытка информации становится применение того же инструмента, который создает проблему, — языковой модели. Идея заключается в том, чтобы поставить вторую нейросеть в качестве интеллектуального фильтра между SAST-сканером и человеком. Этот подход часто называют концепцией 'AI проверяет AI'.
Процесс выглядит следующим образом:
- Статический анализатор выдает сырой список уязвимостей с указанием строк кода и описанием типа ошибки.
- Локально развернутая модель (LLM) получает на вход фрагмент кода, описание потенциальной уязвимости и контекст проекта.
- Модель оценивает вероятность реальной угрозы. Она способна понимать семантику кода гораздо глубже, чем классический поиск по регулярным выражениям.
Преимущество использования именно локальных моделей критически важно. Отправка проприетарного исходного кода во внешние облачные API несет риски утечки коммерческой тайны. Локальная установка гарантирует, что данные остаются внутри периметра компании, при этом позволяя гибко дообучать модель под специфику своего стека технологий.
Как отличить настоящую уязвимость
Чтобы эффективно отличать реальные угрозы от шума, аналитикам необходимо настроить промпты (запросы) для проверяющей LLM так, чтобы она учитывала несколько факторов:
- Проверка санитизации: Анализирует ли код входящие данные перед использованием? Если перед выполнением запроса стоит функция очистки спецсимволов, то предполагаемая SQL-инъекция является ложной.
- Контекст исполнения: Выполняется ли данный участок кода на сервере или только в браузере клиента? Некоторые уязвимости актуальны только для backend-логики.
- Наличие компенсирующих контролей: Защищен ли эндпоинт фреймворком или WAF (Web Application Firewall) на уровне инфраструктуры?
Такой симбиоз позволяет автоматизировать первичный триаж. Нейросеть берет на себя рутинную проверку очевидных false positive, оставляя инженерам по безопасности только те случаи, где действительно требуется экспертное решение архитектурной задачи.