Главная боль вайб-кодинга — безопасность. Как мы ее решаем

Добрый день, с вами Дмитрий Шеверев. Мы с командой делаем свои проекты, преимущественно SaaS и on-prem-решения, а также пишем код на заказ.

Сегодня хочу обсудить с вами тему, которая называется "Вайб-кодинг". Термин модный, противоречивый, интересный. Но речь пойдёт не про сам термин, а про то, что за ним реально стоит, и про проблемы, с которыми многим разработчикам уже приходится сталкиваться почти каждый день.

На мой взгляд термин "Вайб-кодинг" это первую очередь про то, что код сейчас появляется слишком быстро. Намного быстрее, чем его получается проверять.

Давайте посмотрим, как это может выглядеть в реальной жизни

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

Допустим, у него есть задача — что-то доделать. Например, авторизацию, интеграцию или небольшой рефакторинг функций, которые были недавно написаны.

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

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

После этого запускает и смотрит: если есть ошибки и просит того же агента их починить. Потом вспоминает, что нужно было еще сделать тесты, просит их написать ИИ агента и следит, чтобы они "позеленели". Немного утрирую, но но так и есть плюс-минус.

В результате этой работы мы получаем "Пул реквест" (то есть код, который предлагается добавить в проект), допустим, на условные 100 строк. Смотрим на тесты — они зелёные. Смотрим интерфейс — он прекрасно работает и всё открывается.

Далее к этой истории подключается ревьюер Саша, он смотрит дифы нашего Василия (т.е. изменения, которые он внес в проект) Он проглядывает всё по диагонали, делает умное лицо и думает про себя: «Ну вроде всё норм». И нажимает "Принять правки". Так код попадает в проект.

И это всё не лень. Я скорее не назвал бы это ленью.

Просто мы имеем ситуацию, когда объём кода слишком быстро растёт. А времени на его чтение не всегда хватает. Но хотя, ладно, в некоторых случаях это все-таки действительно лень или прокрастинация.

Если ту гипотетическую ситуацию, которую я описал, разделить на части, раньше она выглядела бы так:

написал → понял → проверил → смержил.

А сейчас?

Сейчас типичная ситуация такая:

сгенерировал → немного поправил → смержил.

И вот этот шаг, который называется «понял», начинает куда-то пропадать. Ладно, может быть, не полностью, а частично, но пропадать.

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

Так, возвращаемся к ревьюеру Саше, который вроде всё посмотрел, вроде бы всё хорошо. Глубоко разбираться становится сложно. Потому что со стороны всё выглядит слишком уж уверенно и гладко а объема кода всё больше и больше. Бывает вообще, что проще даже руками заново написать, чем разобраться, что написал агент. Но все работает же? Потом проведем ревью безопасности, отдельно, а сейчас сроки.

Кто-то мне сказал, что ИИ может писать иногда очень странные вещи. Да, искусственный интеллект действительно иногда может написать странные вещи. Но люди тоже иногда пишут странные вещи. Проблема не в этом.

Дело в том, что искусственный интеллект пишет слишком быстро, пишет много, и выглядит всё это достаточно убедительно. Поэтому у ревьюера, разработчика может возникнуть ощущение, что код нормальный.

И вот здесь как раз могут скрываться ошибки. Когда мы привыкаем к тому, что код за нас пишет искусственный интеллект, проверка может становиться достаточно поверхностной. Он сваливает на нас очень много кода, который нужно проверить и одновременно балует нас своей убедительностью и "продуктивностью".

Так как я пишу эту статью для VC, а не для того же Хабра, я не буду уходить, в технические дебри. Но поверхностно пробежимся. Какие проблемы безопасности может добавить ИИ в наш проект. И конечно, это не весь айсберг.

Представьте, что в коде появился тестовый ключ, временный токен или кусочек конфигурации. Иногда это можно заметить почти сразу. А иногда он тихонько уезжает в файл, который потом никто даже не откроет. Кроме того человека, конечно, у кого этого ключа быть не должно.

Искусственный интеллект может предложить подключить какую-то внешнюю библиотеку. Разработчик может просто не обратить на это внимания и даже не проверить, что именно добавилось.

