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

Эта статья по мотивам моего доклада на UWDC для тех, кто хочет глубже разобраться в DevSecOps и больше узнать про пользу, которую он может принести. Поговорим о том, как находить баланс между технологиями и людьми, достигать результата, и, главное, какие ошибки проще предотвращать, чем потом исправлять.

Меня зовут Павел, я руководитель направления Professional Services в Orion soft. Мы занимаемся экспертным аудитом и решением сложных задач, а Orion soft производит программное обеспечение для инфраструктурного слоя, в том числе контейнеризации и виртуализации (Nova и zVirt). Мы тоже не сразу пришли к DevSecOps и поломали немало граблей, поэтому мне есть чем поделиться.

Концепция DevSecOps

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

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

Гармоничное развитие — ключевой фактор успеха. Люди должны быть готовы к внедрению новых технологий. Иначе прыжок из ИТ «каменного века» может стать очень дорогим и медленным. И тут не обойтись без экспертной помощи. Иначе можно просто прыгнуть в другую сторону: потерять время, ресурсы, деньги и не достигнуть результата.

Модель «трёх тел»: Dev, Sec, Ops

Если мы разделим аббревиатуру DevSecOps на три части, то получим взаимодействующие сущности: Dev (разработка), Sec (безопасность) и Ops (эксплуатация). У каждой из них свои задачи, цели и приоритеты.

• Dev отвечает за развитие продукта, скорость вывода новых функций и достижение бизнес-целей. Для разработчиков главное — быстро двигаться вперед, реализовывать новые идеи и KPI.

• Ops (операционка) фокусируется на стабильности, надежности и контроле. Их задача, чтобы всё работало, системы были предсказуемы, а инфраструктура — устойчива.

• Sec (безопасность) заботится о минимизации рисков, оценке угроз и соблюдении требований ИБ. Для них важно, чтобы новые изменения не несли уязвимостей и не ставили под угрозу бизнес.

Эти три стороны часто смотрят на одни и те же процессы по-разному. Если между ними нет согласия и совместной работы, бизнес буквально «не поедет», как в басне Крылова. «Лебедь», «рак» и «щука» тянут телегу в разные стороны, и результат — остановка или даже движение назад. Дорогие для компании ресурсы впустую «молотят воздух».

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

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

Этапы развития инфраструктуры и процессов

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

1. Инвентаризация

Первый шаг — понять, что у вас есть. Необходимо описать инфраструктуру, выявить все её компоненты и ввести единые правила работы с ними. Без этого внутри вашей структуры возникает хаос, когда никто не понимает, за что отвечает и какие ресурсы используются.

2. Мониторинг и контроль

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

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

3. Разделение и сегментация

По мере роста инфраструктуры важно обеспечить её изоляцию и сегментацию. Помните про архитектуру Zero Trust («ноль доверия») — не доверять никому и ничему по умолчанию, даже если пользователь или сервис уже внутри периметра сети. Это снижает риски: потеря одной части не приводит к потере всего. Такой подход позволяет лучше контролировать векторы атак и минимизировать потенциальный ущерб. Со времен Римской империи мало что изменилось — «Divide et impera» (Разделяй и властвуй!).

4. Геораспределение

Когда бизнес предъявляет требования к отказоустойчивости и доступности, возникает задача географического распределения сервисов. Но невозможно абсолютно всё вывести на «четыре девятки». Поэтому нужно определить, какие сервисы более критичны для бизнеса, а какие — менее, и распределить их по разным ЦОДам или облакам для повышения надежности.

5. Автоматизация

С накоплением рутинных процессов следует переходить к автоматизации: внедрять шаблоны, GitOps-практики, автоматизированные пайплайны. Это высвобождает время специалистов и снижает вероятность человеческих ошибок.

Сегодня уже говорят о «GitOps 2.0» — расширении принципов GitOps за счет политики как кода для управления инфраструктурой. Это означает, что помимо хранения конфигураций в Git, компании внедряют автоматическую проверку соответствия изменений заданным политикам прямо в CI/CD. Такой подход гарантирует единообразие настроек и соблюдение требований безопасности на всех средах.

