Почему 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.

Версия той же системы, основанная на ИИ, может предложить больше:

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

Это представляет собой совершенно иной способ работы.

От обнаружения к автономному устранению

Посмотрите, как эта функциональность обычно развивается поэтапно.

Поколение 1: Обнаружение

Инструмент уведомляет человека:

«Существует уязвимость».

Затем инженер приступает к её расследованию.

Поколение 2: Рекомендация

Инструмент идёт дальше:

«Существует уязвимость, вот как её исправить».

Инженер выполняет предложенное решение.

Поколение 3: Устранение проблемы

Инструмент делает ещё один шаг:

«Существует уязвимость. Я уже написал исправление и открыл pull request».

Задача инженера сводится к его проверке.

Поколение 4: Автономный DevSecOps

В конечном итоге, для изменений с достаточно низким уровнем риска, вся цепочка:

Обнаружение → Понимание → Исправление → Тестирование → Подтверждение → Развертывание → Мониторинг

может выполняться практически без участия человека.

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

Цепочка поставок программного обеспечения становится критически важной

Есть ещё одна причина, по которой этот переход имеет такое большое значение.

Современное программное обеспечение редко создаётся полностью с нуля. Вместо этого оно собирается из множества внешних источников: библиотек, взятых из реестров с открытым исходным кодом, API сторонних поставщиков, заранее созданных образов контейнеров, фреймворков приложений, управляемых облачных сервисов, модулей инфраструктуры, которые можно использовать повторно, а также результатов работы инструментов искусственного интеллекта.

Искусственный интеллект значительно ускоряет этот процесс сборки.

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

В результате организации всё чаще нуждаются в ответах на такие вопросы:

Откуда происходит этот код?

Какой ИИ его создал?

Какая версия модели его генерировала?

Какие зависимости он использовал?

Были ли эти зависимости проверены и одобрены?

Какие проверки безопасности над ним были проведены?

Какие правила были применены?

Кто утвердил развертывание?

Что на самом деле работает в производстве сейчас?

Это выносит DevSecOps далеко за рамки простой автоматизации.

Это превращается в систему доверия к программному обеспечению в масштабах всей организации.

Ответственность ИИ становится новым требованием

Эта проблема уже проявляется в опросах отрасли.

Опрос GitLab 2026 года показал, что 80% респондентов заявили, что их организации внедрили инструменты ИИ быстрее, чем смогли разработать соответствующие правила управления, а 92% сообщили о трудностях в управлении, связанных именно с кодом, созданным с помощью ИИ.

Представьте, что аудитор спрашивает:

"Почему этот фрагмент кода имеет доступ к финансовым данным клиентов?"

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

В рабочем процессе агентного разработания честным ответом может стать:

«Это было создано ИИ-агентом для программирования в процессе работы над функцией №4821».

Это открывает целый новый набор вопросов, связанных с управлением.

Какой запрос стал причиной его создания?

К какому контексту у него был доступ?

Была ли добавлена какая-то новая зависимость?

Была ли эта зависимость одобрена к использованию?

Какие тесты на самом деле были выполнены?

Проходила ли какая-либо проверка изменений человеком перед их внедрением?

Какой ИИ-агент безопасности, если таковой существует, его оценивал?

Короче говоря, происхождение ИИ постепенно становится новым обязательным элементом в цепочке поставок программного обеспечения.

Рост платформ 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.

Этот разработчик пишет код.

Коллега его проверяет.

Специалисты по тестированию создают набор тестов.

Отдел безопасности проводит сканирование.

Инженеры DevOps настраивают процесс разработки.

Отдел операций занимается запуском решения.

Всё это может занять дни или недели на завершение.

Завтра

Вместо этого менеджер продукта пишет:

«Позволить авторизованным клиентам замораживать и размораживать карту, фиксировать каждое действие в целях аудита и уведомлять клиента о его совершении».

Инженер берёт эту требование и приступает к его реализации.

В результате получается:

• API
• Изменения в базе данных
• Бизнес-логика
• Тесты на единицу
• Тесты API
• Изменения в инфраструктуре
• Документация

Это может занять всего несколько минут.

Теперь в игру вступает платформа AI DevSecOps.

Он обнаруживает, что ИИ пропустил необходимую проверку авторизации на новом конце точки входа.

Агент безопасности: БЛОКИРОВАТЬ.

Он также выявляет, что недавно добавленная библиотека с открытым исходным кодом имеет критическую известную уязвимость.

Политика цепочки поставок: БЛОКИРОВАТЬ.

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

Проводятся дополнительные тесты.

Агент тестирования: ПРОШЛО.

Платформа подтверждает, что шифрование, логирование и аутентификация настроены корректно.

Политики соответствия: ПРОШЛО.

Приложение отправляется в тестовую среду.

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

Проверка во время работы: ПРОШЛО.

Метод постепенного внедрения направляет небольшую долю, скажем 5%, реального трафика на новую версию.

Показатели наблюдаемости не выявляют ничего необычного.

Нагрузка постепенно увеличивается, пока не достигнет всех пользователей.

Эта функция теперь доступна.

Вся последовательность действий оставляет полную историю аудита:

Требование → ИИ-агент → Код → Зависимости → Тесты → Решения по безопасности → Утверждения → Развертывание → Данные во время работы

Вот так работает AI DevSecOps.

А вот что интересно.

Создание кода на самом деле было самым простым шагом.

Ценным был механизм, способный уверенно отвечать на вопрос:

Готов ли этот программный продукт к внедрению в производство?

Более крупные изменения

В течение длительного времени обсуждения использования ИИ в инженерии программного обеспечения в основном касались одной темы: результатов работы разработчиков.

Насколько быстрее ИИ может сделать тех, кто пишет код?

Этот вопрос начинает казаться слишком ограниченным.

Более важный вопрос заслуживает большего внимания:

Что произойдет, когда разработка программного обеспечения перестанет быть ограниченным ресурсом?

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

Это означает тестирование.

Безопасность.

Управление цепочкой поставок программного обеспечения.

Регулирование.

Автоматическое соблюдение правил.

Автоматизация развертывания.

Наблюдение за системами в рабочем режиме.

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

И, все чаще, решение проблем без ожидания помощи человека.

Все это вместе формирует следующее поколение DevSecOps.

На раннем этапе использования ИИ в инженерии программного обеспечения основная задача заключалась в помощи людям писать код быстрее.

Следующий этап предполагает возможность совместной, безопасной работы людей и ИИ-агентов над всеми этапами создания программного обеспечения.

С такой точки зрения DevSecOps — это не функция, которая выполняется после разработки для уборки последствий.

DevSecOps становится системой управления, на которой функционирует вся ИИ-ориентированная фабрика по разработке программного обеспечения.