В январе 2026 года проект curl прекратил выплачивать вознаграждения за сообщения об уязвимостях. За семь лет программа помогла подтвердить 87 проблем безопасности и выплатила исследователям более $100 тысяч. Но затем доля полезных сообщений резко упала: если раньше уязвимостью оказывались более 15% заявок, то в 2025 году — менее 5%. Среди причин руководитель проекта Дэниел Стенберг назвал поток убедительно написанных, но ошибочных отчётов, созданных с помощью ИИ.

Это показательный конфликт новой эпохи разработки. Генеративные модели удешевили создание кода, патчей и технических отчётов. Проверка результата при этом не стала дешевле: её по-прежнему выполняют люди, которые отвечают за продукт и знают его архитектуру.

Так проявляется главный риск вайб-кодинга. Проблема не в том, что разработчик пользуется ИИ, а в том, что он принимает результат, которого не понимает и не проверяет.

Что такое вайб-кодинг — и что им не является

Термин vibe coding популяризировал Андрей Карпаты в феврале 2025 года. Он описал предельно расслабленный способ работы: формулировать желаемый результат обычными словами, принимать все предложенные изменения, не читать diff, а ошибки возвращать модели до тех пор, пока приложение не заработает. Сам Карпаты оговаривал, что такой подход подходит прежде всего для одноразовых проектов на выходные.

Поэтому важно различать два режима:

  • Разработка с помощью ИИ — инженер использует модель для поиска вариантов, написания заготовок, тестов или документации, но читает изменения и отвечает за решение.
  • Вайб-кодинг в строгом смысле — человек оценивает только видимый результат и сознательно перестаёт следить за устройством кода.

Первый режим уже стал обычным инженерным инструментом. Второй меняет распределение риска: скорость получает автор, а стоимость проверки, сопровождения и устранения ошибок часто переходит к коллегам, пользователям и мейнтейнерам зависимостей.

Галлюцинации пакетов: реальный риск без страшилок

Один из наиболее понятных сценариев атаки связан с несуществующими зависимостями. Модель может предложить правдоподобное имя библиотеки, которой нет в npm или PyPI. Если злоумышленник зарегистрирует такое имя и опубликует под ним вредоносный пакет, невнимательный разработчик или автономный агент может установить его как обычную зависимость. Этот сценарий называют package hallucination attack, а также slopsquatting.

Исследователи из университетов США проверили 16 моделей на 576 тысячах примеров кода для Python и JavaScript. В их эксперименте доля вымышленных пакетов составляла не менее 5,2% у коммерческих моделей и 21,7% у моделей с открытыми весами. Всего авторы обнаружили 205 474 уникальных вымышленных названия.

Эти цифры нельзя превращать в утверждение, будто каждая пятая подсказка современного ассистента опасна. Результат зависит от модели, языка, набора промптов и методики подсчёта. Исследование доказывает более узкий тезис: галлюцинации зависимостей воспроизводимы в масштабе и создают поверхность для атаки на цепочку поставок.

Сценарий выглядит так:

TEXT

запрос разработчика ↓ ИИ предлагает несуществующий пакет ↓ имя регистрирует злоумышленник ↓ разработчик или агент выполняет установку ↓ вредоносный код получает доступ в пределах прав процесса

Важно и другое: lock-файл защищает от незаметной подмены уже зафиксированной версии, но не делает безопасным первоначальное добавление неизвестного пакета. До установки нужно проверить официальный реестр, владельца, репозиторий, историю релизов и то, действительно ли зависимость вообще необходима.

Как ИИ увеличил нагрузку на мейнтейнеров curl

История curl показывает обратную сторону массовой генерации: ИИ способен не только добавить сомнительный код, но и создать шум вокруг настоящего проекта.

В июле 2025 года Стенберг писал, что около 20% сообщений о безопасности, поступивших с начала года, относились к очевидному «AI slop», а настоящими уязвимостями оказались примерно 5% заявок. Каждый отчёт приходилось изучать нескольким участникам команды: проверять путь исполнения, пытаться воспроизвести проблему и объяснять, почему заявленный сценарий не работает.

31 января 2026 года денежная bug bounty-программа curl завершилась. Проект не отказался принимать сообщения об уязвимостях: для них оставили приватные отчёты GitHub и электронную почту. Команда убрала именно вознаграждение и перестала рекомендовать HackerOne, рассчитывая снизить стимул к массовой отправке непроверенных находок.

Причиной был не только ИИ. В итоговом объяснении Стенберг назвал три тенденции: поток сгенерированного мусора, общее падение качества человеческих отчётов и стремление некоторых авторов любой ценой представить находку как критическую, не помогая исправить код. Такая формулировка важнее удобного лозунга «ИИ уничтожил bug bounty»: она точнее описывает проблему стимулов и ответственности.

Хороший отчёт об уязвимости должен содержать проверяемую версию продукта, минимальный сценарий воспроизведения, ожидаемое и фактическое поведение, оценку границ воздействия. Красивый текст и высокий балл CVSS не заменяют работающего доказательства.

Что на самом деле показало исследование Стэнфорда

Работу Do Users Write More Insecure Code with AI Assistants? часто пересказывают слишком широко. В эксперименте участвовали 47 человек: 33 получили доступ к ассистенту на базе codex-davinci-002, 14 вошли в контрольную группу. Участникам предложили шесть задач на Python, JavaScript и C; в итоговый анализ вошли пять задач, связанных с шифрованием, цифровой подписью, безопасной работой с путями, SQL-запросами и обработкой строк. Шестую исключили из-за неоднозначной постановки.