Еще один важный тренд — platform engineering: создание внутренних self-service платформ для разработчиков. Описываемая в статье автоматизация развертываний «по кнопке» — это часть более широкой концепции платформенной инженерии, набирающей популярность, цель которой — предоставить командам удобные инструменты для быстрого и безопасного деплоя.

К слову о GitOps 2.0, у нас в Orion soft скоро выходит новый продукт — автоматизированная платформа HyperDrive, построенная по этой концепции. Следите за анонсами :)

6. Внедрение защитных инструментов

На этом этапе важно выбрать и внедрить средства защиты, исходя из критичности сервисов и потенциальных векторов атак на вашу инфраструктуру. Например, WAF (Web Application Firewall) для веб-сервисов или инструменты сканирования кода и контейнерной безопасности.

7. Проактивное управление

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

Проактивность достигается в том числе за счет ML-инструментов, которые анализируют поведение систем и пользователей для выявления угроз, не описанных заранее правилами. Например, решения на основе ИИ умеют выявлять нетипичные отклонения в сетевом трафике или активности аккаунтов и тем самым сигнализировать о потенциальной атаке. Более того, машинное обучение применяется для предсказания уязвимостей: на основе данных о прошлых инцидентах системы прогнозируют, какие узкие места в коде наиболее рискуют быть эксплуатированы, и позволяют устранить их заблаговременно.

8. Тренды и импортозамещение

Регулярно следите за трендами, посещайте профильные конференции, анализируйте опыт коллег и формируйте свою карту развития IT-сервисов с учетом новых технологий и требований импортозамещения.

1. Внедрение ИИ и МО. Сейчас активно используются решения с искусственным интеллектом для автоматизации безопасности. ИИ способен в режиме реального времени сканировать код и среды на уязвимости, сокращая ручной труд и ускоряя обнаружение проблем. ИИ применяется в мониторинге и реагировании на инциденты: аналитику угроз, корреляции событий и даже автоматизацию первичных шагов реагирования (SOAR).

2. Архитектура Zero Trust. Подход нулевого доверия стал де-факто стандартом для защиты современных распределённых систем. Суть Zero Trust — не доверять ничему и никому по умолчанию, проверяя каждое соединение и запрос. В контексте DevSecOps это означает, что при проектировании инфраструктуры закладываются принципы минимальных привилегий, строгой аутентификации и сегментации сетей.

3. Безопасность цепочки поставок (SLSA и SBOM). Отдельным трендом последних лет стала защита software supply chain – всего конвейера от разработки до деплоя. Первое, SLSA (Supply Chain Levels for Software Artifacts), это многоуровневый стандарт обеспечения целостности ПО. Его цель — снизить риск компрометации ПО посредством набора практик и требований к процессу сборки и поставки кода. Второе, SBOM (Software Bill of Materials), перечень компонентов и зависимостей каждого приложения, даёт прозрачность в том, из чего “собрано” ПО, и упрощает управление уязвимостями и соответствие требованиям.

4. Комплаенс как код. Современный DevSecOps все чаще включает практики Compliance-as-Code. Это когда требования безопасности и нормативные правила (например, стандарты ФСТЭК или ISO) описываются в виде кода и автоматических проверок, и соблюдение комплаенса контролируется непрерывно, наравне с качеством кода. В частности, при инфраструктурном GitOps 2.0 подходе политики (Policy as Code) интегрируются в пайплайны.

5. Импортонезависимые инструменты. К 2025 году в России уже сформировался достаточно зрелый стек решений, позволяющий заменить небезопасные продукты и построить инфраструктуру без зависимостей от зарубежного ПО.

9. Сервисная модель

Это как вишенка на торте! Высшая цель — предоставление внешних и внутренних IT-услуг «по кнопке» без необходимости ручного вмешательства и долгих согласований. Это позволяет быстро и удобно разворачивать нужные сервисы для бизнеса и разработки.

Такой подход сейчас как раз и является ключевой целью platform engineering: многие компании создают внутренние платформы самообслуживания, где разработчики и бизнес могут сами быстро развернуть нужные ресурсы. Индустрия движется к тому, чтобы внутренняя инфраструктура работала как безопасный сервис для команд разработки.

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

Болевые точки и ошибки

