Привет, на связи Константин Артемьев, генеральный директор Шерпа Роботикс[ссылка удалена мод.]. Сегодня я подготовил для Хабра перевод довольно интересной статьи о новых рисках при использовании ИИ для создания кода. Если используешь нейросети для программирования - переходи под кат, предупрежден, значит - вооружен.
Разработчики программного обеспечения всё чаще используют ИИ для создания кода, и эта тенденция неудивительна, учитывая растущие требования к ним в плане создания продуктов и их более быстрого выпуска на рынок.
Исследование, проведённое в прошлом году GitHub, показало, что 97% опрошенных программистов в какой-то момент использовали инструменты для написания кода на основе ИИ. Аналогичный опрос, проведённый Stack Overflow в 2024 году, показал, что 76% из 65 437 разработчиков либо используют, либо планируют использовать такие инструменты. Список причин растёт: от повышения производительности и улучшения качества кода до более быстрой отладки и большей согласованности между командами.
Однако, из-за обоюдоострой природы ИИ, существуют риски, включая надежность кода, уязвимости в системе безопасности и техническую задолженность которые могут замедлить процесс и привести к увеличению затрат, согласно Legit Security, компании, занимающейся управлением состоянием безопасности приложений (ASPM).
Другой риск заключается в том, что большие языковые модели (БЯМ), как известно, с тех пор, как OpenAI впервые выпустила ChatGPT в 2022 году, создают «галлюцинации» — ошибочные или вводящие в заблуждение результаты. Для большинства людей это означает, что ответ на запрос может содержать неверные финансовые данные, включать неверную информацию в эссе или — в одном известном случае — составлять судебные цитаты, которые юрист использовал в судебном иске.
Для разработчиков это может означать создание ссылок на программные библиотеки, модули или другие пакеты кода, которых на самом деле не существует. Это не новое
явление. Фирмы, занимающиеся безопасностью, и аналитики уже давно знают о нём.
Тем не менее, эта тема снова поднимается в связи с атакой на цепочку поставок, которая может быть запущена в репозиториях кода с помощью этих галлюцинаций, получивших красочное название «slopsquatting», и недавним исследованием учёных из трёх университетов, в котором описывается, как это можно сделать.
Название — это отсылка к хорошо известной киберугрозе «типосквоттинг», когда злоумышленники регистрируют вредоносные домены с названиями, очень похожими на названия законных сайтов, в надежде, что разработчик допустит опечатку и случайно попадёт на поддельный сайт.
В случае слэсквоттинга злоумышленник может создать вредоносный пакет, использующий название несуществующей библиотеки, созданной LLM, и разместить его для скачивания в популярном репозитории кода, таком как GitHub, Python Package Index (PyPI) или npm, в надежде, что программист воспользуется им в своей работе.
Аналитики IDC писали о таких угрозах в прошлом году, отмечая, что «галлюцинации пакетов создают новые возможности для злоумышленников внедрять вредоносный код в цепочки поставок программного обеспечения и охотиться на разработчиков, которые используют генеративный ИИ для написания кода».
Исследователи из Техасского университета в Сан-Антонио, Университета Оклахомы и Технологического института Вирджинии углубились в тему, утверждая, что большинство исследований галлюцинаций ИИ были сосредоточены на задачах, связанных с генерацией естественного языка и прогнозированием, таких как обобщение и машинный перевод. Исследования их применения в генерации кода «всё ещё находятся на начальной стадии», — написали они.
Для своей работы по выявлению галлюцинаций в коде Python и JavaScript исследователи протестировали 16 популярных моделей генерации кода, таких как ChatGPT-4, DeepSeek, CodeLlama, Claude, Mistral и OpenChat, и использовали два набора данных с подсказками, чтобы оценить масштаб проблемы. LLM сгенерировали 576 000 примеров кода Python и JavaScript, из которых 19,7% рекомендованных пакетов не существовали.
Итак, будут ли модели воспроизводить галлюцинации в том же пакете? Используя набор из 500 подсказок, которые создавали галлюцинации в пакете, они повторили запросы 10 раз для каждой подсказки и обнаружили, что 43% галлюцинаций в пакете повторялись во всех 10 запросах, а в 58% случаев пакет повторялся более одного раза в 10 итерациях.
Результаты теста показывают, что «большинство галлюцинаций — это не просто случайные ошибки, а повторяющееся явление, которое сохраняется при многократных итерациях», — пишут исследователи. «Это важно, потому что устойчивая галлюцинация более ценна для злоумышленников, которые хотят воспользоваться этой уязвимостью, и делает вектор атаки с использованием галлюцинаций более жизнеспособным».
Ещё одним интересным выводом исследования стало то, что большинство моделей могли распознавать собственные галлюцинации более чем в 75% случаев. Исследователи пишут, что это указывает на то, что «эти модели обладают неявным пониманием собственных генеративных паттернов, которые можно использовать для самосовершенствования. Это важное открытие для разработки стратегий смягчения последствий».
Исследование и огласка, которую получила угроза «слизывания кода», — это важное напоминание разработчикам о том, что нужно быть осторожными при использовании ИИ для генерации кода. Sonatype — один из растущего числа поставщиков на рынке анализа состава программного обеспечения (SCA), который, как ожидается, вырастет с 328,84 млн долларов в прошлом году до почти 1,7 млрд долларов к 2033 году. Инструменты SCA автоматизируют процесс идентификации компонентов с открытым исходным кодом и управления ими.
Митчелл Джонсон, директор по разработке продуктов в Sonatype, рассказал The New Stack, что использование ИИ в разработке программного обеспечения напоминает времена, когда открытый исходный код был в новинку — «своего рода запрещённая технология», от которой разработчиков предостерегали. Сейчас большинство программ включает элементы с открытым исходным кодом.
«Искусственный интеллект — это что-то вроде открытого исходного кода, скажем, 20 или 25 лет назад, когда организации только начинали им пользоваться, — сказал Джонсон. — Но на самом деле разработчики всегда на шаг впереди, потому что мы, как разработчики, стремимся быть более продуктивными, работать быстрее, выпускать продукты быстрее и с более высоким качеством. Быстрее, лучше, дешевле — вот что нас мотивирует. К сожалению, злоумышленники понимают это, и они очень умны».
Проблема в том, что ИИ частично снимает нагрузку с программистов, которым нужно работать быстро, и часто безопасность отходит на второй план. Когда вы спрашиваете вице-президентов по проектированию и менеджеров по разработке о целях на год, «вы нечасто слышите слово «безопасность», — сказал он. — Вы слышите: «Сдайте это вовремя, сдайте это в рамках бюджета, внедрите эту инновацию, сократите эти расходы», но вы не слышите слово «безопасность». Это не значит, что разработчики не думают об этом. Мы видим это всё чаще и чаще, но в целом — нет. Инновации и скорость происходят слишком быстро».
Кейси Эллис, основатель Bugcrowd, рассказал The New Stack, что разработчики стремятся «сделать так, чтобы всё работало, а не так, чтобы всё не работало так, как не должно. Когда существует такое несоответствие, возникают подобные проблемы, и [когда] вы добавляете ускоряющую функцию, такую как код, сгенерированный искусственным интеллектом, атаки, подобные slopsquatting, являются естественным побочным эффектом».
Даже с учётом помощи, которую оказывает ИИ, разработчики по-прежнему обязаны проверять свой код, чтобы убедиться, что в нём нет ничего вредоносного. Джонсон сравнил это с клятвой Гиппократа для инженеров: не навреди коду.
«Вы должны нести ответственность за каждую строку кода, которая проверяется, — за его качество, безопасность, функциональность, производительность, — сказал он. — И вы не можете сказать: «Ну, ИИ подсказал мне». Инженерам проще, чем когда-либо, создавать код с помощью этих больших языковых моделей и инструментов, но мы обязаны следить за тем, чтобы не проверять небезопасный или неработающий код. Именно этим и пытается воспользоваться этот взломщик».
Разработчики не могут слепо доверять тому, что генерирует ИИ, заявили несколько специалистов по безопасности.
«Большинство разработчиков знают, что ИИ может допускать ошибки, но многие по-прежнему слишком доверяют результатам и не всегда проверяют наличие скрытых проблем», — Дж. Стивен Коски, технический директор SlashNext Email Security+, рассказал The New Stack. «Легко увлечься скоростью и удобством, но это может привести к тому, что вы пропустите уязвимости в системе безопасности или будете использовать поддельные пакеты. Лучшая защита — использовать автоматизированные инструменты, которые проверяют зависимости и код на наличие проблем, и всегда проверять предложения ИИ перед их использованием».
По мере того, как разработчики будут расширять использование ИИ, будет важно применять такие средства защиты. Джонсон из Sonatype сказал, что, по его ожиданиям, генеративный ИИ вскоре начнёт разделять организации и программистов, которые могут контролировать и управлять этой технологией, и тех, кто не может.
«По-настоящему хорошие разработчики, которые могут бросить вызов машине, которые понимают, что она выдаёт, правильно это или нет, видят геометрический рост производительности, — сказал он. — Вы увидите, что некоторые предприятия, у которых уже были хорошие методы обеспечения безопасности и разработки, где они работали сообща, станут ещё лучше. А те, кто был небрежен, ещё больше отстанут и столкнутся с серьёзными проблемами, нарушениями. Это позволит отделить и выделить тех, у кого есть, от тех, у кого нет, как на организационном, так и на индивидуальном уровне».