ИИ обнаруживает критические уязвимости: как бизнесу снизить риски

ИИ-уязвимости. Что делать, когда ИИ взламывает все? На повестке дня сегодня вопрос кибербеза. И в целом - как вообще с этим быть? Вопрос этический, бизнесовый и вопрос глобальной безопасности того, что сейчас происходит. Ранее нам рассказывали про то, как модели находили какие-то уязвимости на закрытых тестах. Сейчас же мы попадаем в ситуацию, когда за один день грохнуло сразу две очень громкие новости. Первая случилась уже не в первый раз - это уязвимость в LiteLLM. Версия 1.107.0 уводит пароли из браузеров и ключи доступа к AI-сервисам, а также позволяет запускать чужой код, если просто открыть любую Python-программу в зараженном окружении. Второе - критическая уязвимость в PHP. Я знаю огромную кучу сайтов, которые работают на нем, а в компаниях, где я работал, он активно используется и составляет ядро бизнеса. И мы постепенно пришли к такой стадии, когда LLM, причем далеко не самые свежие, находят такие уязвимости, которые буквально могут положить не просто какой-то отдельный бизнес, а весь интернет и инфраструктурные сервисы. На мой взгляд, подобные проблемы подсвечивают ряд системных историй, которые важно учитывать и бизнесу, и разработчикам самих моделей. Я неоднократно отмечал, что современные поколения моделей разрабатываются спустя рукава. Вместо того чтобы останавливать обучение и думать, как сделать модели безопасными, все бегут вперед в гонке за AGI и конкурентным преимуществом. Дыры просто затыкают системными промптами, по которым модель отказывается что-то делать, но никто не занимается нормальной вычисткой данных и переосмыслением того, что вообще попадает в обучающую выборку. Результат не заставил себя долго ждать. Появилась эта уязвимость, и это очень важный звоночек. Повезло, что ее открыли условные "белые хакеры", а не злые. Однако из-за того, что фикс выходит уже после попадания истории в паблик, огромное количество сервисов все равно не обновится и поляжет. Пострадает куча данных и бизнесов. Здесь хочется поделиться мыслями о том, как быть бизнесу и специалистам в эпоху, когда любой рандомный человек может взять LLM и целенаправленно использовать ее для атаки в твою сторону. 1. Изолирование окружения Я очень часто вижу, что компании сейчас хотят пойти в сторону какого-то харнесса и доверить агентам очень многое. По сути, это то, чего делать не стоит. При проектировании интеграций и бизнес-процессов компании стоит четко понимать, что мы условно готовы раскрывать, а что не готовы. И эти два окружения должны быть изолированы друг от друга. Независимо от того, разработка это, продуктовая работа или что-то еще. 2. Проактивная кибербезопасность Возрастает общий риск с точки зрения кибербеза. Компании должны думать не только о том, как внедрить AI в свои бизнес-процессы, но и о том, как предотвратить угрозы, которые он несет - вне зависимости от того, используете вы ИИ внутри себя или нет. Возрастает роль отделов кибербезопасности, и их деятельность должна быть не просто превентивной, а проактивной. Команды должны использовать современные инструменты, чтобы имитировать атаки на свою инфраструктуру и сервисы, понимать возможности AI и митигировать эти риски до того, как возникнет реальная проблема. 3. Базовые меры для тех, кто вайб-кодит Если вы вайб-кодите свои проекты, пет-проекты или что-либо еще, всегда нужно закладывать вероятность того, что ваш сервис взломают. Это стопроцентно возможно и происходит сейчас постоянно, те же API-ключи сливаются регулярно. Нужно сразу держать в голове сценарий взлома. Минимальные меры здесь - ставить лимиты на API-ключи к серверам, закрывать доступ по SSH и делать другие базовые процедуры, которые минимизируют вероятность взлома и финансовые потери, если он все-таки случится. 4. Проверка сервиса через сильные модели Для людей, активно использующих AI в разработке и вайб-кодинге, один из лучших способов предотвратить подобные истории - самостоятельно инициировать проверку в сильных моделях на высоком уровне effort. Вы сделали сервис, фичу или продукт - откройте отдельный чат в кодинговом агенте и поставьте ему задачу этот сервис как-то взломать и сломать. Лучше сделать это самостоятельно в условиях песочницы, чем подвергнуться атакам конкурентов, нехороших людей или просто попасть под общую волну, когда об уязвимости в каком-нибудь языке, фреймворке или библиотеке станет известно на весь интернет. 5. Обновления и рубильник Если ваши проекты построены на открытых библиотеках, следите за обновлениями, а при накатывании этих обновлений - просите агента проверить код на наличие уязвимостей. И еще один важный момент - у вас всегда должен быть под рукой рубильник и возможность быстро отключить свои сервисы от интернета. Сейчас это тоже критически важная история. 🚀 Влад Корнышев про AI и создание AI-продуктов