Проблемы на пути к DevSecOps у всех примерно похожи. Поэтому выделю основные.

Отсутствие культуры сотрудничества

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

Недостаточная автоматизация

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

Разрозненность политик и стандартов

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

Отсутствие регулярной оценки и улучшения процессов

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

Осознание и системная работа с этими болевыми точками — необходимое условие для построения эффективных, безопасных и устойчивых процессов в современной IT-инфраструктуре.

С процессов мы и начнем разбирать, как избегать подобных ошибок.

Практические рекомендации

Чтобы построить зрелый и эффективный DevSecOps-процесс, важно не только осознавать типовые ошибки, но и внедрять конкретные меры, которые помогают их избегать.

Ответственность за безопасность

Безопасность — это не отдельная зона ответственности, только для специалистов по ИБ. Первое, что нужно сделать — донести до всех участников процесса, что за безопасность ответственны все. Каждый от бизнеса до разработчиков должен думать о рисках и учитывать их на своем этапе работы. Внедряйте культуру общей ответственности: обсуждайте вопросы безопасности на всех уровнях и при каждом изменении.

• Бизнес должен думать о дополнительных рисках, когда приносит задачу.

• Разработчик на этапе формирования ТЗ понимать, какие продукты будет использовать и какие там «дырявые» библиотеки.

• В начале каждого цикла разработки (спринта) приглашайте коллег из ИБ, чтобы они были в процессе, приносили свою экспертизу и обсуждали задачи.

Автоматизируйте проверки

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

Современные средства статического анализа уже используют элементы машинного обучения для снижения числа ложных срабатываний и более точного нахождения уязвимостей. Анализ конфигураций и инфраструктурного кода с помощью policy-as-code дополняет автоматические проверки безопасности. Следует не просто автоматизировать проверки, но и применять умные инструменты, которые учатся на выявленных инцидентах и постоянно улучшают качество процессов DevSecOps.

Регулярная коммуникация и ретроспективы

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

Фикс уязвимостей

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

Инфраструктурные меры

Изоляция prod/dev: Строго разделяйте контуры разработки, тестирования и продакшена. Не используйте реальные данные в тестах, либо обфусцируйте их, чтобы минимизировать риски утечек.

Если бизнес-подразделения сопротивляются и настаивают «тестировать на проде», то коллег можно переубедить. Обычно достаточно разложить всё с точки зрения рисков и потерь персональных данных. Пересчитать активности в деньги и принести «цифру». Тогда не останется варианта, кроме выделения дополнительных ресурсов или пересмотра параметров всего проекта. Потому что, например, за утечку персональных данных в продакшен сейчас можно получить оборотные штрафы. Подобные риски должны оцениваться и приниматься на уровне бизнеса. 

Хранение секретов: Используйте специализированные инструменты для хранения и управления секретами. Не допускайте хранения паролей в коде или на рабочем столе. Помните про мем — «стикер с паролем от компьютера на мониторе». Используйте сертификаты для раздельных контуров и не стесняйтесь их перевыписывать — Safety First.

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

Набирающий популярность способ гарантировать целостность — это когда каждая сборка сопровождается «списком материалов» (SBOM) — перечнем всех включенных библиотек и зависимостей. Это позволяет автоматически отслеживать уязвимости в компонентах и выполнять проверку артефактов перед выпуском.

Fail-fast в пайплайнах: Настройте Security Gates: автоматическое прерывание конвейеров при обнаружении критических ошибок или большого количества уязвимостей. Это позволит быстро реагировать и не допускать попадания проблемных сборок в продакшен.

Стройте универсальные пайплайны для всех сред (Prod, Test, Dev), чтобы процессы были прозрачными и легко масштабировались вместе с ростом бизнеса. Используйте единый репозиторий кода (например, GitLab) как источник правды для всех команд.

Концепция «Shift-Left»

Она давно вышла за рамки разработки программного обеспечения и применяется во многих областях. Ее суть проста: чем раньше вы начинаете заниматься вопросами безопасности (и качества в целом), тем дешевле и проще исправлять ошибки. Исправление уязвимости на этапе проектирования — в разы дешевле, чем её устранение на проде.

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

Мы делаем так

