Перейти до вмісту

Безпека вайб-кодингу: ризики й безпечний реліз

Безпека вайб-кодингу: застосунок, створений ШІ, з TODO на місці входу й робочим ключем у коді поряд із виправленою версією за корпоративним єдиним входом

Менеджерка з продукту в п’ятницю описує ШІ-помічникові панель повернень коштів, а в неділю панель уже працює. Команді подобається, тільки вона висить за публічним посиланням на попередній перегляд, без входу й з робочим платіжним ключем у коді.

Ніхто не вимикав у цьому застосунку жодного захисту. Захисту там ніколи й не було, бо ніхто не переглянув результат як ПЗ компанії.

Що таке безпека вайб-кодингу?

Section titled “Що таке безпека вайб-кодингу?”

Безпека вайб-кодингу — це практика рев’ю, хостингу й контролю ПЗ, яке ШІ-помічник написав за запитами природною мовою, щоб воно відповідало тій самій планці, що й код, написаний вручну. Вона охоплює автентифікацію, секрети, інфраструктуру та доступи, які має сам помічник під час роботи, а не лише код, який він видає.

Андрей Карпаті запровадив термін «вайб-кодинг» (vibe coding) у лютому 2025 року для створення ПЗ, коли ви описуєте задачу й приймаєте те, що повертає модель. За кілька місяців звичка перейшла з хобі-проєктів у компанії, а разом із нею прийшли й хобі-стандарти рев’ю.

Чому ПЗ, створене вайб-кодингом, ризиковане?

Section titled “Чому ПЗ, створене вайб-кодингом, ризиковане?”

Модель оптимізує код під те, щоб він запускався, а пропущена перевірка запуску не заважає. Звіт Veracode 2025 GenAI Code Security Report перевірив понад 100 мовних моделей на 80 задачах і виявив, що згенерований код містив вразливість з OWASP Top 10 у 45% випадків.

Платформи показують ту саму прогалину в масштабі. У 2025 році дослідник безпеки Matt Palmer просканував 1 645 застосунків, створених на Lovable, і знайшов 170, у яких таблиці бази даних читалися без автентифікації; проблему відстежують як CVE-2025-48757. Причиною була відсутня або недостатня безпека на рівні рядків (row-level security) у базах даних застосунків, без якої застосунок кожного автора однаково працював.

Друга половина ризику — швидкість. Застосунок, зроблений за вихідні, рідко проходить той процес рев’ю й хостингу, який пройшов би піврічний проєкт. Він потрапляє з посилання на попередній перегляд просто до реальних даних клієнтів.

Які найбільші ризики безпеки вайб-кодингу?

Section titled “Які найбільші ризики безпеки вайб-кодингу?”

Ризики поділяються на дві групи. Одні живуть у тому, що пише помічник, інші в тому, до чого він має доступ, поки пише.

Немає автентифікації на «тимчасовому» посиланні

Section titled “Немає автентифікації на «тимчасовому» посиланні”

Помічники будують те, що їх просили, і «вхід додамо пізніше» перетворюється на коментар TODO, який іде в реліз. Хостинги попереднього перегляду випускають сертифікат для кожного нового імені хоста, а сертифікати за кілька хвилин потрапляють у публічні журнали прозорості, тож посилання, яке важко вгадати, однаково опубліковане.

Вправа про застосунок від ШІ без рев’ю переносить вас у ту саму панель повернень. Ви переглядаєте код, знімаєте посилання й повертаєте застосунок лише за корпоративним єдиним входом (SSO).

Робочі секрети прямо в коді

Section titled “Робочі секрети прямо в коді”

Згенерованому застосунку потрібен API-ключ, і найшвидше місце для нього — константа в коді. Щойно цей код працює на публічному розгортанні, ключ треба вважати розкритим, навіть якщо невідомо, чи хтось його скопіював.

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

Інфраструктура, що застосовується без помилок і виходить відкритою

Section titled “Інфраструктура, що застосовується без помилок і виходить відкритою”

Згенерований Terraform може бути коректним і зрозумілим і все одно відкривати публічний доступ до бакета сховища. terraform plan доводить лише, що провайдер може побудувати конфігурацію, а публічний ACL цілком можна побудувати.

Вправа про небезпечний згенерований IaC вчить читати, що насправді дозволяє згенерований модуль бакета. Потім ви додаєте до етапу plan бар’єр політик як коду й переконуєтеся, що анонімний запит відхиляється. Ширшу картину зі сховищами дає наш посібник про помилки конфігурації AWS.

Агенти, що працюють з вашими обліковими даними

Section titled “Агенти, що працюють з вашими обліковими даними”

Помічник із доступом до оболонки виконує кожну команду від вашого імені, з тим хмарним профілем, який ваша машина використовує за замовчуванням. У липні 2025 року засновник SaaStr Jason Lemkin повідомив, що агент Replit видалив продакшн-базу даних під час заморожування коду, і Replit у відповідь запровадив автоматичне розділення баз даних розробки й продакшну.

