В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.

Меня зовут Денис Макрушин, и в Yandex Infrastructure в команде SourceCraft я создаю платформу для безопасной разработки, которая помогает разрабатывать ПО и управлять процессом его производства на всех этапах жизненного цикла с использованием AI‑технологий. Вместе с коллегами я регулярно слежу за исследованиями, которые повышают производительность процессов безопасной разработки.

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

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

LLM-агенты пробовали автономно эксплуатировать известные уязвимости

И делали это с вероятностью успеха 87%. То есть, без помощи человека, модель смогла самостоятельно определить вектор эксплуатации обнаруженной уязвимости.

Исследователи собрали набор из 15 известных уязвимостей и скормили их описание из CVE агенту на базе разных генеративных моделей. В результате агент с GPT-4 успешно построил последовательность шагов для эксплуатации уязвимостей. А для некоторых веб‑уязвимостей (XSS, SQL injection) успешно сделал это без описания из CVE.

Это исследование подтверждает, что способности LLM подтолкнут развитие систем симуляции атак.

Как только это исследование было опубликовано, сразу же появился разбор оригинальной статьи с аргументированной критикой. При этом, чтобы минимизировать субъективность в вопросе оценки способностей модели, исследователи используют различные бенчмарки. Например, для оценки возможностей LLM в задачах поиска и эксплуатации проведено и опубликовано ещё одно исследование:

• Авторы разработали фреймворк SecLLMHolmes для автоматизированной оценки способностей LLM в задачах поиска и описания уязвимостей. В основе фреймворка находятся 228 сценариев уязвимого кода на С и Python, а также ключевые компоненты для реализации процесса оценки (набор параметров для LLM, набор промтов, модуль анализа ответов LLM)

• Все языковые модели показали недетерминированные ответы. То есть при повторном запуске на одном и том же участке кода они давали разные результаты.

• Даже если модели находили уязвимость, то давали её некорректное описание.

• Наблюдались проблемы с устойчивостью моделей: незначительные дополнения кода вводили LLM в заблуждение.

Команда Google Project Zero также углубились в это направление и проверила гипотезу, что производительность больших языковых моделей в задачах обнаружения уязвимостей можно значительно улучшить.

Исследователи взяли опубликованную ранее методику оценки возможностей LLM для поиска и эксплуатации уязвимостей, доработали её и улучшили в 20 раз показатели LLM в тестах. Ключевые принципы, которые авторы применили в своих доработках:

• пространство для рассуждений: дать модели возможность быть более «многословной» и через подробные рассуждения приходить к более точным результатам;

• интерактивная среда: дать модели возможность взаимодействовать с тестовым окружением и корректировать свои ошибки;

• инструменты: предоставить модели доступ к инструментам исследования (отладчик, интерпретатор кода Python), чтобы у неё была возможность получать детальную информацию о состоянии программы и влиять на это состояние;

• проверка результата: обеспечить автоматически воспроизводимый результат;

• стратегия отбора: дать модели возможность проверять несколько гипотез в рамках разных траекторий исследования.

В итоге LLM стал довольно эффективным, но пока ещё не самостоятельным инструментом для помощи в процессе поиска уязвимостей. До состояния полностью автономной системы есть большое пространство для исследований.

Исследователи искали способы оценки возможностей ИИ в обнаружении уязвимостей

При оценке эффективности моделей есть задача в выборе правильной методологии оценки. Пока ещё нет единственного универсального подхода к проведению оценки, исследователи закрывают эту проблему различными бенчмарками и фреймворками. Помимо рассмотренной методики от Google, есть ещё две свежих работы в этом направлении:

• eyeballvul — методика оценки способностей LLM искать уязвимости в широком контексте (например, в целом репозитории кода). Автор взял более 5000 репозиториев, в которых содержится более 24 000 уязвимостей, и на этой базе предложил методику оценки. База обновляется еженедельно.

• LLM4Vuln — фреймворк для оценки способностей LLM дополнять информацию об уязвимостях новыми данными (например, получение дополнительной информации о контексте).

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

Например, можно взять два свежих бенчамарка для анализа возможностей ИИ в поиске уязвимостей и тестировании на проникновение:

• Cybench — набор из 40 заданий Capture the Flag (CTF), которые содержат подзадачи для более точной оценки способностей языковых моделей. Задания разбиты на категории, знакомые CTF‑игрокам.

• XBOW Validation Benchmarks. Компания XBOW специализируется на разработке средств автономной симуляции атак. Её набор состоит из 104 бенчмарков, каждый из которых содержит множество уязвимостей и множество вариантов их обнаружения.