В Orion soft мы выстраиваем DevSecOps-процессы для наших заказчиков, опираясь на свой стек продуктов и совместимые решения партнеров.

Для управления секретами, сертификатами и ключами мы используем нашу контейнерную платформу Nova, StarVault как ядро хранения и NeuVector как модуль безопасности. Это позволяет централизованно и безопасно хранить чувствительные данные для всех сред — от разработки до продакшена.

В качестве примера внедрения у заказчиков, могу привести следующий кейс. Мы развернули пайплайн для микросервисного приложения. Технически он выглядит как интернет-магазин, построенный на классическом стеке. В качестве ключевых Open Source-технологий использовали GitLab, для автоматизации CI/CD, Nexus для управления артефактами и Docker для контейнеризации. Для обеспечения информационной безопасности взяли стек Positive Technologies, так как он уже был внедрен у заказчика и легко интегрировался с нашими процессами.

Мы сделали «деплой по кнопке за 15 минут». Конечно, на этапе выхода на продакшен для страховки остаются ручные merge-запросы и согласования от ключевых разработчиков и ИБ, но сам процесс максимально автоматизирован и прозрачен.

Особое внимание уделяли тому, чтобы все ключевые статусы процесса DevSecOps и отчёты были доступны сразу в трёх консолях: GitLab, Positive Technologies и Nova. Это позволило быстрее реагировать на инциденты и поддерживать необходимый уровень безопасности на всех этапах жизненного цикла приложения.

Мы всем своим коллегам рекомендуем работать в GitLab. Это становится единой точкой правды, коммуникации и взаимодействия. В пайплайне проходят автоматические сканы кода и образов, результаты которых сразу видны всем участникам. Коллеги из ИБ могут настраивать политики, отслеживать статусы и получать отчеты на почту, либо прямо в интерфейсе GitLab. Это как раз пример реализации подхода, когда правила безопасности интегрированы в инструменты разработчиков. Благодаря такой интеграции платформа фактически реализует принципы Policy-as-Code\Compliance as Code для всех участников процесса.

Таким образом, более 80% вопросов по статусу жизненного цикла приложения и безопасности решаются через GitLab. Это экономит время и снижает количество недопониманий.

Для более глубокого контроля комплаенса и состояния сервисов мы используем консоль Nova. Она развернута у нас в качестве основы инфраструктуры. По сути, это «кубер на максималках». Помимо стандартного Kubernetes, Nova включает в себя встроенные стеки мониторинга, логирования и безопасности. Особое внимание мы уделяем интеграции платформы безопасности на решении NeuVector:

• обеспечивается сканирование образов, контейнеров, построение сетевых карт и контроль комплаенса;

• вся информация выводится в едином дашборде, что удобно для анализа и быстрой реакции на инциденты.

В консоль Nova чаще заходят DevOps-инженеры и лиды разработки, чтобы следить за метриками потребления ресурсов и состоянием сервисов. И если «что-то идёт не так» это сразу видно по метрикам и алертам.

Заключение

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

Стремитесь к тому, чтобы безопасность была не отдельной функцией, а частью ДНК вашей команды. Вовлекайте специалистов по ИБ на всех этапах, автоматизируйте рутинные проверки, не откладывайте фиксы уязвимостей и регулярно обсуждайте, что можно сделать лучше. Старайтесь строить процессы так, чтобы основная инфраструктура и сервисы работали по принципу «по кнопке». Это позволит быстрее реагировать на запросы бизнеса. Эволюция DevSecOps продолжится внедрением интеллектуальных инструментов и новых практик: для сохранения баланса «скорость–стабильность–безопасность» командам предстоит освоить AI-помощников в разработке, zero-trust подход в архитектуре и повышать прозрачность.

Напоследок, поздравляю всех с наступающим 2026 годом! Пусть в новом году все баги остаются только в тестах, а инфраструктура работает как часы :)

И помните: DevSecOps — это не конечная точка, а путь постоянного развития и поиска баланса между скоростью, стабильностью и безопасностью. Чем чаще вы будете собирать обратную связь и корректировать свои процессы, тем ближе окажетесь к зрелой, эффективной и безопасной IT-инфраструктуре.