ИИ
Генерация программного кода стала одной из сфер, где ИИ уже внедрен достаточно широко, — по некоторым оценкам, за минувший год около 40% нового кода было написано ИИ. CTO Microsoft считает, что через пять лет эта цифра достигнет 95%. Этот код еще предстоит научиться правильно сопровождать и защищать.
Безопасность ИИ-кода эксперты пока оценивают как невысокую, в нем систематически встречаются все классические программные дефекты: уязвимости (SQL-инъекции, вшитые в код токены и секреты, небезопасная десериализация, XSS), логические дефекты, использование устаревших API, небезопасные алгоритмы шифрования и хеширования, отсутствие обработки ошибок и некорректного пользовательского ввода и многое другое. Но использование ИИ-ассистента в разработке ПО добавляет еще одну неожиданную проблему — галлюцинации. В новом исследовании авторы подробно изучили, как на ИИ-код влияют галлюцинации больших языковых моделей. Оказалось, что некоторых сторонних библиотек, которые ИИ пытается использовать в своем коде, просто не существует в природе.
Вымышленные зависимости в open source и коммерческих LLM
Для изучения фантомных библиотек исследователи сгенерировали 576 тысяч фрагментов кода на Python и JavaScript с помощью 16 популярных LLM.
Модели выдумывали зависимости с разной частотой: реже всего галлюцинировали GPT4 и GPT4 Turbo (вымышленные библиотеки встретились менее чем в 5% образцов кода), у моделей DeepSeek этот показатель уже превышает 15%, а сильнее всего ошибается Code Llama 7B (более 25% фрагментов кода ссылаются на несуществующие библиотеки). При этом параметры генерации, которые снижают вероятность проникновения случайных токенов в выдачу модели (температура, top-p, top-k), все равно не могут снизить частоту галлюцинаций до незначительных величин.
Код на Python содержал меньше вымышленных зависимостей (16%) по сравнению с кодом на JavaScript (21%). Результат также зависит от того, насколько стара тема разработки. Если при генерации пытаться использовать пакеты, технологии и алгоритмы, ставшие популярными за последний год, несуществующих пакетов становится на 10% больше.
Самая опасная особенность вымышленных пакетов — их имена не случайны, а нейросети ссылаются на одни и те же библиотеки снова и снова. На втором этапе эксперимента авторы отобрали 500 запросов, которые ранее спровоцировали галлюцинации, и повторили каждый из них 10 раз. Оказалось, что 43% вымышленных пакетов снова возникают при каждой генерации кода.
Интересна и природа имен вымышленных пакетов. 13% были типичными «опечатками», отличающимися от настоящего имени пакета всего на один символ, 9% имен пакетов были заимствованы из другого языка разработки (код на Python, пакеты из npm), еще 38% были логично названы, но отличались от настоящих пакетов более значительно.
Знакомьтесь, slopsquatting
Все вышесказанное позволяет спрогнозировать новое поколение атак на репозитории open source, уже получившее жаргонное название slopsquatting по аналогии с typosquatting. В данном случае захвату (squatting) будут подвергаться не имена с опечатками (typo), а имена из «ИИ-мусора» (AI slop). Благодаря повторяемости имен пакетов в сгенерированном ИИ коде, злоумышленники могут самостоятельно запустить популярные модели, найти в сгенерированном коде повторяющиеся имена вымышленных пакетов и зарегистрировать такие библиотеки на самом деле, внедрив в пакеты нужную им вредоносную функциональность. Если человек, пользующийся ИИ-ассистентом, бездумно устанавливает все пакеты, встречающиеся в сгенерированном коде, или ИИ-ассистент может установить пакеты самостоятельно, вредоносная зависимость попадает в собранное приложение и получившийся код может быть успешно запущен, то есть станет возможной полноценная атака на цепочку поставок (ATT&CK T1195.001). Этот риск значительно возрастет с популяризацией vibe coding — процесса, в котором приложение пишут, оперируя исключительно инструкциями в чате с ИИ, практически не заглядывая в сам программный код.
Учитывая, что во всех популярных репозиториях open source за последний год зарегистрированы десятки случаев публикаций вредоносных пакетов (1, 2), а всего за год обнаружено почти 20 тысяч вредоносных библиотек, можно быть уверенным, что кто-нибудь попытается поставить этот вид атак на конвейер.
Этот сценарий особенно опасен для программистов-любителей, а также для корпоративных IT-отделов, решающих на работе какие-то внутренние задачи по автоматизации.
Как защититься от slopsquatting и рисков использования AI в разработке
Хотя руководств по безопасному внедрению ИИ в разработку существует уже много (например, у OWASP, NIST и у «Лаборатории Касперского»), они описывают очень широкий круг мер, и практическое внедрение многих из них является длительным и сложным процессом. Поэтому мы собрали небольшое подмножество мер, которые напрямую относятся к проблеме «фантомных пакетов» и проще в практическом воплощении. Вот эти меры:
- Сканирование исходного кода и статическое тестирование безопасности должны быть частью конвейера разработки. Любой код, в том числе сгенерированный ИИ, обязан удовлетворять целому ряду четких критериев, включая отсутствие токенов и других секретов в коде, использование корректных версий библиотек и других зависимостей и так далее. Эти задачи хорошо интегрируются в цикл CI/CD, например, в рамках защитного решения Kaspersky Container Security.
- Дополнительные циклы ИИ-проверки, когда языковая модель проверяет собственный код на ошибки, снижают число галлюцинаций. Более того, модель можно попросить проанализировать популярность и полезность каждого из пакетов, упомянутых в проекте. Применение донастройки модели и RAG (Retrieval-Augmented Generation) с помощью заранее построенной базы популярных библиотек также снижает количество ошибок. В вышеупомянутом исследовании удалось, комбинируя все эти методы, снизить число фантомных пакетов до 2,4% для DeepSeek и 9,3% для Code Llama. К сожалению, обе цифры довольно далеки от нуля, поэтому ограничиться этими мерами не получится.
- Запрет на применение ИИ-ассистентов при написании критических и доверенных компонентов. Для тех некритических задач, в которых разрешено написание кода с помощью ИИ, нужно построить процесс проверки кода компетентным разработчиком. Для проверки нужно создать чек-лист, учитывающий специфику ИИ-кода.
- Закрытый список доверенных зависимостей. ИИ-ассистентов и их живых пользователей нужно ограничить в возможностях добавлять библиотеки и зависимости в код — в идеале, должны быть доступны лишь библиотеки из внутреннего репозитория организации, заранее проверенного и одобренного.
- Обучение разработчиков. Они должны изучить тему безопасности ИИ в целом, а также в контексте применения ИИ в разработке кода.
Советы