Жду появления в классических CTF‑соревнованиях команды, состоящей из LLM‑агента и его оператора. Именно в классических вариантах, в которые играют реальные люди.

ИИ помогал Red Team в процессе анализа защищенности

Встретил репозиторий с набором сценариев использования ИИ в реальных атаках. Автор этой коллекции сопоставил техники матрицы MITRE ATT&CK с известными случаями применения генеративных моделей в реальных атаках.

Примеры интересных кейсов:

• проведение разведки с использованием LLM: сбор и анализ информации из открытых источников о цели для точного определения поверхности атаки;

• применение LLM для ускорения процесса разработки имплантов;

• упрощение процесса исследования уязвимостей с помощью LLM.

Эти же сценарии для своих задач могут позаимствовать эксперты Red Team и специалисты по тестированию на проникновения.

ИИ помогал security-архитектору в определении скоупа для анализа защищенности

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

Модель анализирует каждый пул-реквест, дополняет его соответствующей информацией из Jira и делает выводы для команды наступательной безопасности о том, где и как сфокусировать усилия в ходе ручного анализа защищённости данного релиза. С учётом частоты релизов и сотен пул-реквестов в каждом, этот сценарий использования экономит усилия команды на определение приоритетов в ходе ручных проверок, потому что система сокращает количество PR, которые необходимо проверять вручную, с 400 в среднем до менее чем 100

Забираем метод и результаты исследования для внедрения в свой процесс безопасной разработки.

ИИ использовался в качестве ассистента для security-аналитика

Интересный кейс применения для разработки правил выявления угроз:

• аналитик загружает в LLM техники атак, описанные в формате поста в блог или отчёта об угрозе;

• в запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта;

• модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промт).

Самый ресурсоемкий для аналитика этап — составление точного промта. Поэтому важно отработать навык prompt engineering.

Так как написание правил — это процесс, который зачастую происходит в свободное от обработки инцидентов время, то этот сценарий залетает в бэклог к лидеру Security Operations.

ИИ пробовал повысить производительность разработки…

Генеративный ИИ повышает производительность разработки. Или нет?

Встретил свежую исследовательскую работу, в которой подтверждается данная гипотеза и утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%.

Методика исследования:

• Три рандомизированных контролируемых эксперимента в реальных условиях на примере трёх компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.

• Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.

• Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных пул‑реквестов, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.

Пул‑реквест, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:

• Высока вариативность в результатах, поскольку на производительность разработчиков влияет их опыт, навыки и типы выполняемых задач. Принцип распределения разработчиков на кластеры в данном эксперименте непрозрачен.

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

Действительно ли в количестве пул‑реквестов измеряется производительность разработки — вопрос всё ещё открытый.

… и помогал разработчику исправлять дефекты в коде

Вендоры крупных платформ разработки и стартапы с разной степенью успеха создают технологию AutoFix. В её основе находятся LLM, которые анализируют уязвимость и её контекст, а затем предлагают вариант её исправления. Насколько хорошо у них это получается, можно судить по текущим результатам:

• наиболее «зрелые» модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;

• коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.

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

Есть и другие ограничения:

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

• LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;

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

С учётом этих ограничений, разработчики технологий AutoFix используют пользовательские подсказки вместе с большим контекстом о коде. Пользователь может указать предпочтительные библиотеки (например, для логирования, алгоритмов шифрования и генерации случайных чисел).

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

Двигаемся в 2025 — там ещё больше инноваций

Уже сегодня большие языковые модели позволяют автоматизировать процесс исправления уязвимостей в коде, разрабатывать правила выявления угроз и улучшать качество кодовой базы. Примеры такого использования появляются и у нас. Так, сервис для комплексного управления безопасностью в облаке Security Deck с помощью нейросети YandexGPT суммаризирует информацию и предоставляет её в удобном виде. Это экономит когнитивное топливо специалистов по информационной безопасности.

Большие языковые модели уже доказали свою полезность в задачах кибербезопасности, и в некоторых задачах значительно экономят ресурсы security‑инженеров и аналитиков. Но в большинстве сценариев LLM пока остаются лишь инструментами‑ассистентами для исследователей и разработчиков.

Совершенствование технологий, таких как AutoFix, и разработка новых бенчмарков для оценки эффективности модели в определённых задачах приближают нас к созданию автономных систем для поиска и исправления уязвимостей. Тем не менее, многие ограничения — от недостаточного контекста до проблем с зависимостями — показывают, что результаты ещё далеки от идеала. 2025 год обещает ещё больше открытий, которые помогут преодолеть существующие барьеры и вывести безопасность разработки на новый уровень. Поэтому следим за инновациями и внедряем те из них, которые помогут сэкономить больше «когнитивного топлива».