А это важно. Хотелось бы понимать, что это за библиотека, насколько она свежая, что она ещё тянет за собой и нет ли там проблем с безопасностью. Так в проект запросто может попасть много лишнего.

Вероятно, одни из самых проблемных мест — это проверки прав. Когда мы что-то упрощаем либо оставляем что-то временное, к чему можем вернуться потом. По крайней мере, мы так думаем, что вернёмся к этому потом.

А пока всё это запускается, и, о чудо, прекрасно работает. Но только не факт, что безопасно.

CORS может быть открыт шире, чем нужно. Дебаг-режим могли забыть выключить, либо выдали уж слишком много прав, так сказать, с запасом.

И такие вещи могут не броситься в глаза во время ревью.

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

Однако, сейчас, ИИ усиливает не только то, как быстро появляются потенциальные проблемы с безопасностью на продовых серверах.

Мы забываем, что ИИ усиливает и ускоряет и злоумышленников тоже. Сейчас атаки стали намного быстрее, массовее и дешевле. Дело в том, что сейчас риск отдельно взятой уязвимости стал в разы дороже и сильнее, чем он был, скажем, три года назад. Если раньше, ломать ваш портал было дорого, долго и вообще непонятно зачем. То сейчас ИИ все ускорил и упростил настолько, что ответ на вопрос "зачем" может прийти во время самого процесса взлома.

Появился парадокс: ИИ ослабляет защищающихся и усиливает нападающих.

У кого-то есть проверки, есть сканеры, и вроде всё ок. И действительно, у многих команд что-то такое присутствует. Но большинство таких инструментов отвечает на вопрос: что, собственно, в нашем проекте потенциально не так?

А часто нужен ответ на немного другой вопрос. Звучит он следующим образом: "Можно ли нам принять вот это конкретное текущее изменение?" И особенно важно это тогда, когда изменения приходят всё быстрее и быстрее.

На практике нам не нужно отказываться от проверок "потом". Они важны, но также важна и более внимательная проверка изменений, которые были "сейчас".

На практике, чем позже мы найдем проблемы, тем дороже нам будут исправления. Если проблема безопасности будет найдена, например, через месяц, нам придется откатиться назад, вспоминать контекст, например, зачем нам эта библиотека тут, потом переписывать кучу кода, переделывать тесты и т.д. Функционал может быть связан между собой, что приведет к еще большему количеству переписывания кода. Ну и банально исправить что-то такое, что еще свежо в памяти гораздо проще.

Давайте посмотрим гипотетическую ситуацию. Возьмём обычный Пул реквест. Например, какие-то правки, которые касаются авторизации.

Заглядываем внутрь. Что мы можем увидеть? Добавился запасной ключ. Какая-то новая неизвестная библиотека ни с того ни с сего подтянулась. Где-то был расширен доступ.

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

На ревью такие вещи могут пропустить, потому что изменения могут быть разбросаны по разным файлам. ИИ оптимизирует и рефакторит же.

Что же нам с этим делать? Может вообще запретить использовать искусственный интеллект и ИИ агентов? Ну, так себе идея. Потому что это то, что нас реально ускоряет и делает конкурентоспособнее. И никто не захочет откатываться назад.

Что еще? Может быть, будем заставлять наших разработчиков подробно читать каждое изменение полностью? Отличная идея, с учетом того, что они и так это должны делать. То есть не поменяется ничего.

Я бы обозначил ее так:

"Проблема в том, что часто у нас нет понимания, можем ли мы принимать то или иное изменение, которое сделал ИИ"

Для решения этой проблемы появился сервис HighVibe.

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

Сервис может указать, где есть риск. Объяснить, почему это является риском. И предложить, что с этим можно сделать. На человеческом языке, без отправки кода в LLM-модели.

HighVibe помогает сохранить главное преимущество разработки с помощью искусственного интеллекта, а именно — скорость.

Дело в том, что объём изменений, который мы имели раньше, был значительно меньше. Можно было более-менее качественно всё смотреть. А рисков в кибербезопасности становится все больше.

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