AI-асистенти для кодування пишуть небезпечний код: Що потрібно знати розробникам

Станом на березень 2026 року дослідники виявили 74 CVE (Common Vulnerabilities and Exposures), безпосередньо пов'язані з кодом, згенерованим AI. 35 з них були виявлені лише у березні. Розподіл: Claude Code сприяв 27 CVE, GitHub Copilot 4, а Devin 2.

Це не гіпотетичний ризик. Це реальні вразливості у виробничих системах, створені AI-асистентами для кодування, яким розробники довіряли писати безпечний код.

Заголовок The Register у березні 2026 року сказав це прямо: "Кодування з AI не означає, що ваш код більш безпечний." Дослідження Stanford підтвердило, що розробники, які використовують AI-асистентів, насправді створюють більше вразливостей безпеки, ніж ті, хто кодує без допомоги AI.

Зростання "Vibe Coding"

У розробці програмного забезпечення з'явився новий термін: "vibe coding". Він описує розробників, які приймають код, згенерований AI, з мінімальним оглядом — натискаючи "accept" на основі того, чи код "відчувається правильним", замість того, щоб ретельно його аналізувати.

Проблема? Вразливості безпеки не завжди "відчуваються неправильними". Вразливість SQL injection виглядає як звичайний код бази даних. Небезпечна десеріалізація виглядає як стандартна обробка об'єктів. Cross-site scripting може ховатися у, здавалося б, нешкідливій маніпуляції рядками.

Коли розробники приймають сотні пропозицій AI щодня, ретельний огляд стає неможливим. Код відправляється, вразливості відправляються разом з ним.

Реальні ризики безпеки від AI-асистентів коду

1. Вразливі шаблони коду

AI-асистенти коду навчаються на публічних репозиторіях — включаючи репозиторії, повні небезпечного коду. Вони вчаться загальним шаблонам, не обов'язково безпечним шаблонам.

Поширені вразливості, які вводить AI:

Вразливість	Як AI її вводить
SQL Injection	Пропонує конкатенацію рядків замість параметризованих запитів
XSS	Генерує код, який не санітізує введення користувача
Path Traversal	Створює файлові операції без належної валідації
Insecure Deserialization	Пропонує десеріалізувати ненадійні дані
Hardcoded Secrets	Іноді включає облікові дані-заповнювачі, які виглядають реальними
Weak Cryptography	Використовує застарілі алгоритми (MD5, SHA1)

2. Ваш код стає навчальними даними

На безкоштовних рівнях більшості AI-асистентів для кодування ваш код може використовуватися для навчання майбутніх моделей:

• GitHub Copilot Free/Individual: Фрагменти коду використовуються для вдосконалення моделі (якщо ви не відмовитеся)
• Cursor AI Free: Подібні політики збору даних
• Claude Free Tier: Розмови можуть використовуватися для навчання

Це означає:

• Ваші власні алгоритми можуть впливати на пропозиції коду для конкурентів
• Чутлива бізнес-логіка може з'явитися у пропозиціях інших розробників
• Торгові секрети, вбудовані в код, теоретично можуть бути видобуті

Корпоративні рівні зазвичай пропонують угоди про захист даних, але багато розробників використовують безкоштовні рівні, не розуміючи наслідків.

3. Розкриття облікових даних

Коли ви використовуєте AI-асистента коду, ви часто ділитеся контекстом, що включає:

• Змінні середовища (іноді містять ключі API)
• Файли конфігурації
• Рядки підключення до бази даних
• Внутрішні кінцеві точки API

Навіть якщо ви не вставляєте облікові дані безпосередньо, AI-асистенти можуть вивести їх з контексту або запропонувати шаблони коду, які їх розкривають.

Приклад вразливості:

# AI може запропонувати цей шаблон:
import os
api_key = os.getenv("API_KEY")
print(f"Using key: {api_key}")  # Логує секрет!

4. Ризики ланцюга постачання

AI-асистенти коду можуть запропонувати:

• Застарілі пакети з відомими вразливостями
• Typosquatted назви пакетів (шкідливі пакети з подібними назвами)
• Залежності, які ви не мали наміру додавати
• Пакети, які затягують небезпечні транзитивні залежності

Розробник, який запитує "як мені розпарсити JSON у Python?" може отримати пропозицію встановити випадковий пакет замість використання вбудованого модуля json.

5. Проблема п'ятничного дня

Gartner створив хвилі у 2026 році, запропонувавши компаніям "заборонити Copilot у п'ятницю після обіду". Аргументація: втомлені розробники наприкінці тижня більш схильні приймати пропозиції AI без належного огляду.

Це підкреслює ширшу проблему: AI-асистенти найнебезпечніші, коли розробники:

