Чому DevSecOps стає новою перешкодою в епоху програмування з використанням ШІ

Коротко кажучи: Протягом десятиліть однією з найдорожчих складових розробки програмного забезпечення було саме написання коду. Інженери мусили перетворювати вимоги на архітектуру, створювати тисячі рядків коду, виявляти помилки, писати тести, поєднувати системи та нарешті запускати все в експлуатацію. Генеративний ШІ змінює цю ситуацію. Сьогодні розробник може просто описати свої потреби простою мовою, і ШІ-агент для програмування створить значну частину фактичної реалізації — API, запити SQL, набори тестів, інфраструктуру у вигляді коду, документацію, скрипти міграції, іноді навіть цілі додатки. Це вже не якийсь маргінальний експеримент. Дослідження Google DORA 2025 показало, що 90% опитаних фахівців у сфері технологій вже використовують ШІ у своїй щоденній роботі, а понад 80% зазначили, що це підвищує їхню продуктивність. Але є одна умова, яку варто врахувати: як тільки створено

Програмне забезпечення стає значно дешевшим, тож перевірка такого програмного забезпечення набуває ще більшої важливості. Більше створеного коду означає більшу кількість елементів для тестування. Більше використовуваних залежностей означає більшу вразливість через ланцюг постачання. Більше розроблених додатків означає необхідність керування більшою інфраструктурою. Більше випусків означає більшу кількість змін, які потрапляють у продакшн. А більше коду, створеного за допомогою ШІ, породжує більше відкритих питань щодо його походження, безпеки, відповідності стандартам та особи, відповідальної за нього. Тож наступна справжня віха у інженерії програмного забезпечення може взагалі не бути пов’язана з кодуванням за допомогою ШІ — це може бути ШІ-орієнтований DevSecOps: автоматизований механізм довіри, який стоїть між кодом, створеним ШІ, та системами, що працюють у продакшні.

Текуща ситуація: ШІ атакує «вузьке місце» у кодуванні

Класичний процес інженерії програмного забезпечення зазвичай виглядав так:

Вимоги → Проектування → Кодування → Тестування → Забезпечення безпеки → Розгортання → Експлуатація

Протягом більшої частини цієї історії саме написання коду займало більшу частину зусиль.

Створення нового API вручну могло зайняти у розробника кілька днів.

Тепер розробник може натомість дати вказівки ШІ-агенту наступним чином:

"Створіть REST API для приваблення нових клієнтів на Python. Включіть перевірку вхідних даних, шар зберігання, автентифікацію, модулі тестування, Dockerfile та маніфести розгортання."

Агент може виконати значну частину цієї роботи протягом кількох хвилин.

Це фундаментальна зміна в економіці створення програмного забезпечення.

Витрати на створення ще однієї функції, ще одного сервісу чи ще одного додатку постійно знижуються.

І сфера застосування ШІ більше не обмежується автодоповненням коду — вона поширюється на агентську поведінку: парсинг цілих репозиторіїв, редагування кількох файлів одночасно, виконання наборів тестів, виправлення проблем та самостійне створення запитів на з’єднання коду.

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

Проте швидше написання коду не означає автоматично швидшої розробки програмного забезпечення.

Саме ця прогалина є ключовою.

Ми переміщуємо вузьке місце

100 змін у програмному забезпеченні щотижня.

Їхні конвеєри тестування, перевірки безпеки та інфраструктура розгортання були створені саме для обробки приблизно такого навантаження.

Тепер додаймо до цього штучних інтелектуальних агентів.

Розробники раптово працюють набагато швидше, а кількість результатів щотижня зростає до:

300 змін у програмному забезпеченні.

Це величезний стрибок у потужності кодування.

Але тепер:

300 змін потребують перевірки коду.

300 змін потребують тестування.

300 змін потребують підтвердження безпеки.

300 змін можуть ввести нові залежності.

300 змін потрібно перевірити за правилами.

300 змін потребують рішення щодо розгортання.

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

Обмеження не зникло — воно лише перемістилося.

Старе питання було таким:

Чи можемо ми створювати програмне забезпечення достатньо швидко?

Нове запитання таке:

Чи можемо ми достатньо швидко перевіряти та безпечно запускати програмне забезпечення?

DORA описує вплив ШІ як дію підсилювача — він посилює будь-які існуючі інженерні практики, незалежно від їх якості. Їхні дослідження свідчать про те, що ШІ може прискорити процес розробки, водночас виявляючи слабкі місця в системах, які не були створені для такої швидкості.

Це інше формулювання має величезне значення.

