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

Що кажуть дослідження

Кілька досліджень вивчали безпеку коду, написаного з допомогою AI:

  • Вразливі пропозиції поширені в ризикових сценаріях. Дослідники запропонували GitHub Copilot 89 сценаріїв, побудованих навколо слабкостей CWE; приблизно 40% з 1689 згенерованих програм містили вразливості (Pearce et al., «Asleep at the Keyboard?»). Відтоді моделі покращилися, але ці сценарії — SQL-запити, робота зі шляхами, криптографія — досі є місцями скупчення помилок.
  • Розробники з асистентами пишуть менш безпечний код і почуваються впевненіше. У дослідженні Стенфорда учасники з доступом до AI-асистента писали помітно менш безпечний код у кількох задачах і частіше вважали свій код безпечним (Perry et al., 2023).
  • Вигадування пакетів — систематичне явище. У 576 тис. зразків коду від 16 моделей 19,7% рекомендованих пакетів не існували; дослідники нарахували понад 205 тис. унікальних вигаданих назв, і багато з них стабільно повторювалися між запусками (Spracklen et al., 2024).

Другий висновок найважливіший для побудови процесів: ризик не лише в коді, а й у зниженій пильності. Контролі мають компенсувати надмірну впевненість.

Класи вразливостей, за якими треба стежити

AI-код схильний відтворювати патерни, поширені в публічному коді, включно з небезпечними. Звичні підозрювані прямо відповідають OWASP Top 10:2025:

Слабкість Типова форма в AI-коді Контроль
Ін'єкції (SQL, команди, шаблони) Запити, зібрані з рядків, shell=True, неекрановані шаблони Параметризовані API, правила Semgrep, чек-лист рев'ю
Порушений контроль доступу Новий ендпоінт скопійований з публічного без перевірки авторизації Middleware з авторизацією за замовчуванням, тести маршрутів
Криптографічні помилки MD5/SHA1 для паролів, захардкоджені IV, токени з Math.random() Затверджені криптообгортки, лінтери
Помилки конфігурації CORS: *, увімкнений debug, слабкі прапорці cookie Шаблони конфігурацій, сканування IaC
SSRF Завантаження URL від користувача на сервері Allow-списки, контроль вихідного трафіку
Захардкоджені секрети Приклади API-ключів, залишені в коді Сканування секретів, push protection
Десеріалізація pickle.loads, нативна серіалізація Java на вхідних даних Список заборонених API

Нічого з цього не нове. Нове — обсяг: коли агент пише 500 рядків за хвилину, один скопійований патерн може з'явитися в десятку місць.

Slopsquatting: атака через вигадану залежність

Коли модель пропонує pip install fastapi-auth-helpers, а такого пакета не існує, зловмисник може зареєструвати його зі шкідливим кодом. Оскільки моделі повторюють ті самі вигадки, атакувальники збирають імовірні назви, просто опитуючи моделі. Атаку прозвали slopsquatting — це варіація typosquatting, яка цілиться не в людей, а в машини.

Агентні інструменти погіршують ситуацію: агент, що бачить помилку імпорту, може сам запустити команду встановлення. Захист:

  1. Ніколи не дозволяйте автоматичне встановлення залежностей у налаштуваннях агента.
  2. Перевіряйте кожну нову залежність: чи існує вона, хто її підтримує, скільки їй років, скільки завантажень, чи збігається посилання на репозиторій. Допомагають OpenSSF Scorecard і deps.dev.
  3. Використовуйте приватний проксі-реєстр (Artifactory, Nexus, Verdaccio, дзеркало pip/npm) з allow-списком або політикою мінімального віку для нових пакетів.
  4. Lock-файли й хеші цілісності мають бути закомічені й перевірятися в CI.
  5. Генеруйте SBOM і скануйте його на кожній збірці, як описано у статті про безпеку ланцюга постачання контейнерів.

Багаторівневі контролі для розробки з AI

Розглядайте контролі як чотири рівні — від клавіатури розробника до продакшену.

Рівень 1: Сам асистент

  • Правила безпеки у файлі проєкту. Додайте короткий розділ у CLAUDE.md чи AGENTS.md: «Використовуй db.query() з параметрами; ніколи не збирай SQL з рядків. Усі нові маршрути проходять через withAuth(). Не додавай залежності без запиту». Асистенти значно краще виконують конкретні правила, ніж загальне «пиши безпечний код».
  • Обмежені дозволи. Без мережі, встановлень і доступу до файлів з обліковими даними без підтвердження. Див. найкращі практики агентного кодування.
  • Хуки, що блокують правки чутливих шляхів (авторизація, криптографія, платежі) або вимагають для них людини.

