Серед опитаних Salt 29% вказали на небезпечні патерни кодування як на головний ризик, а 15% сказали, що основною проблемою є невідповідність внутрішнім політикам безпеки . Обидва страхи походять з однієї й тієї ж причини: ШІ-асистенти навчаються на публічному коді, а не на політиках безпеки конкретної організації, галузевих стандартах чи вимогах комплаєнсу
.
Звіт вводить поняття "дрейфу безпеки" (security drift) як механізм, що перетворює парадокс впровадження на реальну загрозу. Ідея проста. Організація фіксує свої правила безпеки у вікі, PDF-файлах та корпоративних знаннях, які ШІ-асистент ніколи не читав. Асистент генерує синтаксично правильний і функціонально корисний код, який непомітно порушує ці внутрішні політики. Ніхто цього не помічає, бо процеси перевірки не встигають .
Це підводить Salt до одного з найбільш практичних — і тривожних — висновків про управління. 38% організацій все ще покладаються переважно на ручну перевірку коду, щоб обробити результати роботи ШІ-асистентів. Обсяги ШІ-генерованого коду вже перевищили те, що можуть ефективно перевірити люди, і прогноз Salt на 2027 рік свідчить, що цей розрив лише збільшуватиметься . Лише невелика кількість організацій інтегрувала автоматизовані "бар'єри" безпеки у свої ШІ-робочі процеси
.
Рой Еліяху, генеральний директор Salt Security, різко резюмував ситуацію: управління безпекою не встигає за тим, як ШІ-асистенти змінили розробку програмного забезпечення . Традиційні інструменти статичного та динамічного аналізу (SAST/DAST) знаходять проблеми надто пізно в процесі розробки, коли кожне виправлення — це переписування, а кожне переписування — це затримка
.
Управління безпекою — не єдина сфера, де сприйняття та реальність розійшлися. Звіт Salt висвітлює результати зовнішнього дослідження, яке стало точкою відліку в дебатах про інструменти для розробників: рандомізоване контрольоване дослідження METR, опубліковане в липні 2025 року .
У дослідженні взяли участь 16 досвідчених open-source розробників, які виконали 246 реальних завдань у своїх власних зрілих репозиторіях — кодових базах, що в середньому налічують понад мільйон рядків і мають десятки тисяч зірок на GitHub. Учасники були випадковим чином розподілені на тих, хто використовував ШІ-інструменти (переважно Cursor Pro з Claude 3.5/3.7 Sonnet), і тих, хто працював без них .
Головний результат цитувався так часто, що ризикує стати фоновим шумом, але цифри залишаються вражаючими. Розробники, які використовували ШІ, виконували завдання на 19% повільніше, ніж ті, хто працював без будь-якої ШІ-допомоги. Перед дослідженням ті ж розробники прогнозували, що ШІ зробить їх на 24% швидшими. Після виконання завдань вони оцінили, що інструменти зробили їх приблизно на 20% швидшими — хоча об'єктивні вимірювання показали, що вони були повільнішими. Розрив між відчутною та реальною продуктивністю перевищив 39 процентних пунктів .
Висновок METR не означає, що ШІ-інструменти марні — контекст має велике значення. Прискорення спостерігалося в сценаріях адаптації новачків, генерації рутинного шаблонного коду та завдань, з якими розробники менш знайомі. Але для досвідчених інженерів, які працюють над складними, залежними від кодової бази завданнями, дані свідчать, що інструменти можуть створювати тертя (friction), яке розробники свідомо не реєструють .
Salt приурочила вихід свого дослідження до запуску продукту, покликаного усунути саме той розрив в управлінні, який описує звіт. 1 червня 2026 року компанія представила Salt Code, новий компонент своєї Агентної Платформи Безпеки (Agentic Security Platform) .
Підхід Salt Code полягає в тому, щоб зупинити дрейф безпеки ще до його початку. Замість сканування ШІ-генерованого коду постфактум, він впроваджує внутрішні політики безпеки та комплаєнсу організації безпосередньо всередину ШІ-асистента в момент генерації коду. Продукт працює з основними інструментами, які стандартизують підприємства: Claude Code, Cursor, GitHub Copilot, Windsurf, Codex та Gemini CLI .
Мета — зробити код, що відповідає політикам, результатом за замовчуванням, а не тим, що потребує подальшого сканування та переписування. Для команд безпеки це забезпечує єдиний рівень політик на етапах створення коду, перевірки в конвеєрі та моніторингу під час виконання — перехід від виявлення помилок до їх запобігання .
Чи зможе Salt Code або подібні інструменти закрити прогалину в управлінні з тією швидкістю, якої вимагає впровадження ШІ, залишається відкритим питанням. Але напрямок руху зрозумілий. Якщо прогноз справдиться — що ШІ писатиме понад половину корпоративного коду протягом півтора року — тоді політика безпеки має переміститися з етапу перевірки на рівень налаштувань за замовчуванням. Альтернативою, як попереджає звіт Salt, є дрейф безпеки в промислових масштабах.
Comments
0 comments