Нове рівняння інженерії програмного забезпечення

Простіше кажучи, схема розвитку виглядає приблизно так: впровадження ШІ спричиняє зростання кількості коду, що, у свою чергу, призводить до збільшення кількості змін, які проходять через процес розробки. Це вимагає значно більшої кількості перевірок, що спонукає команди до більшої автоматизації, а це, у кінцевому підсумку, змушує організації інвестувати більше у розробку платформ.

Або, у скороченому вигляді:

Написання коду стає дешевшим. Довіра до нього — ось що має цінність.

Саме тому DevSecOps буде набувати все більшої важливості, оскільки розробка за допомогою ШІ стає нормою, а не залишатиметься на другому плані.

Що саме таке DevSecOps?

Легко звести DevSecOps до формулювання „під’єднати сканер безпеки до вашого процесу CI/CD“, але це не відображає всього спектру його функцій.

DevSecOps значно ширший за це.

У своїй суті він поєднує:

Розробку + Безпеку + Операції

в один безперервний процес доставки.

Повний процес DevSecOps зазвичай включає:

Контроль версій

Код відстеження, гілки, комітти, запити на з’єднання та історія змін з часом.

Якість коду

Перевірка форматування, статичний аналіз, перевірка архітектури та оцінка здатності до підтримки.

SAST

Статичне тестування безпеки додатків перевіряє вихідний код на наявність проблем з безпекою.

Виявлення конфіденційної інформації

Пошук паролів, ключів API, сертифікатів чи токенів, які випадково були додані до репозиторію.

SCA

Аналіз складу програмного забезпечення виявляє ризиковані чи вразливі залежності від сторонніх компонентів.

SBOM

Список компонентів програмного забезпечення відображає всі елементи, які входять до складу додатку.

Безпека IaC

Засоби сканування, які аналізують код Terraform, CloudFormation, Kubernetes та подібні інфраструктурні файли.

Безпека контейнерів

Перевірка зображень контейнерів на наявність вразливих пакетів операційної системи, застарілих бібліотек та неправильно налаштованих елементів.

Тестування

Юніт-тести, інтеграційні тести, тести на регресію, API-тести, тести продуктивності, а також все більше тестів, створених за допомогою ШІ, які підтверджують правильність функціонування.

Політика та відповідність

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

CI/CD

Після схвалення програмне забезпечення створюється, пакується та розгортається в різних середовищах.

Розгортання

Стратегії розгортання, такі як канаркові випуски, розгортання типу «синє/зелене» та флаги функцій, визначають спосіб потрапляння коду у продакшн.

Безпека під час виконання та можливості моніторингу

Діючі додатки постійно перевіряються на наявність вразливостей, атак, збоїв, незвичайної поведінки та зниження продуктивності.

Уся ця система стає ще більш важливою, оскільки машини виконують все більшу частку справжнього програмування.

ШІ також змінює DevSecOps

Існує ще один аспект цієї зміни, який варто розглянути.

DevSecOps не лише буде обробляти більшу кількість коду, написаного за допомогою ШІ.

Сам DevSecOps стає системою, керованою ШІ.

Наразі типовий сканер може позначити щось на кшталт:

Виявлена критична вразливість у залежності X.

Версія цієї ж системи, оснащена ШІ, може зробити більше:

Виявлена критична вразливість. Ось чому це важливо. Ось шлях коду, який постраждав. Ось рекомендована версія. Я створив виправлення. Я пройшов тести на регресію. Ось запит на пул-реквест.

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

Подивіться, як ця можливість зазвичай розвивається етапами.

Інструмент попереджає людину:

«Існує вразливість».

Інженер починає ретельне дослідження.

Генерація 2: Рекомендація

Інструмент йде далі:

«Існує вразливість, і ось як її виправити».

Інженер впроваджує запропоноване рішення.

Генерація 3: Усунення

Інструмент робить ще один крок:

«Існує вразливість. Я вже написав код для її усунення та створив запит на з’єднання коду».

Завданням інженера стає перевірка цього коду.

Генерація 4: Автономний DevSecOps

Зрештою, для змін із достатньо низьким рівнем ризику, вся ланцюгова процедура:

Виявлення → Розуміння → Усунення → Тестування → Перевірка → Розгортання → Моніторинг

може виконуватися майже без участі людини.

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

Ланцюг постачання програмного забезпечення стає критичним

Існує ще одна причина, чому ця трансформація має таке велике значення.