Рівень 2: До коміту

  • Сканування секретів у pre-commit з Gitleaks чи аналогом.
  • Швидкий SAST з правилами Semgrep під ваш стек. Власні правила для внутрішніх API («ніколи не викликай rawQuery») ловлять саме ті патерни, які копіює асистент.
  • Розробник переглядає кожен рядок. Відповідальність лишається за людиною, яка комітить.

Рівень 3: Пул-реквест і CI

  • Повний SAST з CodeQL чи аналогом плюс сканування залежностей.
  • AI-рев'ю безпеки як додатковий прохід із промптом, що містить вашу модель загроз і заборонені патерни, — див. AI-рев'ю коду. Воно добре пояснює, чому щось небезпечно, і це допомагає розробникам навчатися.
  • Шлюз для нових залежностей: CI-задача падає, якщо lock-файл додає пакет, доки людина його не погодить.
  • Тести безпекових властивостей: тести авторизації для кожного маршруту, тести валідації вхідних даних для парсерів.

Рівень 4: Рантайм

  • Сервісні облікові записи з мінімальними правами і контроль вихідного трафіку обмежують наслідки будь-якої пропущеної вразливості.
  • WAF і ліміти частоти перед публічними ендпоінтами.
  • Спостережуваність і алерти на помилки авторизації, незвичні запити та сплески помилок; див. OpenTelemetry.

Приклад правила Semgrep

Власні правила — місце, де ви кодуєте специфічні небезпеки своєї кодової бази. Це правило позначає SQL, зібраний з рядків, для клієнта конкретного проєкту:

rules:
  - id: no-string-built-sql
    languages: [typescript]
    severity: ERROR
    message: >
      Build SQL with db.query(sql, params). String concatenation or template
      literals with variables enable SQL injection.
    patterns:
      - pattern-either:
          - pattern: db.query(`...${$X}...`)
          - pattern: db.query("..." + $X + "...")

Такі правила пишуться за хвилини, виконуються за секунди і перетворюють урок, засвоєний один раз, на перевірку, що працює завжди.

Промпти про безпеку — корисно, але не можна на них покладатися

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

Але промпт — не контроль. Моделлю можна керувати через шкідливий вміст у контексті — отруєний README, опис задачі, docstring залежності. Це проблема prompt injection, описана у статті про безпеку AI-агентів. Політику реально забезпечують детерміновані перевірки рівнів 2–4.

Ліцензування та походження коду

Безпека — це також юридичні ризики. Деякі вендори пропонують фільтри, що блокують пропозиції, які збігаються з публічним кодом, або показують посилання на джерело. Вмикайте їх для пропрієтарних продуктів, залишайте ліцензійне сканування в CI і зазначайте в описі PR, коли великі блоки коду написав асистент. У регульованих середовищах цей слід походження також допомагає з вимогами аудиту.

Чек-лист для команд

  • Файл інструкцій проєкту містить конкретні правила безпеки для вашого стеку
  • Агенти не можуть встановлювати пакети, ходити в мережу чи читати секрети без погодження
  • Сканування секретів у pre-commit увімкнене в кожного розробника
  • SAST з власними правилами запускається на кожен PR
  • Нові залежності потребують явного погодження людиною
  • Lock-файли й SBOM генеруються та скануються на кожній збірці
  • Кожен маршрут має тест авторизації
  • AI-рев'ю працює з вашою моделлю загроз, а люди все одно погоджують
  • Навчання з безпеки охоплює специфічні ризики AI: надмірну впевненість, вигадані пакети, prompt injection

FAQ

Чи AI-код менш безпечний за людський? Дослідження свідчать, що розробники з асистентами частіше приймають небезпечні патерни і рідше їх помічають. Сам код не обов'язково гірший; гіршим часто є рев'ю навколо нього.

Чи варто заборонити AI-асистентів для критичних модулів? Багато команд забороняють агентам редагувати код авторизації, криптографії й платежів без рев'ю сеньйора. Це розумно. Повна заборона зазвичай заганяє використання в тінь.

Чи нові моделі досі вигадують пакети? Рідше, але не ніколи, а атакувальникам достатньо, щоб це траплялося зрідка. Перевірка дешева — залиште її.

Чи можна доручати AI виправляти вразливості, знайдені сканерами? Так, і для відомих патернів це добре працює. Переглядайте виправлення і додавайте тест, що падав би на вразливій версії.

Джерела

  1. Pearce et al. (2021). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions.
  2. Perry et al. (2023). Do Users Write More Insecure Code with AI Assistants?
  3. Spracklen et al. (2024). We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs.
  4. OWASP. OWASP Top 10:2025 і Top 10 for LLM Applications.
  5. OpenSSF. Scorecard; Google. deps.dev.
  6. Semgrep. Writing rules.