Российский рынок DevOps-инструментов сменил повестку. Если три года назад разработчики искали, чем заменить ушедший зарубежный сервис, то к 2026 году вопрос звучит иначе: как инструмент встраивается в реальный поток delivery, как снижает шум и не превращает безопасность в тормоз релизов. DevOpsConf 2026 дал редкую возможность посмотреть на этот сдвиг в одном срезе.
От сканеров к управляемому потоку
Продуктовая аллея конференции собрала инструменты четырёх инженерных зон: безопасность разработки, мониторинг и надёжность, Kubernetes и инфраструктура, инструменты разработчика. Ни рейтинга, ни маркетингового глянца - скорее карта болей, вокруг которых сейчас складывается российский DevSecOps-стек.
В сегменте AppSec главный тренд - переход от набора сканеров к процессному слою поверх них. Крупные команды давно закрыли вопрос «какой SAST поставить». Теперь их интересует, как собрать результаты разных инструментов, убрать дубли, назначить ответственных и показать руководителю динамику риска - не раз в квартал, а в режиме постоянного потока.
Что показали на аллее
Несколько продуктов точно попадают в эту логику. Шерлок от Axel PRO позиционируется как единый центр управления AppSec-дефектами: уязвимость получает владельца, статус и прямую связь с задачей в трекере. Не отчёт безопасника - а инженерная задача с маршрутом: исправить, принять риск, отложить или закрыть как false positive.
TRON.ASOC от Ximi Data решает смежную проблему - операционную перегрузку AppSec-инженера. По словам представителя компании на стенде, когда в CI/CD живёт пять-десять инструментов и в каждый нужно заходить вручную, выгружать отчёты и сводить их - это съедает целый рабочий день. Платформа собирает данные через API, агрегирует и дедуплицирует находки, а модель критичности и роли настраиваются под процесс конкретной компании.
CodeScoring закрывает зону supply chain: состав зависимостей, лицензионные риски, транзитивные пакеты. Актуальность этой темы выросла не из моды на open source, а из реальной структуры современного продукта - значительная его часть собирается из внешних библиотек, и уязвимость может приехать не из кода команды, а из того, что подтянул чужой пакет.
Отдельного внимания заслуживает Runtime Radar от Positive Technologies - open source-решение для мониторинга безопасности контейнеров на базе eBPF. Статический анализ образов и манифестов не закрывает поведение в runtime: неожиданный сетевой вызов, запуск shell внутри контейнера, обращение к чувствительному файлу. Runtime Radar наблюдает за этим на уровне ядра и интегрируется с SIEM, чтобы события безопасности не жили в изоляции от общего контура реагирования.
Почему это важно сейчас
За несколько лет российские команды прошли через вынужденное переключение инструментов и теперь, судя по запросам с аллеи, переходят к следующей задаче - зрелости процессов. Инструмент сам по себе не решает, кто принимает риск, что блокирует релиз и чьи SLA на исправление критичных находок. Но без него эти договорённости остаются декларацией.
- ASOC/ASPM-инструменты помогают управлять потоком дефектов, но требуют уже оформленной модели ответственности
- SCA и supply chain security закрывают риски, которые не видны в собственном коде
- Runtime-защита контейнеров - отдельный слой, который статический анализ не заменяет
- Интеграция с трекерами и SIEM переводит безопасность из внешней проверки во встроенную часть delivery
Российский DevOps-рынок, похоже, дорос до вопросов, которые в западных командах обсуждались ещё до пандемии. Опоздание обидное, но динамика - заметная.