Сучасне програмне забезпечення рідко створюється повністю з нуля. Натомість його складають з багатьох зовнішніх джерел: бібліотек, отриманих з реєстрів відкритого коду, API сторонніх компаній, готових образів контейнерів, фреймворків додатків, керованих хмарних послуг, модулів інфраструктури, які можна використовувати знову, а також результатів роботи інструментів ШІ.

ШІ значно прискорює цей процес складання.

Дослідження Sonatype за 2026 рік щодо ланцюгів постачання програмного забезпечення описує екосистему як ту, що наближається до машинного масштабу, вказуючи на автоматизоване створення продуктів, розширення діаграм залежностей та штучних інтелектуальних агентів, які роблять походження та надійність ще важливішими, ніж будь-коли.

У результаті організації все більше потребують відповідей на такі запитання:

Звідки походить цей код?

Який штучний інтелект його створив?

Яка версія моделі його генерувала?

Які залежності він використовував?

Чи були ці залежності перевірені та схвалені?

Які заходи безпеки були застосовані до нього?

Які правила були використані?

Хто схвалив його розгортання?

Що насправді працює у продакшені зараз?

Це виводить DevSecOps далеко за межі простої автоматизації.

Це перетворюється на систему довіри до програмного забезпечення в масштабах всієї компанії.

Відповідальність ШІ стає новою вимогою

Ця проблема вже проявляється у дослідженнях галузі.

Дослідження GitLab 2026 року показало, що 80% респондентів зазначили, що їхні організації впровадили інструменти ШІ швидше, ніж вони змогли розробити відповідні правила управління, а 92% повідомили про труднощі управління, пов’язані саме з кодом, створеним за допомогою ШІ.

"Чому цей фрагмент коду має доступ до фінансових даних клієнтів?"

Раніше можна було просто вказати відповідального розробника.

У робочому процесі з агентним розробленням чесною відповіддю може бути:

«Його створив агент для програмування на основі ШІ під час роботи над функцією №4821.»

Це відкриває цілу низку нових питань щодо управління.

Який запит спричинив його створення?

До якого контексту він мав доступ?

Чи була додана нова залежність?

Чи схвалена була ця залежність для використання?

Які тести насправді були проведені?

Чи хтось із людей переглянув зміни перед їх об’єднанням?

Який агент безпеки ШІ, якщо взагалі є, оцінив його?

Kortше кажучи, походження ШІ поступово стає новим обов’язковим елементом у ланцюзі постачання програмного забезпечення.

Підйом платформ AI DevSecOps

Сьогодні компанії зазвичай використовують набір несумісних інструментів, щось на кшталт:

Розробник → GitHub → Jenkins → SonarQube → Snyk → Artifactory → Kubernetes → Datadog → ServiceNow

Кожен інструмент вирішує певну частину робочого процесу.

Штучний інтелект робить цю фрагментацію значно дорожчою, адже агенти потребують можливості бачити всю історію життя проекту, щоб бути корисними.

Агент ШІ, який усуває проблеми під час роботи системи, може потребувати доступу до:

• Оригінальних вимог
• Вихідного коду
• Історії змін
• Результатів тестування
• Даних про вразливості
• Історії розгортання
• Конфігурації інфраструктури
• Журналів роботи
• Даних телеметрії з системи
• Записів про попередні інциденти

Саме ця потреба спонукає ринок до використання єдиних інженерних платформ.

Gartner вже включає інженерію платформ та інженерію платформ з використанням технологій GenAI до ключових трендів у інженерії програмного забезпечення, прогнозуючи, що до 2027 року 70% організацій, які мають команди з розробки платформ, вбудують функції GenAI у свої внутрішні платформи для розробників.

DORA також підкреслює цей момент: якість платформи суттєво впливає на те, чи дійсно впровадження ШІ покращує продуктивність організації, чи, навпаки, створює „хаос у наступних етапах“.

Куди зміщується цінність

Ця зміна має серйозні наслідки для всієї технологічної індустрії.

Під час першої хвилі ажіотажу навколо генеративного ШІ більша частина уваги була зосереджена на одному питанні:

Який асистент для програмування найкращий?

Це питання залишається актуальним.

Але разом з ним постає ще більш важливе питання для корпорацій:

Хто контролює процес переходу від ідеї, створеної ШІ, до надійного програмного забезпечення?

Саме в цьому процесі зараз концентрується величезна цінність. Розгляньмо всі етапи:

Кодування за допомогою ШІ

Інструменти на кшталт Copilot, Claude Code, Cursor та інші подібні засоби.

↓

Джерело коду та співпраця

