Интервью Поскольку все — от начинающих разработчиков до шестилетних детей — бросаются в модное кодирование на основе ощущений (vibe coding), не должно удивлять, что и преступники любят автоматизированные инструменты для кодирования.
«Все спрашивают: используется ли vibe coding в вредоносном ПО? И ответ на данный момент, скорее всего, утвердительный», — заявила Кейт Мидда, старший директор по консалтингу в Unit 42 компании Palo Alto Networks, в беседе с The Register.
Лишь около половины организаций, с которыми мы работаем, имеют какие-либо ограничения на использование ИИ
Однако луч для защитников заключается в том, что модели ИИ — даже когда их просят написать вымогательские записки — допускают ошибки, а это значит, что атаки, созданные с помощью vibe coding, могут потерпеть неудачу.
Как и любая новая блестящая технология, кодирование с помощью ИИ порождает множество уязвимостей в области безопасности, включая потенциал для корпоративных команд разработки ускорять свою работу со скоростью, которую не могут поддерживать команды по безопасности.
Существуют также риски, связанные с тем, что агенты и системы ИИ получают доступ и эксфильтрируют данные, к которым им не должно быть позволено прикасаться, плюс атаки с использованием подсказок (prompt) и инъекций в память (memory injection).
И есть еще риск, что преступники или хакерские группы, поддерживаемые государствами, будут использовать большие языковые модели (LLM) для написания вредоносного ПО или оркестровки целых атак — и хотя в обоих случаях по-прежнему требуется участие человека (human in the loop), сценарии наихудшего развития событий приближаются к реальным инцидентам безопасности.
Vibe coding SHIELD
Чтобы помочь компаниям лучше управлять этими рисками, Palo Alto Networks разработала фреймворк для vibe coding под названием «SHIELD», цель которого — внедрить меры контроля безопасности на протяжении всего процесса кодирования. Мидда, возглавляющая бизнес-услуги по обеспечению безопасности ИИ в Unit 42, стала соавтором блога о фреймворке SHIELD, опубликованного в четверг, и заранее поделилась им с The Register.
«Лишь около половины организаций, с которыми мы работаем, имеют какие-либо ограничения на использование ИИ», — сказала она.
SHIELD расшифровывается как:
- S – Separation of Duties (Разделение обязанностей): Это включает ограничение доступа и привилегий путем разрешения агентам работать только в средах разработки и тестирования.
- H – Human in the Loop (Человек в контуре): Обязательный просмотр кода человеком и требование одобрения запроса на слияние (pull request) перед слиянием кода.
- I – Input/Output Validation (Валидация ввода/вывода): Включая использование таких методов, как разделение подсказок (prompt partitioning), кодирование, ролевое разделение для очистки подсказок, а затем требование от ИИ выполнять проверку логики и кода с помощью Статического анализа безопасности приложений (SAST) после разработки.
- E – Enforce Security-Focused Helper Models (Применение вспомогательных моделей, ориентированных на безопасность): Разработка вспомогательных моделей — специализированных агентов, предназначенных для автоматизированной проверки безопасности приложений, созданных с помощью vibe coding — для выполнения SAST-тестирования, сканирования секретов, проверки мер контроля безопасности и других функций валидации.
- L – Least Agency (Минимальная агентность): Предоставление только минимальных разрешений и возможностей, необходимых инструментам vibe coding и агентам ИИ для выполнения их ролей.
- D – Defensive Technical Controls (Оборонительные технические средства контроля): Применение защитных мер в отношении цепочки поставок и управления выполнением компонентов перед использованием этих инструментов, а также отключение автозапуска для обеспечения участия человека в контуре после развертывания.
Мы поговорим об этом подробнее через минуту. Но сначала вернемся к вредоносному ПО, созданному с помощью vibe coding.
Мидда и ее коллеги из Palo Alto не всегда могут точно определить, использовали ли разработчики платформу vibe coding для создания вредоносного ПО. Некоторые фрагменты кода облегчают задачу, включая водяной знак, подтверждающий, что код был сгенерирован Cursor, Replit, Claude или другим инструментом ИИ.
Она также не говорит, какой инструмент наиболее популярен среди преступников, хотя и отметила, что они используют «несколько» продуктов, «и, учитывая общую популярность платформ vibe coding, вы, вероятно, можете экстраполировать на основе популярности каждого из них».
Команда по консалтингу киберрисков Palo Alto также видела «множество различных шаблонов в среде, которые указывают» на использование платформ кодирования для разработки вредоносного ПО, добавила Мидда. И один из таких шаблонов, который наблюдала Мидда — когда разработчики вредоносного ПО напрямую встраивают в код вызовы API к большим языковым моделям — является веским доказательством того, что вредоносные элементы занимаются vibe coding.
«Таким образом, внутри самого вредоносного ПО есть вызовы API к OpenAI или другим платформам с вопросами о том, как сгенерировать вредоносное ПО, как сгенерировать фишинговые электронные письма, чтобы они выглядели правдоподобно», — объяснила она, назвав это «прямым и неопровержимым доказательством того, что они используют эти LLM в процессе разработки своего вредоносного ПО».
«Театр безопасности»
Злоумышленники также используют LLM для того, что Мидда называет «театром безопасности». Это код, который выглядит так, будто он может привести к успешной атаке, но неэффективен по ряду причин, включая отсутствие адаптации под конкретную среду. «Он имеет вид действительной атаки, — сказала она, — но если копнуть чуть глубже, понимаешь: „Эй, подождите-ка, это на самом деле не имеет смысла“».
Это включает в себя «висячие стратегии атак», когда LLM генерирует, например, метод уклонения. «Но этот метод уклонения на самом деле не будет соответствовать тому, что мы обычно видим у современных злоумышленников, или это будет метод уклонения, который никогда не был реализован в среде — он был просто сгенерирован как побочный продукт вызова API к LLM», — пояснила Мидда.
В одном из таких инцидентов Unit 42 задокументировала запрос, отправленный в GPT-3.5 Turbo от OpenAI через стандартный API с просьбой к модели «сгенерировать простой метод уклонения для инструмента извлечения данных и вернуть только название метода, максимум три слова, которое поможет избежать обнаружения», — сказала она. Запрос включал такие примеры: «случайная задержка, спуфинг процессов, обфускация памяти».
Мы наблюдаем случаи галлюцинаций, когда LLM назовет его ‘readme.txtt’. Это ошибка, которую никогда не допустил бы злоумышленник — это как Основы вымогательства (Ransomware 101)
Как и было указано, LLM вернула название метода, но модель лишь подключилась к рабочему столу жертвы — она не реализовала метод уклонения. «Это было сделано для вида и чисто для логирования», — сказала Мидда. «Возможно, существовал бы способ заставить это работать, но это не было должным образом реализовано в среде».
Хотя она не может знать наверняка, почему злоумышленник устроил бы театр безопасности, а не настоящую атаку, «если бы мне пришлось гадать, я думаю, это просто вывод», — сказала Мидда. «LLM сгенерирует огромный объем кода, злоумышленник торопится, он не проверяет все, что есть в выводе кода, и возникают ошибки».
Иными словами, инструменты ИИ допускают те же ошибки при генерации вредоносного кода, что и при написании легитимного.
Галлюцинации остаются распространенной ловушкой ИИ, и даже разработчики программ-вымогателей ощущают эту боль.
После заражения машины жертвы вымогатели оставляют на рабочем столе файл readme, обычно названный “readme.txt”, содержащий вымогательское сообщение и требование о выплате.
«Мы наблюдаем случаи галлюцинаций, когда LLM называет его ‘readme.txtt’», — сказала Мидда. «Это ошибка, которую никогда не допустил бы злоумышленник — это как Основы вымогательства (Ransomware 101). Но сейчас мы видим, что они движутся так быстро и не делают почти ничего в плане проверки или контроля, что такие вещи просто случаются. Они бросают все подряд».
Ошибки при использовании моделей ИИ, лишенных ситуационной осведомленности человека и созданных с приоритетом функциональности над безопасностью, допускают не только злоумышленники.
Большинство организаций, разрешающих своим сотрудникам использовать инструменты vibe coding, также не провели никакой формальной оценки рисков этих инструментов и не имеют мер контроля безопасности для мониторинга вводов и выводов.
«Если вы являетесь предприятием, есть несколько способов контролировать и устранять риски vibe coding», — сказала Мидда. Первый шаг включает применение принципов минимальных привилегий и минимальной функциональности к инструментам ИИ так же, как это делается к пользователям-людям, предоставляя только минимальные роли, обязанности и привилегии, необходимые для выполнения их работы.
«Все так взволнованы использованием ИИ и желанием ускорить работу своих разработчиков, что вся эта модель минимальных привилегий и минимальной функциональности была полностью отброшена», — сказала Мидда.
Далее она предлагает ограничить использование одним разговорным LLM, который сотрудники могут использовать, и заблокировать все остальные инструменты кодирования ИИ на файрволе. А для организаций, которые все же решат, что им нужен инструмент vibe coding в их среде, «путь вперед — это фреймворк SHIELD», по словам Мидды. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Qual-score: 8/7
Bayan-score: 0.70080322
Автор – Jessica Lyons