В четырёх из пяти задач группа с ИИ чаще предлагала небезопасные решения. Её участники при этом были более уверены в безопасности своего кода. Исследователи также заметили, что лучшие результаты показывали люди, которые меньше доверяли первому ответу, давали больше контекста и переформулировали запросы.

Но это исследование 2022 года, опубликованное на ACM CCS 2023. Оно изучало одну модель, небольшую выборку и короткие учебные задачи, а не современные агентные среды и не промышленную разработку в целом. Из него нельзя честно вывести, что любой код с ИИ менее безопасен. Зато оно показывает, что уверенность человека в безопасности кода может расходиться с результатами независимой проверки.

Практический вывод не сводится к совету «лучше писать вручную». Ручной код тоже содержит уязвимости. Правильный вопрос звучит иначе: какие независимые проверки проходит изменение до того, как ему доверят данные и права пользователя?

Почему ссылка на Linux не заменяет доказательства

В дискуссиях о вайб-кодинге часто пересказывают резкие высказывания Линуса Торвальдса, не приводя записи выступления или ссылки на переписку. Приписывать ему эффектную цитату без первоисточника нельзя.

Официальные правила ядра Linux дают более надёжную опору. Строка Signed-off-by подтверждает условия Developer’s Certificate of Origin: участник создал вклад или имеет право передать его под открытой лицензией и понимает, что вклад и сведения о нём будут храниться публично. Это сертификат происхождения и лицензирования, а не обещание «понимать каждую ассемблерную инструкцию».

Однако инженерная ответственность никуда не исчезает. Документация по отправке патчей требует объяснить, что меняется и почему, разделять работу на логические патчи и следить, чтобы ядро собиралось и работало на каждом этапе серии. Происхождение кода — от человека, генератора или ИИ-ассистента — не отменяет этих требований.

Секреты и полномочия: где цена ошибки особенно высока

ИИ-агент видит ровно то окружение, которое ему предоставили. Если процесс имеет доступ к .env, SSH-ключам, облачным токенам и производственной базе, ошибочная команда получает тот же радиус поражения.

Проблема утечек секретов существовала задолго до вайб-кодинга, а увеличение объёма создаваемого кода может расширять поверхность риска. По данным GitGuardian, в публичных коммитах GitHub за 2025 год обнаружили 28,6 млн новых секретов. Отдельно компания сообщает, что коммиты с соавторством Claude Code содержали секреты примерно вдвое чаще базового уровня. Это наблюдаемая корреляция, а не доказательство, что утечки вызвал именно инструмент: на результат могут влиять тип пользователей, проектов и способ определения AI-assisted коммитов.

Поэтому безопасность агента начинается не с промпта «будь осторожен», а с технического ограничения прав:

  • отдельная рабочая копия или контейнер;
  • отсутствие производственных секретов по умолчанию;
  • минимальные сетевые и файловые разрешения;
  • подтверждение опасных команд человеком;
  • короткоживущие учётные данные с узкими правами;
  • журнал изменений, который можно проверить и откатить.

Практический контур проверки AI-кода

Универсального «детектора плохого AI-кода» нет. Надёжнее встроить результат модели в обычный инженерный процесс.

До изменения

  1. Сформулировать критерии готовности, ограничения безопасности и границы доступа агента.
  2. Не передавать модели секреты и данные, которые запрещено отправлять выбранному провайдеру.
  3. Работать в отдельной ветке или изолированной среде, где ошибка обратима.

Во время работы

  1. Просматривать diff небольшими порциями, а не принимать сотни строк одним блоком.
  2. Требовать объяснения архитектурного решения, но проверять его по документации и коду: объяснение модели тоже может быть ошибочным.
  3. Проверять каждую новую зависимость до установки. Предпочитать стандартную библиотеку или уже одобренные компоненты.
  4. Не разрешать агенту самостоятельно отключать проверки, менять права доступа и работать с production.

Перед объединением

  1. Запустить типизацию, линтер, тесты и сборку в чистом окружении.
  2. Проверить авторизацию, обработку входных данных, ошибки и крайние случаи отдельно от «счастливого пути».
  3. Использовать сканирование секретов, статический анализ и анализ зависимостей как дополнительные барьеры, а не как замену ревью.
  4. Попросить другого инженера оценить решение. Автор промпта так же склонен защищать полученный результат, как автор ручного кода.
  5. Убедиться, что команда сможет сопровождать изменение без участия исходного чата и конкретной модели.

Вывод

Вайб-кодинг полезен там, где ошибка дёшева, результат легко проверить, а работу можно выбросить и начать заново: в прототипах, одноразовых инструментах и исследовании интерфейсов. Чем ближе код к платежам, персональным данным, инфраструктуре или популярному open-source-пакету, тем меньше допустима работа «по ощущению».

ИИ резко снизил цену первой версии. Но он не отменил цену доказательства: тестов, ревью, воспроизводимости, контроля зависимостей и ограничений доступа. В зрелой команде модель ускоряет инженера. Без этих барьеров она ускоряет выпуск ошибок — и перекладывает стоимость их проверки на других.

Первоисточники