Платформи такі як GitHub, GitLab та Bitbucket.

↓

Безпека

SAST, SCA, сканування конфіденційних даних, безпека контейнерів та безпека ланцюга постачання.

↓

Керування артефактами

Пакети, контейнери та записи про походження.

↓

CI/CD

Автоматизоване створення, тестування та розгортання.

↓

Хмарні платформи

Інфраструктура та середовища виконання.

↓

Оперативне спостереження

Журнали, метрики, трекінг, інциденти та дані про роботу в продакшені.

↓

Управління

Політики, схвалення, записи аудиту та документація щодо дотримання правил.

Та платформа, яка зможе об’єднати всі ці елементи, стане надзвичайно важливою з стратегічної точки зору.

Майбутнє: розробники стають оркеструвальниками

Це зовсім не означає, що роль розробника зникне.

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

Більшість розробників наразі присвячують більшу частину свого часу написанню логіки реалізації.

У майбутньому це зміниться на виконання ролі оркеструвальника інтелектуальних систем.

Замість того, щоб казати машині:

Напиши цю функцію.

інженер буде частіше казати:

Створи цю можливість.

Штучний інтелект бере на себе завдання з реалізації.

Увага людини спрямовується на оцінку архітектурних рішень, бізнес-правил та ризиків.

Агенти з безпеки шукають слабкі місця.

Агенти з тестування перевіряють, чи правильна поведінка системи.

Агенти з розгортання керують процесом впровадження.

Агенти з моніторингу стежать за системою під час її функціонування.

Все частіше завданням людини є керування системою в цілому, а не її поступове складання.

Gartner також зробив подібне прогнозування, описавши, як розробники будуть переходити до оркестрації, формулювання проблем, проектування систем та перевірки того, чи результати, отримані за допомогою ШІ, справді відповідають стандартам якості.

Інженери DevSecOps також змінюються

Функції DevSecOps також змінюються в подібному напрямку.

Традиційно ця робота полягала у:

• Створенні конвеєрів обробки даних
• Підтримці Jenkins
• Налаштуванні сканерів

Керування скриптами розгортання

Усунення проблем у середовищах

Це все частіше означає такі речі:

• Проектування платформ, які забезпечують доставку програмного забезпечення від початку до кінця
• Створення правил, від яких залежить вся організація
• Написання правил безпеки, яких мають дотримуватися агенти
• Контроль за тим, що можуть робити автономні агенти для кодування
• Розробка систем, які автоматично вирішують проблеми, замість того щоб чекати на людину
• Відстеження того, звідки насправді походить кожен елемент програмного забезпечення
• Створення спільних шаблонів, які команди можуть використовувати знову, замість того щоб починати з нуля
• Оцінка рівня інженерних ризиків, з якими стикається організація
• Забезпечення надійної роботи автономних систем доставки

Іншими словами:

Робота у сфері DevSecOps більше не полягає у підтримці працездатності процесів розробки, а стосується створення шару керування, який регулює програмне забезпечення, створене за допомогою ШІ.

Зміни в безпеці: від контрольно-пропускних пунктів до захисних бар’єрів

У більшості організацій сьогодні безпека функціонує як контрольний пункт.

Розробники завершують роботу над чимось.

Безпека перевіряє це.

З’являється проблема.

Розробники її виправляють.

Безпека знову перевіряє.

Такий постійний обмін стає непрактичним, коли ШІ значно прискорює процес розробки порівняно з минулим.

Модель, яка його замінює, виглядає більш так:

Політика → Автоматизація → Постійне застосування

Команди з безпеки один раз формулюють правила.

Платформа потім постійно застосовує ці правила, не чекаючи на підтвердження від людини щоразу.

Ось як це відбувається.

Правило: Жоден API, відкритий для інтернету, не може обійтися без автентифікації.

Агент ШІ поставляє API без цієї перевірки.

Платформа DevSecOps негайно це помічає.

Розгортання автоматично блокується.

Агенту з кодування повідомляють точну причину.

Агент з кодування виправляє API.

Тести запускаються знову.

Правило безпеки тепер дотримується.

Розгортання продовжується.

Жодна людина з команди безпеки не переглядала це вручну.

Проте правила дотримувалися на кожному етапі процесу.

Ось справжня перевага DevSecOps на основі ШІ.

Чому компанії можуть витрачати більше на DevSecOps, а не менше

Легко припустити, що ШІ дозволить компаніям обійтися меншою кількістю інструментів та меншими витратами на інженерну інфраструктуру.

У критичних частинах стеку більш ймовірним є протилежне.

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

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

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