• Втомлені
• Під тиском дедлайнів
• Працюють над незнайомими кодовими базами
• Багатозадачні

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

Останні дослідження та висновки

Дослідження Georgia Tech (березень 2026)

Найбільш комплексне дослідження на сьогодні відстежило CVE, конкретно пов'язані з кодом, згенерованим AI:

• 74 загальні CVE відстежені до AI-асистентів коду
• Claude Code: 27 CVE (найбільше через його можливості доступу до файлової системи та виконання коду)
• GitHub Copilot: 4 CVE
• Devin: 2 CVE
• 35 CVE виявлено лише у березні 2026 — темп прискорюється

Дослідження Stanford (2025)

Контрольоване дослідження виявило, що розробники, які використовують AI-асистентів:

• Більш схильні писати небезпечний код
• Більш впевнені, що їх код безпечний (незважаючи на те, що він менш безпечний)
• Менш схильні консультуватися з документацією з безпеки

Звіт Pillar Security (2026)

Дослідники безпеки виявили нові вектори атак у GitHub Copilot та Cursor AI:

• Ін'єкція промптів через файли репозиторію
• Ексфільтрація контексту коду на зовнішні сервери
• Маніпуляція пропозиціями через стратегічно створені коментарі коду

Як використовувати AI-асистентів коду безпечніше

1. Ставтеся до пропозицій AI як до ненадійного введення

Кожна пропозиція повинна бути:

• Переглянута рядок за рядком
• Перевірена на наслідки для безпеки
• Валідована проти найкращих практик безпеки

Не припускайте, що код, згенерований AI, безпечний, тому що він працює.

2. Використовуйте корпоративні рівні для чутливого коду

Якщо ви працюєте над власним кодом:

Продукт	Корпоративний захист
GitHub Copilot Enterprise	Код не використовується для навчання, відповідає SOC 2
Cursor AI Business	Покращений захист даних
Claude Enterprise	Доступна угода про обробку даних

Різниця у вартості мінімальна порівняно з ризиком витоку коду.

3. Ніколи не діліться обліковими даними з AI

Не робіть:

• Не вставляйте ключі API у промпти
• Не включайте файли .env у контекст
• Не просіть AI "відлагодити цей рядок підключення" з реальними обліковими даними

Робіть:

• Використовуйте значення-заповнювачі: YOUR_API_KEY_HERE
• Редагуйте чутливі значення перед діленням коду
• Зберігайте облікові дані в окремих файлах, виключених з AI

4. Запускайте сканування безпеки

Інтегруйте автоматизовані інструменти безпеки, які вловлюють те, що AI пропускає:

• Інструменти SAST (Semgrep, SonarQube) для аналізу коду
• Сканери залежностей (Snyk, Dependabot) для вразливих пакетів
• Сканери секретів (GitGuardian, TruffleHog) для витоку облікових даних

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

5. Створіть командні керівництва

Встановіть чіткі політики для використання AI-асистентів коду:

• Які рівні схвалені для використання
• Які типи коду не можуть використовувати допомогу AI
• Необхідні процеси огляду для коду, згенерованого AI
• Вимоги до навчання з безпеки

6. Безпечне спільне використання облікових даних для розробки

При співпраці над проектами, що включають чутливі облікові дані:

Не робіть:

• Не діліться обліковими даними через Telegram, Viber або email
• Не комітьте облікові дані у репозиторії (навіть приватні)
• Не вставляйте облікові дані в інтерфейси чату AI

Робіть:

• Використовуйте менеджери паролів для спільного використання командних облікових даних
• Використовуйте інструменти управління секретами (HashiCorp Vault, AWS Secrets Manager)
• Діліться одноразовими обліковими даними через зашифровані, що закінчуються посилання

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

Шлях вперед

AI-асистенти коду нікуди не зникають. Вони занадто корисні. Але поточний підхід — довіра AI писати безпечний код — явно провалюється.

Рішення не в тому, щоб відмовитися від інструментів кодування AI. Це:

1. Ставтеся до AI-коду як до коду молодшого розробника — він потребує огляду
2. Підтримуйте інструменти безпеки — автоматизоване сканування вловлює помилки AI
3. Захищайте свої дані — використовуйте корпоративні рівні, не діліться секретами
4. Залишайтеся інформованими — ризики безпеки еволюціонують у міру розширення можливостей AI

74 CVE, виявлені на початку 2026 року, це лише початок. У міру того, як AI-асистенти коду стають потужнішими і ширше приймаються, поверхня атак зростає. Готуйтеся відповідно.

Дізнайтеся більше: Як безпечно використовувати інструменти AI →

Створіть безпечну нотатку для обміну обліковими даними →