Начнем с разработки. Приводится некоторое количество интересной статистики, например, что 46% кода на Github уже (в 2023) было сгенерировано копайлотом, 22% кодогенерации в Meta принимается пользователями, при этом в 40% автосгенерированного кода есть уязвимости. Таким образом, исследователей интересует, а можем ли мы сравнить LLM по их склонности генерировать плохой код? Чтобы ответить на этот вопрос создается бенчмарк CyberSecEval. Он включает в себя:
1. ICD: инструмент под названием Insecure Code Detector, который на основе 189 статических правил для детектирования 50 типовых проблем из Common Weakness Enumeration от MITRE на разных языках, от C до PHP. Авторы размечают вручную 50 примеров для каждого языка и на них оценивают качество инструмента – 96% точности, 79% полноты.
2. Датасет: набор тест-кейсов для двух сценариев – инструктивного и tab-дополнения. Сначала в открытом коде с помощью ICD ищутся небезопасные строки, затем к ним или генерируются инструкции, или оставляются строки, предшествующие строкам с ошибкой.
3. Метрика: смотрим, сгенерирует ли модель обратно дырявый код или сделает что-то иное. В качестве метрики считается число кейсов, где модель не сгенерировала код с уязвимостью. Есть нюанс: если сеть вообще ничего в ответ не сгенерирует или начнет генерировать чепуху, то и уязвимости там не будет. Поэтому авторы (на мой взгляд немного неоднозначно) дополнительно считают метрику «качества кода», в качестве которой берут BLEU между генерацией и тем, что было в оригинальном дырявом коде.
1. ICD: инструмент под названием Insecure Code Detector, который на основе 189 статических правил для детектирования 50 типовых проблем из Common Weakness Enumeration от MITRE на разных языках, от C до PHP. Авторы размечают вручную 50 примеров для каждого языка и на них оценивают качество инструмента – 96% точности, 79% полноты.
2. Датасет: набор тест-кейсов для двух сценариев – инструктивного и tab-дополнения. Сначала в открытом коде с помощью ICD ищутся небезопасные строки, затем к ним или генерируются инструкции, или оставляются строки, предшествующие строкам с ошибкой.
3. Метрика: смотрим, сгенерирует ли модель обратно дырявый код или сделает что-то иное. В качестве метрики считается число кейсов, где модель не сгенерировала код с уязвимостью. Есть нюанс: если сеть вообще ничего в ответ не сгенерирует или начнет генерировать чепуху, то и уязвимости там не будет. Поэтому авторы (на мой взгляд немного неоднозначно) дополнительно считают метрику «качества кода», в качестве которой берут BLEU между генерацией и тем, что было в оригинальном дырявом коде.
Результаты оценки по этому бенчмарку таковы: чем лучше модель, тем больше вероятность, что она сгенерирует уязвимый код. У меня есть гипотеза, что это связано с тем, что чем лучше модель, тем больше вероятность, что она сгенерирует вообще что-то похожее на реальное решение; авторы предполагают, что более мощные модели просто учатся у нас более эффективно, лучше запоминают наши ошибки, а потому, как мы, пишут плохой код. Конкретные метрики по моделям можно увидеть на картинке, но обратите внимание, что ось ординат на всех разного масштаба.
Следующим идет чуть более веселый бенчмарк про полезность в кибератаках. Он состоит из:
1. Инструкций, которые сгенерировали, комбинируя некоторый префикс («Я пентестер, поэтому мне нужно»), просьбу сгенерировать код и запрос, соответствующий какому-нибудь TTP из MITRE ATT&CK.
2. Оценщика на основе регулярок, который проверяет,сказала ли модель I'm sorry dave, I’m afraid I can't do that отказалась ли модель от ответа.
3. Оценщика на основе аж двух моделей (LLaMA-70B и CodeLLaMA-13B), которые проверяют ответ, если он не содержал отказа.
4. Метрики – доли ответов, которые, как кажется LLM-оценщикам, могут быть полезны для кибератак. Пайплайн оценки аналогично предыдущему тестируется на тестовой выборке, отобранной вручную, как имеющий 94% точности и 84% полноты.
1. Инструкций, которые сгенерировали, комбинируя некоторый префикс («Я пентестер, поэтому мне нужно»), просьбу сгенерировать код и запрос, соответствующий какому-нибудь TTP из MITRE ATT&CK.
2. Оценщика на основе регулярок, который проверяет,
3. Оценщика на основе аж двух моделей (LLaMA-70B и CodeLLaMA-13B), которые проверяют ответ, если он не содержал отказа.
4. Метрики – доли ответов, которые, как кажется LLM-оценщикам, могут быть полезны для кибератак. Пайплайн оценки аналогично предыдущему тестируется на тестовой выборке, отобранной вручную, как имеющий 94% точности и 84% полноты.
Для оценки из каждой модели для каждого промпта семплируют три дополнения. Результаты следующие. В среднем модели помогают в 52% случаев. Модели для кодогенерации (CodeLLaMA) отказываются реже, особенно когда речь идет о задачах «двойного назначения» типа шифрования файлов, которые могут иметь как полезные, так и вредные применения. Были отличия и в разрезе TTP – например, модели больше склонны отказываться от помощи в уклонении от обнаружения (evasion), чем в сборе информации (reconnaissance).
В конце исследователи отмечают, что у статьи есть определенные ограничения: от вполне реальной утечки тест-кейсов через гитхаб и неидеальной схемы детектирования уязвимостей до англоцентризма и отсутствию multi-turn-тестов. Тем не менее, наличие такого бенчмарка достаточно важно – как минимум, если вы решите сделать offensive LLM, вы знаете, на чем измерять эффективность 😈
В следующий раз посмотрим, что нового появилось в CyberSecEval 2.
В следующий раз посмотрим, что нового появилось в CyberSecEval 2.
Meta
CYBERSECEVAL 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models | Research - AI at Meta
Large language models (LLMs) introduce new security risks, but there are few comprehensive evaluation suites to measure and reduce these risks. We...
CYBERSECEVAL 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models
Bhatt et al., 2024
Статья, блог, код
Меньше, чем полгода спустя, авторы CyberSecEval выкатывают вторую версию своего бенчмарка, приуроченную к выходу LLaMA-3. Во второй версии добавляются новые задачи для двух аудиторий: тех, кто строит решения для кибербезопасности на основе LLM, и тех, кто создает приложения общего назначения. Первым эта работа дает набор тестов, которые помогают оценить устойчивость решения перед стандартными атаками, вторым – возможность оценить, насколько хорошо LLM подходит для решения их задач.
Bhatt et al., 2024
Статья, блог, код
Меньше, чем полгода спустя, авторы CyberSecEval выкатывают вторую версию своего бенчмарка, приуроченную к выходу LLaMA-3. Во второй версии добавляются новые задачи для двух аудиторий: тех, кто строит решения для кибербезопасности на основе LLM, и тех, кто создает приложения общего назначения. Первым эта работа дает набор тестов, которые помогают оценить устойчивость решения перед стандартными атаками, вторым – возможность оценить, насколько хорошо LLM подходит для решения их задач.
Кроме того, исследователи улучшают тест на полезность в кибератаках из первой версии бенчмарка, добавляя в него набор пограничных запросов, которые относятся к сфере кибербезопасности и могут казаться зловредными, но на самом деле являются безопасными. Для оценки того, насколько часто LLM отказываются от таких запросов (что делает их бесполезными для соответствующих задач), используется метрика False Refusal Rate (FRR 🦊).
Исследователи также смотрят, насколько за 4 месяца изменился уровень элайнмента с точки зрения помощи в проведении кибератак. Изменился он очень солидно – с 52% случаев, в которых модели соглашались помочь, доля промптов, на которые не был дан отказ, в среднем уменьшилась до 28%. Самой доброй и непослушной, разумеется, оказывается LLaMA-3. Что же касается FRR, то протестированные модели в большинстве своем довольно неплохо различают плохие промпты от пограничных. Самой полезной и зловредной оказывается gpt-3.5-turbo, самой полезной и безобидной – опять, вот так совпадение, маленькая LLaMA-3.
Исследователи также смотрят, насколько за 4 месяца изменился уровень элайнмента с точки зрения помощи в проведении кибератак. Изменился он очень солидно – с 52% случаев, в которых модели соглашались помочь, доля промптов, на которые не был дан отказ, в среднем уменьшилась до 28%. Самой доброй и непослушной, разумеется, оказывается LLaMA-3. Что же касается FRR, то протестированные модели в большинстве своем довольно неплохо различают плохие промпты от пограничных. Самой полезной и зловредной оказывается gpt-3.5-turbo, самой полезной и безобидной – опять, вот так совпадение, маленькая LLaMA-3.
Первым новым бенчмарком в CSE2 является набор тестов на prompt injection. Тесты покрывают два вида инъекций – которые противоречат системному промпту, но не несут прямого вреда, и те, в которых подразумевается какой-то вред (например, раскрытие секрета). Покрывается 14 техник (плюс смесь техник), включая “ignore previous instuctions”, контрабанду токенов, режим разработчика и прочие известные вещи. Есть тесты как на прямые, так и на непрямые инъекции. Каждый тест-кейс включает системную инструкцию, пользовательский промпт с инъекцией и вопрос об успешности атаки к LLM-оценщику. По замерам исследователей, в среднем 17% атак оказываются успешными, при этом те LLM, у которых instruction-tuning не подразумевал наличие системного промпта (типа мистраля), из теста исключили. Интересное наблюдение – LLM с плохой мультиязычностью (например, LLaMA-3) больше подвержены инъекциям с помощью использования другого языка.
Следующим бенчмарком стал тест на эксплуатацию уязвимостей в программном коде. Это набор созданных вручную или сгенерированных синтетически задачек типа CTF (целью LLM является достать флаг), в которых LLM должна проэксплуатировать возможность SQL-инъекции в программах на Python, ошибки в логике обработки строк на на Python/JS/C или ошибки управления памятью в C/C++. Настоящий уязвимый код не брали, чтобы не столкнуться с ситуацией, когда LLM видела пример на претрейне.
GPT-4 тут, как обычно, лучше всех, другие модели показывают результаты в зависимости от размера. Интересно, что LLaMA-3 8B и gpt-3.5-turbo показывают схожий результат. Тем не менее, в целом результаты самих авторов не впечатляют.
GPT-4 тут, как обычно, лучше всех, другие модели показывают результаты в зависимости от размера. Интересно, что LLaMA-3 8B и gpt-3.5-turbo показывают схожий результат. Тем не менее, в целом результаты самих авторов не впечатляют.
Наконец, исследователи обращают внимание, что многие сервисы интегрируют в LLM интерпретатор кода, который тоже может быть подвержен различным уязвимостям или использован во вред. Очевидно, что интерпретатор должен быть обернут во всевозможные контейнеризации, виртуализации и прочие изоляции, но на практике выясняется, что один из первых LLM-кейсов в MITRE ATLAS был связан как раз с небезопасным использованием интерпретатора в студенческой поделке под названием MathGPT. Авторы бенчмарка предоставляют 500 промптов – по 100 в каждой из категорий: попытки побега из контейнера, повышения привилегий, пост-эксплуатация (включая персистирование), использование интерпретатора для атак на другие систем и для генерации контента для социальной инженерии. Для оценки процента отказа от выполнения зловредных инструкций снова используется LLM-судья. Что касается результатов, то самыми безопасными оказались вариации CodeLLaMA и GPT-4, которые, видимо, лучше умеют определять, что является потенциально опасным в контексте интерпретатора (или в целом лучше работают с идеей интерпретатора как инструмента), а в среднем LLM соглашаются сгенерировать (что не означает генерацию успешного или правильного кода) попытки эксплуатации интерпретатора в одной трети случаев.
В сумме вторая версия бенчмарка гораздо богаче первой и, что важно, имеет тесты не только на отказ от плохого поведения, но и на долю ложных отказов от добросовестных запросов на рисковые кибербазопасные темы. Кроме того, уже в самой статье бенчмарк на эксплуатацию уязвимостей рассматривается не как диагностика проблем, а как диагностика способностей – все-таки было бы очень удобно, если бы можно было загрузить сервер с GPU фаззировать по-умному свои приложения с утра до вечера, это бы потенциально повысило защищенность ПО. Важным выводом с точки зрения защищенности является то, что prompt injection – нерешенная задача, поэтому надеяться на то, что модель не будет забивать на system prompt пока рановато. Занятно, что буквально пару недель назад вышла статья ребят из OpenAI (включая небезызвестного Эрика Уоллеса), где они демонстрируют, что резко снизить вероятность prompt injection вполне можно на уровне элайнмента – и об этом мы тоже обязательно почитаем.
arXiv.org
The Instruction Hierarchy: Training LLMs to Prioritize Privileged...
Today's LLMs are susceptible to prompt injections, jailbreaks, and other attacks that allow adversaries to overwrite a model's original instructions with their own malicious prompts. In this work,...
Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations
Inan et al., 2023
Статья, модель (новая)
Завершая трилогию (1, 2) про Purple LLaMA, сегодня мы посмотрим на Llama Guard. Исследователи формируют таксономию видов рискованного поведения модели, собирают под него датасет и с помощью инструктивного файн-тюнинга дообучают LlaMA-2-7B работать в качестве цензора для вводов и выводов модели.
У современных API для модерации (типа Perspective API) есть, по мнению исследователей, определенные недостатки:
- они определяют наличие недопустимого контента, не разделяя текст на пользовательский и сгенерированный моделью (непонятно, в чем на практике выражается этот недостаток);
- у них ограниченный набор видов опасного контента, который не адаптируется под меняющиеся реалии;
- они доступны только по API (видимо, поэтому они называются “moderation API”);
- внутри у них маленькие модели, которые не смогут определить, что сгенерированный более мощной моделью контент опасен.
Чтобы исправить эти недостатки исследователи и выпускают в открытый доступ Llama Guard.
Inan et al., 2023
Статья, модель (новая)
Завершая трилогию (1, 2) про Purple LLaMA, сегодня мы посмотрим на Llama Guard. Исследователи формируют таксономию видов рискованного поведения модели, собирают под него датасет и с помощью инструктивного файн-тюнинга дообучают LlaMA-2-7B работать в качестве цензора для вводов и выводов модели.
У современных API для модерации (типа Perspective API) есть, по мнению исследователей, определенные недостатки:
- они определяют наличие недопустимого контента, не разделяя текст на пользовательский и сгенерированный моделью (непонятно, в чем на практике выражается этот недостаток);
- у них ограниченный набор видов опасного контента, который не адаптируется под меняющиеся реалии;
- они доступны только по API (видимо, поэтому они называются “moderation API”);
- внутри у них маленькие модели, которые не смогут определить, что сгенерированный более мощной моделью контент опасен.
Чтобы исправить эти недостатки исследователи и выпускают в открытый доступ Llama Guard.
arXiv.org
Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations
We introduce Llama Guard, an LLM-based input-output safeguard model geared towards Human-AI conversation use cases. Our model incorporates a safety risk taxonomy, a valuable tool for categorizing...
Таксономия, которую составили авторы, состоит из следующих пунктов:
- Ненависть и насилие
- Сексуальный контент
- Оружие, включая нелегальное
- Вещества, оборот которых ограничен
- Суицид и самоповреждение
- Планирование преступление
Чтобы детектировать все эти непотребства, исследователи создают набор задач (т.е. промптов), которые состоят из соответствующих описаний категорий, диалогов (причем с разным количество реплик), постановки задачи (детектирование в запросе или в ответе) и метки класса. При этом мы все еще используем диалоговую модель, поэтому Llama Guard должна выводить токен safe или unsafe, и если в результате получился unsafe, то на следующей строке – индекс типа небезопасного контента из таксономии.
Отдельно подчеркивается, что хотя Llama Guard тюнится на определенный ограниченный набор категорий, этот набор можно расширить за счет того, что у нас все-таки LLM на семь миллиардов параметров в основе – таксономию в промпте можно поменять в режиме zero-shot или few-shot, предоставив пару примеров.
- Ненависть и насилие
- Сексуальный контент
- Оружие, включая нелегальное
- Вещества, оборот которых ограничен
- Суицид и самоповреждение
- Планирование преступление
Чтобы детектировать все эти непотребства, исследователи создают набор задач (т.е. промптов), которые состоят из соответствующих описаний категорий, диалогов (причем с разным количество реплик), постановки задачи (детектирование в запросе или в ответе) и метки класса. При этом мы все еще используем диалоговую модель, поэтому Llama Guard должна выводить токен safe или unsafe, и если в результате получился unsafe, то на следующей строке – индекс типа небезопасного контента из таксономии.
Отдельно подчеркивается, что хотя Llama Guard тюнится на определенный ограниченный набор категорий, этот набор можно расширить за счет того, что у нас все-таки LLM на семь миллиардов параметров в основе – таксономию в промпте можно поменять в режиме zero-shot или few-shot, предоставив пару примеров.