У попередніх дослідженнях DevSecOps від GitLab вже було виявлено, що фахівці з безпеки стурбовані тим, що код, створений за допомогою ШІ, збільшить їхню роботу, а дослідження 2026 року вказує на те, що вони називають „парадоксом ефективності ШІ“ — ситуацію, коли швидке створення коду у поєднанні з непов’язаними інструментами може створити нові перешкоди на пізніх етапах робочого процесу.

Тож економіка починає відходити від:

Оплати працівникам переважно за створення коду

і рухатися до:

Оплати платформ, які можуть безпечно керувати величезним обсягом програмного забезпечення.

Простий приклад

Ось конкретне ілюстрування.

Дозволити клієнтам заморозити свою кредитну картку через мобільний додаток.

Вчора

Менеджер продукту складає вимоги.

Розробник проектує API.

Цей розробник пише код.

Колега перевіряє його.

Відділ QA створює набір тестів.

Відділ безпеки проводить сканування.

DevOps формує цілісну систему обробки.

Відділ операцій керує процесом впровадження.

Усе це може зайняти дні чи тижні для завершення.

Завтра

Натомість менеджер продукту пише:

"Нехай автентифіковані клієнти могли заморожувати та розморожувати картку, фіксувати кожну дію для аудиту та повідомляти клієнта про це."

Інженер бере цю вимогу та працює над її реалізацією.

Це призводить до створення:

• API
• Змін у базі даних
• Бізнес-логіки
• Тестів на одиницю
• Тестів API
• Змін у інфраструктурі
• Документації

Це може зайняти кілька хвилин.

Тепер вступає в дію платформа AI DevSecOps.

Він виявляє, що ШІ пропустив необхідну перевірку авторизації на новому кінцевому пункті.

Агент безпеки: БЛОКУВАТИ.

Він також виявляє, що нещодавно додана бібліотека з відкритим кодом має критичну відому вразливість.

Політика ланцюга постачання: БЛОКУВАТИ.

Агент з кодування замінює її на більш безпечну залежність.

Тести виконуються ще раз.

Агент тестування: ПРОХОДИТЬ.

Платформа підтверджує, що шифрування, облік та автентифікація налаштовані належним чином.

Політики відповідності: ПРОХОДИТЬ.

Додаток надсилається до тестового середовища.

Проти нього виконуються синтетичні транзакції для імітації реального використання.

Перевірка під час роботи: ПРОХОДИТЬ.

Метод поступового впровадження надсилає невелику частину, наприклад 5%, реального трафіку до нової версії.

Показники спостережуваності не виявляють нічого незвичайного у кількості помилок.

Обсяг трафіку поступово збільшується, поки не досягне всіх користувачів.

Ця функція вже доступна.

Уся послідовність залишає повний запис аудиту:

Вимога → Штучний інтелект → Код → Залежності → Тести → Рішення щодо безпеки → Схвалення → Розгортання → Докази під час роботи

Ось так працює AI DevSecOps.

А ось що цікаво.

Створення коду насправді було найпростішим кроком.

Найціннішим був механізм, здатний впевнено відповісти на таке питання:

Чи справді цей програмний продукт готовий до використання у промислових умовах?

Більша зміна

Протягом тривалого часу обговорення ШІ в інженерії програмного забезпечення переважно стосувалися однієї речі: результатів роботи розробників.

Наскільки швидше ШІ може допомогти тим, хто пише код?

Це питання починає здаватися занадто обмеженим.

Більше питання заслуговує на більшу увагу:

Що станеться, коли розробка програмного забезпечення перестане бути дефіцитним ресурсом?

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

Це означає тестування.

Безпеку.

Керування ланцюгом постачання програмного забезпечення.

Управління.

Автоматичне застосування правил.

Автоматизацію розгортання.

Спостереження за системами у режимі роботи.

Відстеження того, звідки насправді походить робота, створена за допомогою ШІ.

І, все частіше, вирішення проблем без очікування на людину.

Разом усе це становить наступне покоління DevSecOps.

Рання стадія використання ШІ у інженерії програмного забезпечення переважно стосувалася допомоги людям у швидшому написанні коду.

Наступна стадія полягає у можливості для людей та агентів ШІ спільно, безпечно керувати цілими заводами з розробки програмного забезпечення.

Якщо дивитися з цієї точки зору, DevSecOps — це не функція, яка діє після розробки та прибирає наслідки її роботи.

DevSecOps стає платформою керування, на якій працює весь завод з розробки програмного забезпечення, керований ШІ.