Ви довіряєте своєму ШІ-асистенту для коду. Він пише чисті функції, обробляє граничні випадки, залишає корисні коментарі. Код компілюється, тести проходять, pull request — пропозиція влити новий код у основний проєкт — отримує палець вгору. Через три місяці пентестер знаходить дірку у функції, яку ваш агент написав о другій ночі. Ніхто не поставив під сумнів, бо 'виглядало норм'.

Це не мисленнєвий експеримент. Це звичайний вівторок.

Прірва між впевненістю та компетентністю

ШІ-згенерований код — це вже приблизно 46% нового коду в багатьох компаніях. Від цього не сховатися. Але десь між 'ШІ написав' і 'ми задеплоїли' прокралося небезпечне припущення: що машина розуміє, що робить. Ні. Це дуже швидка друкарка без жодного уявлення про зловмисників.

Вам потрібна інструкція з виживання. Ось вона.

Кожен четвертий сніпет — з діркою

У лютому 2026 дослідницька група з безпеки AppSecSanta протестувала шість великих LLM — великих мовних моделей, мозку ChatGPT, Claude, Gemini та компанії — на 89 security-орієнтованих промптах. Python і JavaScript. Реальні задачі, зіставлені з OWASP Top 10 — загальноприйнятий список найкритичніших ризиків безпеки вебзастосунків.

Результат: 25,1% згенерованого коду містив підтверджені вразливості. Кожен четвертий сніпет. Ваш ШІ штампує баги промисловими масштабами — і робить це зі спокійною впевненістю людини, яку жодного разу не зламали.

Відсоток вразливостей за моделями:

Модель Вразливості
GPT-5.2 19,1% (найкраще)
Gemini 2.5 Pro 22,4%
Grok 4 23,7%
Claude Opus 4.6 29,2%
DeepSeek V3 29,2%
Llama 4 Maverick 29,2%

Розкид у 10 пунктів означає, що вибір моделі має значення. Але навіть найкраща модель ліпить вразливість майже в кожному п'ятому результаті. Обрати GPT-5.2 замість Llama 4 — допомагає. Але не рятує.

Де моделі валяться найчастіше:

  • SSRF (Server-Side Request Forgery — коли ваш сервер обманом змушують викликати внутрішні URL від імені атакуючого): 32 знахідки. Найбільша категорія.
  • Ін'єкції (SQL injection, command injection — коли користувацький ввід прослизає в запити до бази даних чи системні команди): 30 знахідок, 33,1% усіх проблем.
  • Помилки конфігурації безпеки: 25 знахідок — захардкоджені секрети, debug-режим на продакшені.
  • Зламаний контроль доступу (коли користувачі можуть робити те, що їм не дозволено): присутній у кожній протестованій моделі.

Окреме дослідження Help Net Security від березня 2026 тестувало Claude Code, OpenAI Codex і Google Gemini в агентному режимі — не просто автодоповнення, а повністю автономне написання коду. Агенти нагенерували 143 проблеми безпеки у 38 сканах, що покривали 30 pull request-ів. 87% тих PR містили щонайменше одну вразливість. Зламаний контроль доступу з'явився у вихідних даних кожного агента. Кожного. Одного.

Чому машина пише небезпечний код

Моделі не зловмисні. Вони — машини ймовірностей, натреновані на GitHub, а GitHub — це скарбниця небезпечного коду. Відповіді зі Stack Overflow 2015 року з захардкодженими JWT-секретами (JWT — JSON Web Token, цифровий пропуск, що підтверджує вашу авторизацію). Туторіальний код, що пропускає валідацію вводу, бо 'це ж просто демо'. Продакшен-код компаній, які ніколи не проводили аудит безпеки.

Три патерни з'являються знову і знову:

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

2. Небезпечні дефолти. JWT-токени без терміну дії. OAuth-реалізації (OAuth — протокол, що дозволяє 'Увійти через Google' замість створення чергового пароля) без параметра state, який запобігає перехопленню. Refresh-токени, які не можна відкликати. Моделі генерують код, який працює, але обирає ледачий дефолт, а не безпечний.

3. SSRF усюди. Коли модель пише код для завантаження URL, вона майже ніколи не перевіряє, куди той URL веде. Жодних allowlist-ів, жодного блокування внутрішніх IP-адрес, жодних обмежень протоколу. Просто викликає requests.get(user_input) і деплоїть. Атакуючий підсовує http://169.254.169.254/ — і ось у нього вже ваші хмарні креденшали.

Ваш п'ятирівневий захисний стек

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

Рівень 1: Security-орієнтований промптинг

Найпростіший фікс, який нічого не коштує. Дослідження Veracode показало, що додавання навіть загального нагадування про безпеку до промпту підвищило відсоток безпечного коду з 56% до 66% для Claude Opus 4.6. Десять відсотків покращення від одного речення. Не магія. Але безкоштовно.

Додайте це у ваш системний промпт, правила Cursor або ваш CLAUDE.md:

When writing code: validate all inputs server-side. Never trust
client data. Use parameterized queries. Set secure defaults for
auth tokens (expiration, rotation). Block SSRF by validating URLs
against allowlists. Never hardcode secrets.

Для ШІ-агентів на кшталт Claude Code, Codex чи Copilot в агентному режимі — закиньте ці інструкції у конфігураційні файли проєкту. Агент читає їх на кожному завданні.

Рівень 2: SAST прямо в редакторі

SAST — Static Application Security Testing — сканує ваш код на вразливості без його запуску, як перевірка орфографії, але для дірок у безпеці. Ключова знахідка AppSecSanta: лише один SAST-інструмент зловив 78% вразливостей, згенерованих ШІ. Запуск кількох сканерів драматично покращує покриття.

