Когда Мэтт Шлихт создавал Moltbook — социальную сеть, где общаются ИИ-агенты, — он не писал код сам. У него «было лишь видение», и он реализовал его с помощью «вайб-кодинга» (vibe-coding). Социальная сеть была запущена 28 января 2026 года, и уже через несколько дней исследователи безопасности начали обнаруживать серьезные уязвимости.
Эксперты облачной компании по безопасности Wiz, а также независимо исследователь Джеймсон О’Райли, обнаружили, что базовая база данных Moltbook, размещенная на Supabase, была неправильно настроена. В результате она предоставляла широкий доступ на чтение и запись к данным платформы.
«Утечка включала 1,5 миллиона токенов аутентификации API, 35 000 адресов электронной почты и личные сообщения между агентами», — отметили исследователи Wiz в своем блоге.
В традиционной разработке программного обеспечения утечка секретов обычно вызвана ошибкой. Как правило, разработчик жестко прописывает ключ, копирует не тот конфигурационный файл или отправляет внутренний код в публичный репозиторий. При кодировании с помощью ИИ такие ошибки могут возникать быстро и часто остаются незамеченными, поскольку скорость и функциональность ставятся выше безопасности.
Учитывая рост популярности вайб-кодинга, эта проблема усугубляется. «Темпы, с которыми мы строим, и огромный объем кода были бы невообразимы еще несколько лет назад», — говорит Дуэйн Макдэниел, ведущий разработчик-адвокат в GitGuardian.
В 2025 году публичные коммиты кода выросли более чем на 40% по сравнению с предыдущим годом, и утечки секретов растут с такой же скоростью. По данным отчета компании GitGuardian, в прошлом году на GitHub было зафиксировано увеличение утечек секретов на 34% — самый большой скачок за всю историю, в результате чего общее число раскрытых учетных данных достигло почти 29 миллионов.
«12 из 15 самых быстрорастущих типов утечек секретов приходились на сервисы ИИ», — говорит Макдэниел. Более 1,27 миллиона секретов, связанных с ИИ, были раскрыты в 2025 году, что на 81% больше по сравнению с предыдущим годом — это самый быстрый рост, зафиксированный в какой-либо отдельной категории.
Макдэниел относит эти учетные данные к нескольким широким областям: сами платформы LLM, экосистема поддержки и оркестрации, плоскость управления ИИ (AI control plane), серверы протокола контекста модели (MCP) и ассистенты для кодирования на основе агентов.
«Меня все больше беспокоит объем кода, выводимого ИИ, и скорость, с которой разработчики его проверяют», — говорит Кристин Бехераско, CISO компании WithSecure. «Это может привести к появлению большего количества уязвимого кода, особенно учитывая, что передовые модели ИИ теперь способны выявлять уязвимости в масштабе».
Утечки секретов требуют немедленного реагирования
Многие организации глубоко осознают, что у них есть проблема с кодом, сгенерированным ИИ. Однако некоторые не осознают серьезности ситуации и того, сколько секретов раскрывается в их системах.
Когда обнаруживается утечка секрета, проблема должна рассматриваться как инцидент безопасности. «Мы немедленно активируем наш процесс реагирования на инциденты», — говорит Бехераско из WithSecure.
Секрет отзывается или отключается, и генерируется новый. «Затем команда реагирования на инциденты работает с R&D для расследования последствий для систем и данных. За этим следует очистка, а затем усиление защиты», — говорит она. «Хотя инцидентами обычно руководит офис CISO, команда R&D отвечает за фактическую отзыв и очистку».
Организация проводит постмортемы и внедряет любые необходимые обновления систем или политик на основе полученных знаний.
Хотя устранение последствий имеет решающее значение, этот процесс далеко не прост. По данным GitGuardian, 64% действительных секретов, выявленных в 2022 году, остаются не отозванными в 2026 году, в основном потому, что многим организациям не хватает управления и повторяющихся процессов, необходимых для их очистки в масштабе.
«Мы считаем, что это меньше проблема видимости, а больше сочетание приоритетов, инструментов и ответственности», — говорит Макдэниел из GitGuardian.
Обнаружение — это легкая часть, говорит Рохан Гупта, вице-президент по облачным технологиям, безопасности и DevOps в R Systems. «Устранение последствий — это то место, где проверяется дисциплина».
Решение более широкой проблемы
По мере расширения кодирования с помощью ИИ руководители служб безопасности должны переосмыслить подход к управлению рисками. Это означает выход за рамки репозиториев и обеспечение безопасности всего жизненного цикла разработки программного обеспечения (SDLC), включая инструменты совместной работы, где часто появляются учетные данные.
«Мы фокусируемся на обоих аспектах, но профиль риска сильно различается — то, что обнаруживается в Jira или Slack, сильно отличается от того, что вы найдете в репозитории кода», — говорит Дэвид Маккиннон, директор по безопасности в N-able. «Зрелый SDLC — который включает в себя такие вещи, как эффективное хранение учетных данных (credential vaulting), разделение обязанностей, сканирование исходного кода, раздельные среды разработки, тестирования/продакшена и многое другое — помогает минимизировать бизнес-риски».
В WithSecure Бехераско говорит, что секреты и доступ агентов поддерживаются «настолько транзиентными, насколько это возможно» для снижения риска. Также действует Политика безопасности жизненного цикла, которая предписывает проводить проверку кода. «Эта политика фактически является «библией» безопасности для разработчиков», — говорит она. «Она охватывает оценку воздействия на конфиденциальность, моделирование угроз, тестирование безопасности и проверку кода».
Гупта из R Systems согласен, советуя организациям ротировать учетные данные, отзывать раскрытые версии, проводить аудит несанкционированного использования в любом окне раскрытия и по возможности удалять из истории. «Для долгосрочных устаревших служебных учетных записей, сторонних интеграций ротация встроенных учетных данных поставщиков по-прежнему является скоординированным ручным упражнением, и мы постепенно переводим все больше этого в автоматизацию», — говорит он.
Ключевым шагом в решении проблемы является знание о ее существовании. «Если организация не знает, сколько секретов она раскрывает в своей кодовой базе или какой уровень доступа имеют эти секреты, она несет огромный бизнес-риск, о котором не подозревает», — говорит Маккиннон из N-able.
Он советует CISO повышать осведомленность о масштабах проблемы. Он также предлагает более качественное обучение разработчиков, лучшие инструменты для обнаружения и управления рисками, а также решения, которые позволяют как человеческой, так и управляемой ИИ разработке работать безопасно. Не менее важно, по его словам, встраивать эти практики в повседневные рабочие процессы, чтобы безопасность стала частью процесса написания кода, а не чем-то, добавляемым постфактум.
Его организация сканирует секреты при коммите кода, чтобы заблокировать любые коммиты, которые могут внести риск в продукты. «К создателю этого кода, будь то человек или ИИ, предъявляются те же требования к зрелости безопасности», — добавляет Маккиннон.
Бехераско согласна. «Мы должны целенаправленно заранее определять ответственность и постоянно ее проверять, пресекая все, что ускользает», — говорит она. «В противном случае эти неуправляемые идентификаторы и секреты будут накапливаться быстрее, чем мы сможем их контролировать».
Советы для CISO
Если и есть один ясный урок из роста разработки, управляемой ИИ, то он таков: самая большая ошибка, которую могут совершить CISO, — это рассматривать расползание секретов как проблему сканирования. «На самом деле это проблема владения и управления машинных идентификаторов в масштабе», — говорит Макдэниел.
Гупта идет дальше. «Утечка секрета — это симптом неуправляемой проблемы с нечеловеческими идентификаторами (NHI)», — говорит он. «Если рассматривать это как обнаружение и реагирование, вы будете вечно гоняться за утечками. Если рассматривать это как управление идентификацией — инвентаризация каждого NHI, назначение владельца, принудительное использование краткосрочных учетных данных, предпочтение идентификаторов рабочих нагрузок статическим ключам, агрессивное прекращение использования после ротации — проблема начнет уменьшаться, а не расти».
И хотя публичные утечки привлекают внимание, большая часть раскрытия секретов накапливается в частном порядке — во внутренних репозиториях, системах сборки и рабочих процессах разработчиков, — где ответственность неясна, а устранение последствий часто откладывается.
«Частное часто ошибочно принимают за безопасное, хотя на самом деле это просто означает, что на него меньше глаз», — говорит Гупта. «Внутри частных репозиториев люди расслабляются. Поскольку это кажется локализованным, бдительность ослабевает. Достаточно одной проблемы с цепочкой поставок или того, что кто-то уйдет с несанкционированным доступом».
Настоящий риск заключается в огромном объеме NHI, создаваемых быстрее, чем организации могут их отслеживать. «Самые умные CISO сейчас подталкивают свои команды DevOps и разработки к внедрению лучших способов управления авторизацией, чем долгоживущие, избыточно привилегированные ключи API», — говорит он.
Для Бехераско из WithSecure проблемы безопасности, связанные с кодом, сгенерированным ИИ, являются неотложными. «Аппетит руководителей организаций к внедрению ИИ сейчас высок, и мы должны управлять этим риском, даже несмотря на то, что возможности и средства контроля еще не полностью созрели», — говорит она.
Тем не менее, несмотря на срочность, отрасль все еще ищет способы реагирования. «Я не думаю, что у кого-то есть правильные ответы; мы все создаем управление по ходу дела», — говорит Бехераско. По мере того как ИИ-агенты становятся более распространенными, традиционные подходы могут не успевать, и организациям, возможно, придется использовать ИИ для управления ИИ, добавляет она.
Маккиннон считает, что CISO не должны оставаться в одиночестве в этом вопросе. Им следует привлекать генеральных директоров и технических директоров к этому процессу и объяснять им, что «риск реален и он широко распространен».
«Никогда не бывает идеального времени для решения этой проблемы, но инвестиции в упреждающее снижение этого риска намного проще и дешевле, чем узнавать о нем после того, как он был использован для компрометации вашей компании», — говорит Маккиннон.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Andrada Fiscutean
