ШІ-асистенти коду перемогли. Битва за безпеку лише починається.

Швидкість впровадження ШІ в розробку програмного забезпечення створила розрив, якого не мало б бути. З одного боку, команди розробки з неймовірною швидкістю взяли на озброєння ШІ-асистентів. З іншого боку, системи безпеки, які мають контролювати цей код, все ще працюють так, ніби кожен рядок був набраний однією людиною з передбачуваною швидкістю. Червневий звіт Salt Security за 2026 рік, "AI Coding Assistants and the New Security Challenge", кількісно оцінює цей розрив у жорстких цифрах і вводить термін, який може визначити наступну еру безпеки додатків: дрейф безпеки.

Парадокс впровадження: швидкі інструменти, повільний контроль

ШІ-асистенти кодування — це вже не експеримент на периферії. Дослідження Salt показало, що 67% організацій повідомляють про широке використання цих інструментів у своїх командах розробки . Компанія прогнозує, що до 2027 року ШІ-генерований код перевищить 50% всього корпоративного коду — це поріг, за яким машинний код стане домінантним джерелом для виробничих систем .

Таке зростання вітали б майже в будь-якому іншому куточку корпоративних технологій. Проблема в тому, що відбувається, коли цей код надходить без адекватної реакції з боку безпеки. 90% керівників служб безпеки сказали Salt, що вони активно занепокоєні ризиками, які несе ШІ-генерований код . Їхнє занепокоєння не абстрактне. Останнє тестування Veracode, на яке посилається звіт Salt, показує, що рівень безпеки для ШІ-генерованого коду становить приблизно 55% — цей показник практично не змінювався протягом двох років. Це означає, що майже половина всього згенерованого коду містить відомі вразливості, коли не надаються чіткі вказівки з безпеки .

Серед опитаних Salt 29% вказали на небезпечні патерни кодування як на головний ризик, а 15% сказали, що основною проблемою є невідповідність внутрішнім політикам безпеки . Обидва страхи походять з однієї й тієї ж причини: ШІ-асистенти навчаються на публічному коді, а не на політиках безпеки конкретної організації, галузевих стандартах чи вимогах комплаєнсу .

Дрейф безпеки: коли ніхто не помічає, що потрапляє в реліз

Звіт вводить поняття "дрейфу безпеки" (security drift) як механізм, що перетворює парадокс впровадження на реальну загрозу. Ідея проста. Організація фіксує свої правила безпеки у вікі, PDF-файлах та корпоративних знаннях, які ШІ-асистент ніколи не читав. Асистент генерує синтаксично правильний і функціонально корисний код, який непомітно порушує ці внутрішні політики. Ніхто цього не помічає, бо процеси перевірки не встигають .

Це підводить Salt до одного з найбільш практичних — і тривожних — висновків про управління. 38% організацій все ще покладаються переважно на ручну перевірку коду, щоб обробити результати роботи ШІ-асистентів. Обсяги ШІ-генерованого коду вже перевищили те, що можуть ефективно перевірити люди, і прогноз Salt на 2027 рік свідчить, що цей розрив лише збільшуватиметься . Лише невелика кількість організацій інтегрувала автоматизовані "бар'єри" безпеки у свої ШІ-робочі процеси .

Рой Еліяху, генеральний директор Salt Security, різко резюмував ситуацію: управління безпекою не встигає за тим, як ШІ-асистенти змінили розробку програмного забезпечення . Традиційні інструменти статичного та динамічного аналізу (SAST/DAST) знаходять проблеми надто пізно в процесі розробки, коли кожне виправлення — це переписування, а кожне переписування — це затримка .

Розрив у сприйнятті METR: повільніше, але відчувається швидше

Управління безпекою — не єдина сфера, де сприйняття та реальність розійшлися. Звіт Salt висвітлює результати зовнішнього дослідження, яке стало точкою відліку в дебатах про інструменти для розробників: рандомізоване контрольоване дослідження METR, опубліковане в липні 2025 року .

У дослідженні взяли участь 16 досвідчених open-source розробників, які виконали 246 реальних завдань у своїх власних зрілих репозиторіях — кодових базах, що в середньому налічують понад мільйон рядків і мають десятки тисяч зірок на GitHub. Учасники були випадковим чином розподілені на тих, хто використовував ШІ-інструменти (переважно Cursor Pro з Claude 3.5/3.7 Sonnet), і тих, хто працював без них .

Головний результат цитувався так часто, що ризикує стати фоновим шумом, але цифри залишаються вражаючими. Розробники, які використовували ШІ, виконували завдання на 19% повільніше, ніж ті, хто працював без будь-якої ШІ-допомоги. Перед дослідженням ті ж розробники прогнозували, що ШІ зробить їх на 24% швидшими. Після виконання завдань вони оцінили, що інструменти зробили їх приблизно на 20% швидшими — хоча об'єктивні вимірювання показали, що вони були повільнішими. Розрив між відчутною та реальною продуктивністю перевищив 39 процентних пунктів .

Висновок METR не означає, що ШІ-інструменти марні — контекст має велике значення. Прискорення спостерігалося в сценаріях адаптації новачків, генерації рутинного шаблонного коду та завдань, з якими розробники менш знайомі. Але для досвідчених інженерів, які працюють над складними, залежними від кодової бази завданнями, дані свідчать, що інструменти можуть створювати тертя (friction), яке розробники свідомо не реєструють .

Salt Code: впровадження правил на рівні запиту, а не на етапі конвеєра

Salt приурочила вихід свого дослідження до запуску продукту, покликаного усунути саме той розрив в управлінні, який описує звіт. 1 червня 2026 року компанія представила Salt Code, новий компонент своєї Агентної Платформи Безпеки (Agentic Security Platform) .

Підхід Salt Code полягає в тому, щоб зупинити дрейф безпеки ще до його початку. Замість сканування ШІ-генерованого коду постфактум, він впроваджує внутрішні політики безпеки та комплаєнсу організації безпосередньо всередину ШІ-асистента в момент генерації коду. Продукт працює з основними інструментами, які стандартизують підприємства: Claude Code, Cursor, GitHub Copilot, Windsurf, Codex та Gemini CLI .

Мета — зробити код, що відповідає політикам, результатом за замовчуванням, а не тим, що потребує подальшого сканування та переписування. Для команд безпеки це забезпечує єдиний рівень політик на етапах створення коду, перевірки в конвеєрі та моніторингу під час виконання — перехід від виявлення помилок до їх запобігання .

Чи зможе Salt Code або подібні інструменти закрити прогалину в управлінні з тією швидкістю, якої вимагає впровадження ШІ, залишається відкритим питанням. Але напрямок руху зрозумілий. Якщо прогноз справдиться — що ШІ писатиме понад половину корпоративного коду протягом півтора року — тоді політика безпеки має переміститися з етапу перевірки на рівень налаштувань за замовчуванням. Альтернативою, як попереджає звіт Salt, є дрейф безпеки в промислових масштабах.