Генерируйте и молитесь: использование SALLMS для оценки безопасности кода, сгенерированного LLM: Аннотация и введение
9 февраля 2024 г.:::информация Этот документ доступен на arxiv под лицензией CC 4.0.
Авторы:
(1) Мохаммед Латиф Сиддик, факультет компьютерных наук и инженерии, Университет Нотр-Дам, Нотр-Дам;
(2) Джоанна К.С. Сантос, факультет компьютерных наук и инженерии, Университет Нотр-Дам, Нотр-Дам.
:::
Таблица ссылок
- Абстрактное и amp; Введение
- Предыстория и мотивация
- Наша структура: SALLM
- Эксперименты
- Результаты
- Ограничения и угрозы действительности
- Связанные работы
- Выводы и amp; Ссылки
Аннотация
С ростом популярности больших языковых моделей (например, GitHub Copilot, ChatGPT и т. д.) в повседневной практике разработчиков программного обеспечения важно гарантировать, что код, создаваемый этими инструментами, не только функционально корректен, но и не содержит ошибок. уязвимости. Хотя LLM могут помочь разработчикам работать более продуктивно, предыдущие эмпирические исследования показали, что LLM могут генерировать небезопасный код. Генерации небезопасного кода способствуют два фактора. Во-первых, существующие наборы данных, используемые для оценки моделей большого языка (LLM), неадекватно отражают реальные задачи разработки программного обеспечения, чувствительные к безопасности. Вместо этого они часто основаны на соревновательных задачах по программированию или задачах по программированию в классе. В реальных приложениях созданный код интегрируется в более крупные базы кода, что создает потенциальные угрозы безопасности. Налицо явное отсутствие тестов, направленных на оценку безопасности сгенерированного кода. Во-вторых, существующие метрики оценки в первую очередь ориентированы на функциональную корректность сгенерированного кода, игнорируя при этом соображения безопасности. Такие метрики, как pass@k, измеряют вероятность получения правильного кода в топ-k предложениях. Другие популярные метрики, такие как BLEU, CodeBLEU, ROUGE и METEOR, также подчеркивают функциональную точность, игнорируя последствия для безопасности. В свете этих пробелов в исследованиях в этой статье мы описали SALLM, структуру для оценки способностей LLM систематически генерировать безопасный код. Эта платформа состоит из трех основных компонентов: новый набор данных подсказок Python, ориентированных на безопасность, среда оценки для тестирования сгенерированного кода и новые метрики для оценки производительности моделей с точки зрения создания безопасного кода.
1 Введение
код LLM – это модель большого языка (LLM), обученная на большом наборе данных, состоящем как из текста, так и из кода. В результате кодовые LLM могут генерировать код, написанный на определенном языке программирования, из заданной подсказки. Эти подсказки обеспечивают высокоуровневую спецификацию намерений разработчика [34].
Подсказки могут включать одно- или многострочные комментарии к коду, выражения кода (например, определение функции), текст или их комбинацию. и т. д. Учитывая подсказку в качестве входных данных, LLM генерирует новые токены один за другим, пока не достигнет стоповой последовательности (т. е. предварительно настроенной последовательности токенов) или пока не будет достигнуто максимальное количество токенов.
С недавними выпусками GitHub Copilot [25] и ChatGPT [2] инструменты генерации исходного кода на основе LLM все чаще используются разработчиками для сокращения усилий по разработке программного обеспечения [77]. Недавний опрос 500 американских разработчиков, работающих в крупных компаниях, показал, что 92% из них используют LLM для создания кода для работы и личного использования [60]. Частично такое быстрое распространение связано с возросшей производительностью, которую воспринимают разработчики; LLM помогают им автоматизировать повторяющиеся задачи, чтобы они могли сосредоточиться на сложных задачах более высокого уровня [77].
Хотя методы генерации кода на основе LLM могут создавать функционально правильный код, предыдущие работы показали, что они также могут генерировать код с уязвимостями и запахами безопасности [51, 52, 58]. Предыдущее исследование также продемонстрировало, что обучающие наборы, обычно используемые для обучения и/или точной настройки LLM, содержат вредоносные шаблоны кодирования, которые просачиваются в сгенерированный код [62]. Более того, недавнее исследование [52] с 47 участниками показало, что люди, использовавшие LLM codex-davinci-002, писали код, который был менее безопасным по сравнению с теми, кто его не использовал. Хуже того, участники, использовавшие LLM, с большей вероятностью считали, что их код безопасен, в отличие от их коллег, которые не использовали LLM для написания кода.
Есть два основных фактора, способствующих генерации небезопасного кода. Во-первых, LLM кода оцениваются с помощью тестов, которые не включают в себя конструкции для оценки безопасности сгенерированного кода [63, 75]. Во-вторых, существующие метрики оценки (например, pass@k [11], CodeBLEU [56] и т. д.) оценивают производительность моделей с точки зрения их способности создавать функционально правильный код, игнорируя при этом проблемы безопасности. Таким образом, производительность, сообщаемая для этих моделей, чрезмерно сосредоточена на повышении точности сгенерированного кода в отношении прохождения функциональных тестовых примеров этих тестов без оценки < em>безопасность созданного кода.
Вклад этой статьи:
• Новая платформа для систематической и автоматической оценки безопасности кода, сгенерированного LLM;
• Общедоступный набор данных подсказок Python [1];
• Две новые метрики (secure@k и уязвимость@k) и демонстрация того, как их вычислять статически и динамически.
• Сравнительный анализ пяти LLM (CodeGen-2B-mono, CodeGen-2.5-7B-mono, StarCoder, GPT-3.5 и GPT4) с использованием нашей платформы.
Остальная часть статьи организована следующим образом: В разделе 2 представлены основные понятия, необходимые для понимания этой статьи. В разделе 3 подробно описана наша структура. В разделе 4 описано эмпирическое исследование, которое мы провели для оценки LLM. В разделе 5 представлены результаты наших экспериментов. В разделе 6 объясняются ограничения SALLM. В разделе 7 представлены соответствующие работы. Наконец, раздел 8 завершает этот документ, описывая планы будущей работы.
[1] После принятия набор данных будет опубликован на GitHub и отправлен на этап оценки артефактов.
Оригинал