84% айтівців уже використовують або планують використовувати AI-інструменти у своїй роботі. Разом із популярністю генеративного ШІ зростає й кількість нових ризиків. Так, моделі здатні не лише пришвидшувати розробку, а й відтворювати вразливості, рекомендувати небезпечні залежності або генерувати помилки в логіці контролю доступу.
Разом із Юрієм Гальчевським, CISO / ICT Risk Manager, HBJ розбирається, чого варто очікувати від згенерованого коду, як його перевіряти перед релізом і які практики допоможуть безпечно інтегрувати AI в процес розробки.
Що таке vibe coding і чому він став популярним
Vibe coding — це підхід, за якого розробник описує задачу природною мовою, а AI генерує значну частину коду або навіть цілий функціональний модуль. Інакше кажучи, розробники більше не мають писати кожну функцію вручну, й натомість керують процесом генерації коду: формулюють вимоги, уточнюють контекст, перевіряють результат і вирішують, що залишити, а що доопрацювати.
Популярність підходу найперше пояснюється швидкістю. Те, на що раніше могли йти години або навіть дні, сьогодні нерідко займає кілька хвилин. Вайб-кодинг підходить для створення MVP, швидкого прототипування, автоматизації рутинних задач, генерації тестів і документації.
Втім, швидкість не завжди означає якість. AI здатний згенерувати код, який успішно компілюється й коректно працює в базових сценаріях, але водночас містить приховані вразливості або невдалі архітектурні рішення. Тому питання безпеки згенерованого коду сьогодні виходить на перший план.
Чому код, написаний AI, може бути небезпечним
Найчастіше проблеми виникають через те, що моделі бракує повного контексту проєкту. Вона не знає архітектури застосунку, бізнес-логіки, внутрішніх правил команди чи моделі загроз і працює лише з інформацією, яку отримує в запиті. Якщо цього недостатньо, модель починає робити припущення.
Тоді AI може використовувати застарілі практики, пропускати перевірку вхідних даних, помилятися в логіці авторизації та контролю доступу або пропонувати рішення, які добре працюють локально, але створюють проблеми на рівні всієї системи.
Це підтверджують і дослідження. За даними Veracode GenAI Code Security Report 2025, лише близько 55% завдань із генерації коду завершувалися безпечною реалізацією. В інших випадках згенерований код містив відомі вразливості або порушував базові принципи безпечної розробки.
«Найбільшу небезпеку часто становить не поганий код, а хибне відчуття, що з ним усе гаразд. AI може згенерувати код, який компілюється, проходить тести й навіть справляє враження професійного рішення. Але він не знає, яка у вас модель загроз, де проходять межі довіри й чому саме так побудована бізнес-логіка», — пояснює Юрій Гальчевський, CISO, ICT & Security Risk Manager.
Локально правильна функція може непомітно порушити авторизацію на рівні всього процесу, відкрити доступ до зайвих даних або створити race condition, який проявиться в найбільш невдалий момент, уточнює фахівець.
«Модель відповідає на запит, а не за архітектуру. Тому головна небезпека не в тому, що AI пише поганий код, а в тому, що команда може без достатньої перевірки прийняти рішення, логіку якого сама до кінця не проаналізувала».
Які вразливості найчастіше з'являються в AI-коді
Один із поширених прикладів — SQL injection. Подібна вразливість може виникнути, коли AI формує запит через конкатенацію рядків замість параметризованих запитів. Також модель може некоректно екранувати користувацьке введення, що відкриває шлях до XSS-атак, або не перевіряти формат, тип і допустимі значення вхідних даних.
Окрема група ризиків пов'язана з автентифікацією та авторизацією. Наприклад, код може перевіряти, чи увійшов користувач у систему, але не враховувати, чи має він право виконувати конкретну дію. У згенерованому рішенні також можуть залишитися тестові API-ключі, токени або паролі. Крім того, AI іноді пропонує небезпечну роботу з файлами чи спрощує механізми захисту, щоб код швидше запрацював.
Не всі вразливості можна виявити за типовими патернами. Найскладнішими часто стають помилки бізнес-логіки: код може працювати саме так, як написано, але порушувати внутрішні правила системи. На цю проблему звертає увагу Юрій Гальчевський:
«Особливо підступними я вважаю business logic flaws та IDOR. Вони не „кричать“, що в системі є баг, а спокійно чекають, поки хтось підставить чужий ID у URL. Причина проста: AI не знає, як влаштована саме ваша система. Він генерує код на основі найімовірніших шаблонів. Якщо в промпті не описати ролі користувачів, правила доступу чи можливі нестандартні сценарії, модель самостійно "додумає" відсутні деталі. Саме такі припущення можуть призвести до критичних вразливостей».
Ризики сторонніх бібліотек і вигаданих залежностей
Іноді модель генерує не просто нерелевантний фрагмент коду, а посилається на бібліотеку, якої взагалі не існує. Це ще один ризик — package hallucination.
Подібна помилка може стати точкою входу для атаки. Зловмисники здатні зареєструвати пакет із вигаданою назвою в npm або PyPI, додати до нього шкідливий код і чекати, поки хтось встановить його, довірившись рекомендації AI. Саме тому package hallucination сьогодні розглядають як один із потенційних ризиків для software supply chain.
Втім, небезпеку становлять не лише вигадані пакети. AI також може рекомендувати застарілі або вже непідтримувані версії бібліотек, залежності з відомими вразливостями чи компоненти з ліцензіями, несумісними з політикою компанії. Тому будь-яку нову залежність варто дуже ретельно перевіряти.
Як зазначає Юрій Гальчевський, увагу варто приділяти і вигаданим пакетам, і цілком реальним залежностям, адже останні можуть становити не меншу загрозу.
«Перш ніж додавати пакет у проєкт, варто перевірити офіційний реєстр, репозиторій, видавця, активність супроводу, історію релізів, відомі CVE, транзитивні залежності, ліцензію, цифрові підписи та provenance. Версії бажано фіксувати, а самі залежності регулярно перевіряти за допомогою SCA-інструментів», — каже фахівець.
Він додає, що мільйони завантажень не гарантують безпеки. Це лише показник того, що пакет використовує багато людей».
Як перевіряти AI-згенерований код перед релізом
«До AI-згенерованого коду застосовують ті самі вимоги SDLC, що й до написаного людиною, а для критичних компонентів вони мають бути навіть суворішими, бо “ШІ написав” — це не індульгенція, — наголошує Юрій. — Мінімальний набір захисних практик має включати рев’ю коду фахівцем, який добре розуміє його логіку, функціональне й негативне тестування, SAST, SCA, secret scanning, а також перевірку IaC та безпеки CI/CD. Для застосунків і сервісів, які можна тестувати під час виконання, варто використовувати DAST, а для критичної бізнес-логіки — threat modeling і цільове security testing. Автоматизовані сканери добре виявляють відомі шаблони вразливостей, але значно гірше розпізнають проблеми в бізнес-логіці та архітектурі. Тому відповідальність за merge завжди залишається на людині».
На практиці це означає, що відповідь на запитання «як перевірити код» не залежить від того, хто його написав — розробник чи AI. Основою процесу залишається принцип human-in-the-loop, коли фінальне рішення про готовність змін до релізу завжди ухвалює людина.
Першим етапом є code review, а для критичних компонентів — security code review. Під час цього оцінюють не лише якість реалізації, а й відповідність архітектурі, вимогам secure coding та бізнес-логіці проєкту.
Наступний крок — автоматизоване тестування, яке охоплює unit- та інтеграційні тести, а також тестування безпеки. Для цього використовують статичний аналіз коду (SAST), DAST, SCA, сканери вразливостей, secret scanning та інші інструменти, які допомагають знайти потенційні проблеми ще до того, як зміни потраплять у production.
Як безпечно працювати з AI coding agents
На відміну від звичайних AI-асистентів, AI coding agents можуть не лише генерувати код, а й взаємодіяти з репозиторіями, запускати команди, змінювати файли та виконувати окремі етапи розробки. Саме тому для роботи з ними вже недостатньо звичайних правил використання AI для програмування — потрібні окремі механізми контролю.
Оскільки такі агенти можуть взаємодіяти із середовищем розробки та інфраструктурою, важливо не лише обмежити їхні повноваження, а й контролювати виконання критичних дій. Один із ключових принципів безпечної роботи — human-in-the-loop, коли остаточне рішення про виконання потенційно небезпечних команд завжди залишається за людиною.
«AI coding agent — це не «розумний автокомпліт з характером», а привілейований технічний суб'єкт, який цілком реально виконує команди й змінює середовище, поки ви п'єте «лавандовий раф на кокосовому молоці», — зазначає Юрій.
Тому безпечна робота з AI coding agents має будуватися на кількох базових принципах.
Мінімальні права доступу. Агент має працювати через окремий сервісний акаунт, у sandbox або ephemeral workspace, з обмеженим доступом до файлової системи й мережі, короткоживучими credentials та allowlist інструментів.
Жодного неконтрольованого доступу до production. Агент не повинен бачити production-секрети, мати прямий деплой або самостійно змінювати CI/CD без людського підтвердження.
Повне журналювання дій. Усі дії потрібно логувати. І не тому, що ви не довіряєте агенту, а тому, що довіра без логів — це просто оптимізм.
Недовіра до будь-якого вхідного джерела. Репозиторій, issue, README і навіть відповідь MCP-сервера — усе це недовірений вхід. Через нього зловмисник цілком може реалізувати prompt injection і непомітно взяти керування агентом на себе.
Як інтегрувати перевірки безпеки в CI/CD
Окремі перевірки не дадуть очікуваного результату, якщо запускати їх лише час від часу або виконувати вручну. Щоб вразливості не потрапляли в production, тестування безпеки має стати частиною CI/CD і автоматично запускатися після кожної зміни.
На практиці кожен pull request перевіряють ще до злиття з основною гілкою. Конвеєр може включати unit- та інтеграційні тести, SAST, dependency scanning, secret scanning, аналіз контейнерів і перевірку ліцензій. Крім того, команди нерідко перевіряють код на відповідність рекомендаціям OWASP Top 10, щоб своєчасно виявити найпоширеніші ризики безпеки. За потреби до конвеєра також додають DAST для тестового середовища.
Якщо система виявляє критичну вразливість, секрет у коді або небезпечну залежність, збірка автоматично блокується до усунення проблеми. Додаткові політики можуть забороняти використання бібліотек із відомими CVE або версій, які більше не підтримуються. Перед розгортанням фінальний артефакт ще раз перевіряють на відповідність вимогам безпеки.
Командам, які лише починають вибудовувати цей процес, Юрій Гальчевський радить зосередитися на трьох базових кроках.
Чітка політика використання AI. Команда має визначити, що можна передавати моделі, які інструменти дозволені й хто відповідає, коли щось піде не так (а щось таки піде).
Обов’язковий конвеєр перевірки. Людський review, тести, SAST, SCA та secret scanning мають застосовуватися до кожної AI-assisted зміни — без винятків на кшталт «у нас дедлайн!»
Розмежування доступу. Coding agents мають працювати лише в sandbox, із мінімальними правами й без production credentials.
Головне — не створювати окремий «AI-процес» в обхід звичайного secure SDLC. Інакше у вас буде два процеси й нуль безпеки. AI — це прискорювач розробника, а не джерело довіри. Швидкість генерації зростає, але вимоги до перевірки й персональної відповідальності мають залишатися такими ж непохитними, як і раніше, а в ідеалі — ще жорсткішими».
FAQ
Чи можна використовувати AI-код у production?
Так, але лише після тих самих перевірок, що й код, написаний людиною: code review, тестування та сканування на вразливості. AI-код не повинен отримувати «привілей довіри» лише тому, що виглядає акуратно.
Які інструменти допомагають знайти вразливості в коді?
Для цього зазвичай використовують комбінацію SAST для статичного аналізу, DAST для динамічного тестування, dependency scanning для перевірки сторонніх бібліотек і secret scanning для виявлення випадково закомічених секретів, токенів та ключів доступу.
Що таке package hallucination?
Це ситуація, коли AI-модель вигадує пакет або бібліотеку, яких насправді не існує. Якщо зловмисник встигає зареєструвати такий пакет у публічному репозиторії, розробник може несвідомо встановити шкідливу залежність замість потрібної.
Хто відповідає за помилки в коді, створеному AI?
Відповідальність за AI-згенерований код несе команда розробки та компанія, яка випускає продукт. AI є лише інструментом, а остаточне рішення про включення коду до проєкту завжди ухвалює людина.
