ИИ программист

Несмотря на то, что вопрос о повышении производительности труда с помощью ИИ-ассистентов всё ещё остается дискуссионным, наиболее активно они используются в сфере разработки программного обеспечения. В этой области большие языковые модели выполняют широкий спектр задач, начиная от оптимизации кода и написания документации и заканчивая полноценной разработкой приложений. Помимо традиционных рисков информационной безопасности, здесь возникают специфические уязвимости, присущие самим ИИ-моделям. На стыке этих двух направлений новые ошибки и вызовы появляются практически еженедельно
Когда языковая модель создает код, в нем могут содержаться ошибки и программные уязвимости. Ведь для обучения LLM брали данные из Интернета, в том числе тысячи примеров не очень качественного кода. Недавнее исследование Veracode показало, что ведущие ИИ-модели стали генерировать значительно более корректный код — в 90% случаев он компилируется без ошибок. Два года назад успешно компилировалось менее 20% кода. А вот безопасность кода не улучшилась — 45% созданного моделью кода содержало классические программные уязвимости из OWASP Top 10, и за два года мало что изменилось. Исследование проводилось на сотне популярных разновидностей LLM и фрагментах кода, написанных на Java, Python, C# и JavaScript. Это означает, что вне зависимости от того, в каком режиме и каком сервисе применяется LLM готовому приложению требуется очень тщательная проверка на уязвимости. В реальности ее часто не проводят.
В качестве примеров подобных ошибок часто приводят кейс скандально известного из-за двух крупных утечек данных приложения Tea, предназначенного исключительно для женщин. Но в реальности это приложение было создано гораздо раньше, чем появился вайб-кодинг. Виноват ли в проблемах Tea ИИ, мы окончательно узнаем в суде. Но ИИ-программирование точно стало причиной бед стартапа Enrichlead. Его основатель хвастался в соцсетях, что весь программный код его платформы написан с помощью Cursor AI: «ноль кода написано вручную». Но через несколько дней после запуска проекта выяснилось, что он полон тривиальных ИБ-уязвимостей и любой желающий может пользоваться платными функциями или модифицировать данные. В результате проект пришлось закрыть, потому что доработать код до нужного уровня при помощи Cursor у автора не получилось. Впрочем, он не унывает и пробует запустить новые проекты, основанные на вайб-кодинге.
Основные виды уязвимостей в ИИ-коде
Хотя феномену программирования с ИИ всего год-два, уже накопилась статистика по типовым ошибкам в сгенерированном коде. Как правило это:
• отсутствие проверок ввода, очистки ввода от посторонних символов и другие детские ошибки, ведущие к классическим уязвимостям вроде cross-site scripting (XSS) и SQL injection;
• API-ключи и другие секреты, зашитые прямо в веб-страницу и видимые пользователю в ее коде;
• логика аутентификации, целиком реализованная на стороне клиента, прямо в коде сайта, работающая в браузере. Ее несложно подделать для обхода любых проверок;
• ошибки журналирования — от недостаточной фильтрации при записи в журнал до полного отсутствия журналов;
• избыточно мощные и опасные функции — ИИ-модель оптимизирована на выдачу кода, решающего задачу кратчайшим путем. Но кратчайший путь часто небезопасен. Азбучный пример — применение в коде функции eval для математических вычислений над данными, введенными пользователем. Это открывает дорогу к выполнению произвольного кода в созданном приложении;
• устаревшие или несуществующие зависимости. ИИ-код часто ссылается на старые версии библиотек, делает устаревшие и небезопасные API-вызовы или даже требует подключить библиотеку, не существующую в природе. Последнее особенно опасно, потому что атакующие могут создать вредоносную библиотеку с правдоподобным именем, и ИИ-агент включит ее в реальный проект.
Опасные промпты
Известная среди разработчиков присказка «сделано строго по техническому заданию» уместна и при работе с ИИ-ассистентом. Если запрос для создания функции или приложения недостаточно четкий и не упоминает аспекты безопасности, вероятность генерации уязвимого кода значительно возрастает. Но наибольшую эффективность дают более конкретные рекомендации, адаптированные для используемого языка программирования и призывающие не делать программных ошибок из списков MITRE или OWASP. Большой набор подобных инструкций собран в GitHub Wiz, их рекомендуется добавить в системный промпт ИИ-ассистента.
Ухудшение безопасности при доработках
При многократных доработках кода по дополнительным запросам безопасность этого кода снижается. К такому выводу пришли в свежем исследовании, где GPT-4o до 40 раз просили доработать написанный ей же код, сканируя результат на уязвимости после каждого раунда. Уже после пяти раундов доработок в коде было на 37% больше критических уязвимостей, чем в начале. В исследовании независимо тестировались 4 стратегии написания промптов: в одном подчеркивались требования эффективности, в другом — безопасности, в третьем — требования новых возможностей, четвертый был нечетким. В случае когда промпты фокусировались на новых функциях, в код добавилось 158 уязвимостей, включая 29 критических. Когда промпт подчеркивал необходимость написать безопасный код, дефектов было гораздо меньше, но все равно много — 38 новых уязвимостей, включая 7 критических.
Как пользоваться ИИ-кодом безопасно
Существенно снизить (но далеко не обнулить) уровень риска при использовании ИИ-кода можно, применяя комплекс организационных и технических мер:
• внедрять автоматическую проверку сгенерированного ИИ-кода прямо по мере его написания при помощи оптимизированных инструментов SAST;
• внедрять требования безопасности в системные промпты используемых ИИ-сред;
• проводить детальный разбор кода опытным живым специалистом. Вооружить его специализированными ИИ-инструментами анализа безопасности, чтобы повысить эффективность анализа;
• тренировать разработчиков писать безопасные промпты и в целом обучать безопасному применению ИИ .
По материалам Касперский