В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.
Меня зовут Денис Макрушин, и в Yandex Infrastructure в команде SourceCraft я создаю платформу для безопасной разработки, которая помогает разрабатывать ПО и управлять процессом его производства на всех этапах жизненного цикла с использованием AI‑технологий. Вместе с коллегами я регулярно слежу за исследованиями, которые повышают производительность процессов безопасной разработки.
Команда нашего продукта изучает технологии, которые позволяют снизить когнитивную нагрузку на разработчика и AppSec‑инженера. В частности, мы исследуем технологии AutoFix и фреймворки для их оценки, чтобы адаптировать работающие практики и инструменты для наших задач.
В этой статье разберём, какие инновации принесли LLM в кибербезопасность, выделим инсайты и ключевые технологические ограничения, с которыми будем разбираться в 2025 году.
LLM-агенты пробовали автономно эксплуатировать известные уязвимости
И делали это с вероятностью успеха 87%. То есть, без помощи человека, модель смогла самостоятельно определить вектор эксплуатации обнаруженной уязвимости.
Исследователи собрали набор из 15 известных уязвимостей и скормили их описание из CVE агенту на базе разных генеративных моделей. В результате агент с GPT-4 успешно построил последовательность шагов для эксплуатации уязвимостей. А для некоторых веб‑уязвимостей (XSS, SQL injection) успешно сделал это без описания из CVE.
Это исследование подтверждает, что способности LLM подтолкнут развитие систем симуляции атак.
![Диаграмма системы поиска уязвимостей на основе LLM Изображение выглядит как текст, Шрифт, диаграмма, снимок экрана Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu.jpg)
Как только это исследование было опубликовано, сразу же появился разбор оригинальной статьи с аргументированной критикой. При этом, чтобы минимизировать субъективность в вопросе оценки способностей модели, исследователи используют различные бенчмарки. Например, для оценки возможностей LLM в задачах поиска и эксплуатации проведено и опубликовано ещё одно исследование:
-
Авторы разработали фреймворк SecLLMHolmes для автоматизированной оценки способностей LLM в задачах поиска и описания уязвимостей. В основе фреймворка находятся 228 сценариев уязвимого кода на С и Python, а также ключевые компоненты для реализации процесса оценки (набор параметров для LLM, набор промтов, модуль анализа ответов LLM)
-
Все языковые модели показали недетерминированные ответы. То есть при повторном запуске на одном и том же участке кода они давали разные результаты.
-
Даже если модели находили уязвимость, то давали её некорректное описание.
-
Наблюдались проблемы с устойчивостью моделей: незначительные дополнения кода вводили LLM в заблуждение.
![Архитектура системы SecLLMHolmes Изображение выглядит как текст, Шрифт, линия, белый Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-2.jpg)
Команда Google Project Zero также углубились в это направление и проверила гипотезу, что производительность больших языковых моделей в задачах обнаружения уязвимостей можно значительно улучшить.
Исследователи взяли опубликованную ранее методику оценки возможностей LLM для поиска и эксплуатации уязвимостей, доработали её и улучшили в 20 раз показатели LLM в тестах. Ключевые принципы, которые авторы применили в своих доработках:
-
пространство для рассуждений: дать модели возможность быть более «многословной» и через подробные рассуждения приходить к более точным результатам;
-
интерактивная среда: дать модели возможность взаимодействовать с тестовым окружением и корректировать свои ошибки;
-
инструменты: предоставить модели доступ к инструментам исследования (отладчик, интерпретатор кода Python), чтобы у неё была возможность получать детальную информацию о состоянии программы и влиять на это состояние;
-
проверка результата: обеспечить автоматически воспроизводимый результат;
-
стратегия отбора: дать модели возможность проверять несколько гипотез в рамках разных траекторий исследования.
![Архитектура фаззинг-системы на основе LLM Изображение выглядит как диаграмма, текст, линия, План Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-3.png)
В итоге LLM стал довольно эффективным, но пока ещё не самостоятельным инструментом для помощи в процессе поиска уязвимостей. До состояния полностью автономной системы есть большое пространство для исследований.
Исследователи искали способы оценки возможностей ИИ в обнаружении уязвимостей
При оценке эффективности моделей есть задача в выборе правильной методологии оценки. Пока ещё нет единственного универсального подхода к проведению оценки, исследователи закрывают эту проблему различными бенчмарками и фреймворками. Помимо рассмотренной методики от Google, есть ещё две свежих работы в этом направлении:
-
eyeballvul — методика оценки способностей LLM искать уязвимости в широком контексте (например, в целом репозитории кода). Автор взял более 5000 репозиториев, в которых содержится более 24 000 уязвимостей, и на этой базе предложил методику оценки. База обновляется еженедельно.
-
LLM4Vuln — фреймворк для оценки способностей LLM дополнять информацию об уязвимостях новыми данными (например, получение дополнительной информации о контексте).
![Фреймворк LLM4vuln для оценки способностей LLM к выявлению уязвимостей Изображение выглядит как текст, рукописный текст, Шрифт, диаграмма Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-4.jpg)
Принимаем мысль, что LLM пока что может использоваться исключительно в качестве ассистента для исследователя, и доводим модели до совершенства в узкоспециализированных сценариях. Фреймворки и бенчмарки помогут с этой задачей.
Например, можно взять два свежих бенчамарка для анализа возможностей ИИ в поиске уязвимостей и тестировании на проникновение:
-
Cybench — набор из 40 заданий Capture the Flag (CTF), которые содержат подзадачи для более точной оценки способностей языковых моделей. Задания разбиты на категории, знакомые CTF‑игрокам.
-
XBOW Validation Benchmarks. Компания XBOW специализируется на разработке средств автономной симуляции атак. Её набор состоит из 104 бенчмарков, каждый из которых содержит множество уязвимостей и множество вариантов их обнаружения.
Жду появления в классических CTF‑соревнованиях команды, состоящей из LLM‑агента и его оператора. Именно в классических вариантах, в которые играют реальные люди.
![Результаты тестирования моделей на наборе данных eyeballvul, которые показывают их точность, полноту и F1-меру (эта метрика позволяет оценить, насколько хорошо модель одновременно находит уязвимости и избегает ложные срабатывания) Результаты тестирования моделей на наборе данных eyeballvul, которые показывают их точность, полноту и F1-меру (эта метрика позволяет оценить, насколько хорошо модель одновременно находит уязвимости и избегает ложные срабатывания)](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-5.jpg)
ИИ помогал Red Team в процессе анализа защищенности
Встретил репозиторий с набором сценариев использования ИИ в реальных атаках. Автор этой коллекции сопоставил техники матрицы MITRE ATT&CK с известными случаями применения генеративных моделей в реальных атаках.
Примеры интересных кейсов:
-
проведение разведки с использованием LLM: сбор и анализ информации из открытых источников о цели для точного определения поверхности атаки;
-
применение LLM для ускорения процесса разработки имплантов;
-
упрощение процесса исследования уязвимостей с помощью LLM.
![Один год вместе с LLM в кибербезопасности: как ИИ менял индустрию - 6 IMG_0362.jpeg](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-6.jpg)
Эти же сценарии для своих задач могут позаимствовать эксперты Red Team и специалисты по тестированию на проникновения.
ИИ помогал security-архитектору в определении скоупа для анализа защищенности
Разработчики научили генеративную модель выделять из описания релиза ключевые нововведения и изменения. Таким образом, она подсказывает, нужно ли проводить ручной анализ, и какой должен быть скоуп у этой проверки.
Модель анализирует каждый пул-реквест, дополняет его соответствующей информацией из Jira и делает выводы для команды наступательной безопасности о том, где и как сфокусировать усилия в ходе ручного анализа защищённости данного релиза. С учётом частоты релизов и сотен пул-реквестов в каждом, этот сценарий использования экономит усилия команды на определение приоритетов в ходе ручных проверок, потому что система сокращает количество PR, которые необходимо проверять вручную, с 400 в среднем до менее чем 100
Забираем метод и результаты исследования для внедрения в свой процесс безопасной разработки.
![Процесс проведения security review с помощью LLM Изображение выглядит как рисунок, зарисовка, текст, диаграмма Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-7.png)
ИИ использовался в качестве ассистента для security-аналитика
Интересный кейс применения для разработки правил выявления угроз:
-
аналитик загружает в LLM техники атак, описанные в формате поста в блог или отчёта об угрозе;
-
в запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта;
-
модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промт).
Самый ресурсоемкий для аналитика этап — составление точного промта. Поэтому важно отработать навык prompt engineering.
Так как написание правил — это процесс, который зачастую происходит в свободное от обработки инцидентов время, то этот сценарий залетает в бэклог к лидеру Security Operations.
![Система генерации сигнатур для выявления угроз Изображение выглядит как текст, рукописный текст, Шрифт, диаграмма Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-8.png)
ИИ пробовал повысить производительность разработки…
Генеративный ИИ повышает производительность разработки. Или нет?
Встретил свежую исследовательскую работу, в которой подтверждается данная гипотеза и утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%.
Методика исследования:
-
Три рандомизированных контролируемых эксперимента в реальных условиях на примере трёх компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.
-
Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.
-
Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных пул‑реквестов, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.
Пул‑реквест, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:
-
Высока вариативность в результатах, поскольку на производительность разработчиков влияет их опыт, навыки и типы выполняемых задач. Принцип распределения разработчиков на кластеры в данном эксперименте непрозрачен.
-
Эксперименты проводились в реальных рабочих условиях, где на производительность разработчиков могли влиять различные факторы, не поддающиеся контролю, например, изменения в проектах или командные взаимодействия.
Действительно ли в количестве пул‑реквестов измеряется производительность разработки — вопрос всё ещё открытый.
… и помогал разработчику исправлять дефекты в коде
Вендоры крупных платформ разработки и стартапы с разной степенью успеха создают технологию AutoFix. В её основе находятся LLM, которые анализируют уязвимость и её контекст, а затем предлагают вариант её исправления. Насколько хорошо у них это получается, можно судить по текущим результатам:
-
наиболее «зрелые» модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;
-
коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.
То есть, использовать Autofix можно, но внедрять исправленный код в продакшн без дополнительной верификации нужно аккуратнее. Например, исправление проблемы, связанной со слабым шифрованием или использованием небезопасных протоколов, может привести к сбоям в работе приложения.
Есть и другие ограничения:
-
сложности с зависимостями и импортами: модели часто не могут правильно обработать сложные зависимости и импорты в кодовой базе. Например, когда LLM предлагает переписать код для использования методов безопасной сериализации, но не предлагает импортировать библиотеку для этой задачи
-
LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;
-
недостаточный контекст: модели часто предлагают исправления, которые не соответствуют шаблонам проектирования или общей архитектуре проекта.
![Упрощённая версия процесса обработки уязвимостей и генерации исправлений от разработчиков Semgrep Assistant Изображение выглядит как текст, диаграмма, Шрифт, План Автоматически созданное описание](https://www.braintools.ru/images/2025/01/24/odin-god-vmeste-s-LLM-v-kiberbezopasnosti-kak-ii-menyal-industriyu-9.png)
С учётом этих ограничений, разработчики технологий AutoFix используют пользовательские подсказки вместе с большим контекстом о коде. Пользователь может указать предпочтительные библиотеки (например, для логирования, алгоритмов шифрования и генерации случайных чисел).
Помимо инструкций от пользователя, увеличить точность ответов помогает механизм повторных попыток. LLM генерирует несколько исправлений для одной и той же уязвимости и таким образом увеличивает шансы на получение правильного варианта.
Двигаемся в 2025 — там ещё больше инноваций
Уже сегодня большие языковые модели позволяют автоматизировать процесс исправления уязвимостей в коде, разрабатывать правила выявления угроз и улучшать качество кодовой базы. Примеры такого использования появляются и у нас. Так, сервис для комплексного управления безопасностью в облаке Security Deck с помощью нейросети YandexGPT суммаризирует информацию и предоставляет её в удобном виде. Это экономит когнитивное топливо специалистов по информационной безопасности.
Большие языковые модели уже доказали свою полезность в задачах кибербезопасности, и в некоторых задачах значительно экономят ресурсы security‑инженеров и аналитиков. Но в большинстве сценариев LLM пока остаются лишь инструментами‑ассистентами для исследователей и разработчиков.
Совершенствование технологий, таких как AutoFix, и разработка новых бенчмарков для оценки эффективности модели в определённых задачах приближают нас к созданию автономных систем для поиска и исправления уязвимостей. Тем не менее, многие ограничения — от недостаточного контекста до проблем с зависимостями — показывают, что результаты ещё далеки от идеала. 2025 год обещает ещё больше открытий, которые помогут преодолеть существующие барьеры и вывести безопасность разработки на новый уровень. Поэтому следим за инновациями и внедряем те из них, которые помогут сэкономить больше «когнитивного топлива».
Автор: makrushin