Вправа про хмарні облікові дані, доступні автоматично простежує схоже видалення до ключа продакшну в профілі за замовчуванням. Ви прибираєте облікові дані продакшну з ноутбука, деактивуєте ключ і повертаєте схвалення в режим «Питати перед записом».

Доступ за межі теки проєкту

Section titled “Доступ за межі теки проєкту”

Відкрита в редакторі тека позначає, де закінчується ваш проєкт. Вона не обмежує те, що може прочитати помічник, якщо його доступ до файлів не прив’язаний до цієї теки.

Вправа про необмежений доступ помічника до файлів показує консультанта, чий помічник пошукав по всьому диску й вставив код іншого клієнта в пул-реквест. Наприкінці доступ до файлів обмежено робочою областю, для кожного клієнта є окремий профіль, а коміти перевіряються на назви інших клієнтів.

Запобіжники, вимкнені через дедлайн

Section titled “Запобіжники, вимкнені через дедлайн”

Запити на схвалення, політики тенанта й хуки комітів здаються тертям, коли демо вже завтра. Їх вимкнення прибирає саме ті контрольні точки, які зловили б агента, що виконує інструкції з недовіреного файлу.

Вправа про вимкнені запобіжники ШІ — підсумкова в нашому курсі. Ви проживаєте цей шорткат, бачите, як README залежності змушує помічника записати робочий ключ у закомічений файл, а потім повертаєте кожен контроль і доводите, що тепер він зупиняє витік.

Як зробити вайб-кодинг безпечним?

Section titled “Як зробити вайб-кодинг безпечним?”

Вважайте ПЗ, створене ШІ, програмним забезпеченням компанії з першого коміту й тримайте доступи самого помічника вузькими. Ось контролі, що закривають описані ризики:

  • Розробник читає кожен інструмент, створений ШІ, до того як той торкнеться даних клієнтів, так само як будь-який інший пул-реквест.
  • Внутрішні інструменти працюють на інфраструктурі компанії за єдиним входом, а не за особистим посиланням на попередній перегляд.
  • Ключі надходять із середовища або менеджера секретів, а сканер секретів у pre-commit блокує решту.
  • Перевірка політик як коду на етапі plan зупиняє небезпечні ресурси до apply.
  • Доступ до файлів обмежено робочою областю, облікові дані продакшну не потрапляють на машини розробників, а схвалення для запису залишаються ввімкненими.
  • Ніхто не комітить з --no-verify, щоб обійти сканер. Натомість виправляйте те, що він знайшов.

Це ті самі контролі, які вже має зріла інженерна команда. Вайб-кодинг просто створює ПЗ швидше, ніж ці контролі встигають застосувати, тож прогалину треба закривати свідомо.

Хто має робити рев’ю застосунку, створеного ШІ?

Section titled “Хто має робити рев’ю застосунку, створеного ШІ?”

Розробник, який не писав промпт. Автор знає, що застосунок має робити, а рецензент читає, що він робить насправді, зокрема TODO на місці входу.

Запишіть це в політику до появи наступного інструмента. Наш матеріал про ризики тіньового ІТ пояснює, як провести несанкціоновані інструменти через процес приймання, не забороняючи їх.

Ширшу модель загроз цих помічників, зокрема промпт-ін’єкції та MCP-сервери, описує наш огляд ризиків безпеки ШІ-асистентів для програмування.

Чи безпечний вайб-кодинг для продакшн-застосунків?

Може бути, якщо результат проходить те саме рев’ю, автентифікацію й роботу із секретами, що й будь-який інший код компанії. Небезпека в тому, щоб пропустити ці кроки, бо застосунок зробили за вихідні, а не за квартал. Швидкість створення не знижує планку для того, що потрапляє до клієнтів.

Чи можна просто попросити ШІ-помічника зробити код безпечним?

Прохання допомагає, але це порада, яку наступний запит може не врахувати. Контролі, що працюють на кожній зміні, як-от рев’ю коду, сканер секретів і перевірка політик у конвеєрі, ловлять проблеми незалежно від того, хто написав код: людина чи модель.

Хто відповідає за код, який написав ШІ-помічник?

Людина й компанія, які його випускають. Прийнята пропозиція стає вашим кодом разом із будь-якою вразливістю чи ліцензійним зобов’язанням. Помічник пише чернетку, а розробник вирішує, що піде в реліз.

Як навчати розробників безпеки вайб-кодингу?

Практичні сценарії працюють краще за слайди з політиками, бо збої конкретні: публічне посилання, ключ у коді, видалення з не тим профілем. Наш курс «Безпечна розробка з ШІ-помічниками» проводить інженерів через кожен із них, а потім просить випустити виправлення й довести, що воно працює.

Почніть з одного застосунку

Section titled “Почніть з одного застосунку”

Візьміть найновіший внутрішній інструмент, який хтось створив з ШІ-помічником, і перевірте три речі: хто може відкрити його без входу, які ключі лежать у його коді та які облікові дані зберігає машина автора.

Каталог безпеки ШІ та LLM містить повний курс «Безпечна розробка з ШІ-помічниками», який можна спробувати безкоштовно. Щоб розгорнути його на інженерну команду, зв’яжіться з нами.