Швидкість написання коду за допомогою ШІ зараз перевищує швидкість перевірки безпековими командами. Нове дослідження Linux Foundation, підтримане та участь у якому ActiveState, показує, що 58% команд випускають код швидше, ніж безпекові перевірки можуть за ним поспівати; одночасно 60% опитаних заявили, що допоміжні інструменти ШІ для програмування збільшили кількість зовнішніх пакетів у їхніх кодових базах. Однак команди перевіряють непрямі залежності цих пакетів — тобто «передавані залежності» — лише приблизно в половині випадків.
ActiveState є спонсором та учасником цього нового дослідження. Дослідження підтримується Open Source Security Foundation (OpenSSF) та LF AI & Data Foundation. ActiveState у понеділок оприлюднила результати дослідження «State of AI Impact on Software Security and Cybersecurity 2026». У дослідженні зазначається, що розрив між швидкістю розробки програмного забезпечення за допомогою ШІ та здатністю організацій забезпечити безпеку коду, що виробляється, постійно збільшується.
Дослідження показує, що зі зростанням швидкості генерації коду та виявлення вразливостей завдяки ШІ ці виклики стають все більш терміновими, оскільки організації мають все менше часу для виявлення та усунення проблем до того, як зловмисники використають безпекові недоліки. Вразливість PHP2Shell у жовтні 2026 року підкреслила цю терміновість: протягом кількох годин після розкриття вразливості було опубліковано термінове виправлення та зафіксовано спроби експлуатації. Дослідження стверджує, що зі зростанням швидкості виявлення та експлуатації вразливостей організації під тиском повинні забезпечити, щоб безпекові перевірки, аудит залежностей та виправлення встигали за темпами.
Це дослідження охопило 172 фахівців з безпеки з бізнесу та відкритих проектів. Дослідження також виявило, що ШІ також є частиною рішення, але супроводжується певними компромісами. Респонденти зазначили, що 30% уразливостей, виявлених за останній рік, були виявлені за допомогою інструментів з підтримкою ШІ; 69% опитаних сказали, що ці інструменти значно покращили їхній рівень безпеки. У середньому інструменти ШІ прискорили роботу з безпеки на 17%, але хибні сповіщення про уразливості збільшили навантаження фахівців на 30%, що підкреслює необхідність балансу між ефективністю, що надає ШІ, та ефективним наглядом за безпекою.
Генеральний директор ActiveState Аббі Кернс сказала: «AI-асистенти для програмування — це не просто написання коду, вони також вибирають ваші залежності, і це дослідження показує, що команди перевіряють лише приблизно половину того, що вони отримують. Це збігається з тим, що ми щотижня чуємо від клієнтів. Уповільнення розробників не вирішує проблеми. Розв’язок полягає у визначенні того, що варте довіри, до того, як код потрапить до репозиторію, щоб розробники та їхні AI-інструменти могли починати з компонентів, схвалених командою безпеки».
Інші ключові виявлення включають:
- Навички під загрозою. 82% опитаних згодні, що надмірна залежність від інструментів ШІ ослаблює безпечні навички розробників.
- Турбота перевищує рівень готовності. Для кожної з оцінених загроз, пов’язаних з ШІ, більше фахівців висловили турботу, ніж вважали себе готовими до них. Найбільша різниця — 41 процентний пункт — спостерігається щодо автоматизованого використання вразливостей та фаззінгу з використанням ШІ.
- Ланцюжок постачань займає перше місце у списку занепокоєнь. Атаки на ланцюжок постачань — це найбільше занепокоєння для експертів з безпеки, що становить 93%; далі йде ін’єкція підказок — 90%; і навантаження на підтримку через часті оновлення компонентів — 87%.
- Невизначеність відповідальності. Лише 30% команд мають посади, відповідальні за AI-пов’язані загрози безпеці, і лише приблизно третина команд має офіційну політику безпеки, що охоплює AI.
- Чітке розподілення відповідальності призводить до результатів. У командах із окремими посадами з безпеки ШІ 75% відповіли, що вони добре підготовлені до атак на ШІ-системи, тоді як серед усіх опитаних цей показник становить 50%.
- Ручний контроль не є обов’язковим. Серед команд з політикою безпеки ШІ лише 57% вимагають ручного перевірки коду, згенерованого ШІ.
Дослідження показує, що ці висновки разом вказують на те, що зі зростанням рівня впровадження ШІ необхідно чітко визначити відповідальність за безпеку та посилити управління. Дослідження також зазначає, що створення спеціалізованих посад, розробка чіткої політики та правильне впровадження інструментів пов’язані з вищим рівнем готовності; однак це дослідження не доводить, що саме ці практики призвели до цих розбіжностей.
Лаура Гуаццеллі, архітектор безпеки в OpenSSF, що спеціалізується на AI/ML/LLM/агентних системах, сказала: «Зі зростанням використання ШІ для прискорення розробки програмного забезпечення організаціям потрібно так само обережно керувати та захищати код, що генерується. Це починається з розуміння, на яких етапах ланцюга постачання програмного забезпечення ШІ вносить ризики, визначення відповідальних за вирішення цих ризиків та забезпечення того, щоб практики безпеки відповідали змінам у способах побудови програмного забезпечення».
Звіт рекомендує організаціям призначити відповідальних за безпеку, пов’язану з ШІ, розробити офіційну політику безпеки ШІ та включити до неї ручний аналіз згенерованого коду, а також підсилювати контроль над прямими та непрямими залежностями. На основі цих висновків ActiveState рекомендує впроваджувати управління на етапі введення відкритих компонентів, а не лише під час сканування та перевірки, щоб команди безпеки могли вирішити, які компоненти можуть потрапити до ланцюжка постачання програмного забезпечення, перш ніж розробники або допоміжні системи ШІ їх підтягнуть.
Повний звіт «Стан впливу ШІ на безпеку програмного забезпечення та кібербезпеку до 2026 року» доступний на сайті Linux Foundation і містить висновки дослідження та практичні рекомендації: https://www.linuxfoundation.org/research/ai-impact-on-cybersecurity-2026
Про ActiveState
ActiveState підкреслює, що компанія зобов’язана забезпечити безпеку ланцюжка постачання програмного забезпечення з самого початку в епоху AI-програмування. За допомогою ActiveState Curated Catalog — приватного, перевіреного сховища відкритого коду — команди безпеки можуть вирішувати, які компоненти дозволено вводити до корпоративного програмного забезпечення, перш ніж їх запровадять розробники або AI-помічники з програмування. Компанія стверджує, що це надає командам безпеки контроль, зберігаючи при цьому швидкість розробки інженерних команд. Curated Catalog сумісний із сховищами артефактів, сканерами та AI-помічниками з програмування, які команди вже використовують. Докладніше на activestate.com.
Джерело повідомлення: ActiveState