Рекомендований сетап:

  • Semgrep — безкоштовний, швидкий, 3 000+ правил. Працює у VS Code, JetBrains і CI. Ловить ін'єкції, SSRF, захардкоджені секрети.
  • Bandit (Python) — ловить типові проблеми безпеки Python. Нульова конфігурація.
  • ESLint-плагіни безпеки (JavaScript) — eslint-plugin-security і eslint-plugin-no-unsanitized.

Встановіть Semgrep як pre-commit hook — скрипт, що автоматично запускається перед кожним комітом і блокує поганий код від потрапляння в репозиторій:

pip install semgrep
semgrep --config auto --error .

Тепер кожен коміт сканується. ШІ пише код — Semgrep дає по руках до пушу.

Рівень 3: Сканування в CI-пайплайні

Ваш pre-commit hook ловить очевидне. Ваш CI-пайплайн — автоматизована система збірки й тестування, що запускається при пуші коду — має проводити глибший аналіз:

# Приклад GitHub Actions
- name: Semgrep SAST
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/cwe-top-25
      p/python-security
      p/javascript-security

- name: Dependency check
  uses: dependency-check/dependency-check-action@v1

Зосередьте правила на категоріях, де ШІ валиться найчастіше: SSRF (CWE-918), ін'єкції (CWE-89, CWE-78), небезпечна десеріалізація (CWE-502 — коли зловмисні дані розпаковуються у виконувані об'єкти) та path traversal (CWE-22 — коли атакуючий використовує ../../ щоб вийти за межі директорії й читати файли, до яких не мав мати доступу).

Рівень 4: Людське рев'ю через призму безпеки

Code review для ШІ-згенерованого коду відрізняється від звичайного. Ви шукаєте не логічні помилки — з ними ШІ справляється прийнятно. Ви шукаєте:

  • Ендпоінти без перевірки авторизації. ШІ пише route handler, але забуває middleware — код-вартового, який перевіряє 'а тобі сюди можна?'
  • Користувацький ввід, що тече в небезпечні місця. Запити до бази, файлові операції, HTTP-запити, шелл-команди. Якщо користувацький ввід торкається будь-чого з цього без санітизації — у вас проблема.
  • Відсутній rate limiting. ШІ ніколи не додає rate limiting, якщо ви явно не попросите. Кожен публічний ендпоінт потребує його, інакше хтось забомбить його 10 000 запитів на секунду.
  • Секрети в коді. Модель іноді генерує плейсхолдерні API-ключі, які виглядають достатньо реальними, щоб задеплоїти. Потім вони потрапляють на GitHub. Потім — в чужі руки.

Навчіть свою команду ставити одне питання до кожної ШІ-згенерованої функції: 'Що буде, якщо ввід ворожий?'

Рівень 5: OpenSSF rules file

OpenSSF — Open Source Security Foundation — опублікував стандартизований гайд Security-Focused Guide for AI Code Assistant Instructions. Це файл правил, який ви кидаєте в корінь проєкту. Кожен ШІ-інструмент для коду, що підтримує інструкції на рівні проєкту, читає його автоматично.

Файл покриває валідацію вводу, кодування виводу, автентифікацію, управління сесіями, криптографію, обробку помилок і логування. Замість писати власні правила безпеки з нуля — використовуйте їхні: підтримуються security-професіоналами, оновлюються регулярно, безкоштовно.

Що це вам коштує

Час. Кожен рівень додає тертя. Pre-commit hooks додають 5–15 секунд на коміт. CI-скани додають хвилини до пайплайну. Людське рев'ю вимагає людей, які знають, як виглядає SSRF. OpenSSF-файл вимагає прочитати його один раз і зрозуміти, що він робить.

False positives будуть дратувати. Semgrep буде фолсити на коді, який насправді нормальний. Ви витрачатимете час на розслідування неіснуючих проблем. Це податок, який ви платите за те, щоб зловити справжні.

І нічого з цього не є стовідсотковим. Дослідження AppSecSanta показало, що 22% вразливостей проскочили повз усі протестовані SAST-інструменти. Деякі дірки потребують динамічного тестування — реального запуску коду й атаки на нього — щоб їх знайти. Статичний аналіз необхідний, але недостатній.

Що зробити в понеділок вранці

Не треба впроваджувати всі п'ять рівнів до наступного тижня. Почніть із двох:

  1. Додайте інструкції з безпеки в конфіг вашого ШІ. Скопіюйте блок промпту з Рівня 1. Вставте в проєкт. П'ять хвилин.
  2. Встановіть Semgrep як pre-commit hook. Дві команди. Готово до того, як охолоне кава.

Цього одного вже достатньо, щоб бути попереду більшості команд, що деплоять ШІ-згенерований код сьогодні. Додайте CI-сканування, коли буде спринт з вільним повітрям. Додайте OpenSSF-файл, коли хтось із команди прочитає його й зрозуміє. Тренуйте рев'юерів поступово.

Нова нормальність

Відсоток вразливостей у ШІ-згенерованому коді впав із приблизно 40% у 2024 до 25% у 2026. Прогрес, звісно. Такими темпами ми дістанемося до 'прийнятного' десь біля 2030. Чотири роки чекати — не варіант.

Ставтесь до ШІ-згенерованого коду як до роботи джуна, який друкує зі швидкістю 500 слів на хвилину, випромінює впевненість і ніколи не чув про OWASP. Рев'юйте. Скануйте. Тестуйте. Потім деплойте.

ШІ пише код у 10 разів швидше. Ваші інструменти безпеки мають встигати. Інструменти існують. Єдине, чого бракує — звички їх використовувати.