Если совершенно случайно в вашей работе возникают критические ошибки на проде, которые исправляются слишком долго. А еще, возможно, специалисты по безопасности начинают выявлять уязвимости только после релиза. Или вдруг в команде используются ручные проверки, например: сборки кода выгружаются вручную, а ИБ их «бесконечно долго» сканируют и отдают вместе со своим рукописным отчетом.
Эта статья по мотивам моего доклада на 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-сервисов с учетом новых технологий и требований импортозамещения.
-
Внедрение ИИ и МО. Сейчас активно используются решения с искусственным интеллектом для автоматизации безопасности. ИИ способен в режиме реального времени сканировать код и среды на уязвимости, сокращая ручной труд и ускоряя обнаружение проблем. ИИ применяется в мониторинге и реагировании на инциденты: аналитику угроз, корреляции событий и даже автоматизацию первичных шагов реагирования (SOAR).
-
Архитектура Zero Trust. Подход нулевого доверия стал де-факто стандартом для защиты современных распределённых систем. Суть Zero Trust — не доверять ничему и никому по умолчанию, проверяя каждое соединение и запрос. В контексте DevSecOps это означает, что при проектировании инфраструктуры закладываются принципы минимальных привилегий, строгой аутентификации и сегментации сетей.
-
Безопасность цепочки поставок (SLSA и SBOM). Отдельным трендом последних лет стала защита software supply chain – всего конвейера от разработки до деплоя. Первое, SLSA (Supply Chain Levels for Software Artifacts), это многоуровневый стандарт обеспечения целостности ПО. Его цель — снизить риск компрометации ПО посредством набора практик и требований к процессу сборки и поставки кода. Второе, SBOM (Software Bill of Materials), перечень компонентов и зависимостей каждого приложения, даёт прозрачность в том, из чего “собрано” ПО, и упрощает управление уязвимостями и соответствие требованиям.
-
Комплаенс как код. Современный DevSecOps все чаще включает практики Compliance-as-Code. Это когда требования безопасности и нормативные правила (например, стандарты ФСТЭК или ISO) описываются в виде кода и автоматических проверок, и соблюдение комплаенса контролируется непрерывно, наравне с качеством кода. В частности, при инфраструктурном GitOps 2.0 подходе политики (Policy as Code) интегрируются в пайплайны.
-
Импортонезависимые инструменты. К 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-CodeCompliance as Code для всех участников процесса.
Таким образом, более 80% вопросов по статусу жизненного цикла приложения и безопасности решаются через GitLab. Это экономит время и снижает количество недопониманий.
Для более глубокого контроля комплаенса и состояния сервисов мы используем консоль Nova. Она развернута у нас в качестве основы инфраструктуры. По сути, это «кубер на максималках». Помимо стандартного Kubernetes, Nova включает в себя встроенные стеки мониторинга, логирования и безопасности. Особое внимание мы уделяем интеграции платформы безопасности на решении NeuVector:
-
обеспечивается сканирование образов, контейнеров, построение сетевых карт и контроль комплаенса;
-
вся информация выводится в едином дашборде, что удобно для анализа и быстрой реакции на инциденты.
В консоль Nova чаще заходят DevOps-инженеры и лиды разработки, чтобы следить за метриками потребления ресурсов и состоянием сервисов. И если «что-то идёт не так» это сразу видно по метрикам и алертам.
Заключение
Конечно, как я уже говорил, что идеальной формулы для решения задачи трех тел — нет. Всё, что мы можем, это в моменте собирать обратную связь процесса и постоянно искать компромисс. И чем чаще и лучше мы будем взаимодействовать во всех трех доменах DevSecOps, чем больше будем общаться между собой, тем лучше нам будет жить.
Стремитесь к тому, чтобы безопасность была не отдельной функцией, а частью ДНК вашей команды. Вовлекайте специалистов по ИБ на всех этапах, автоматизируйте рутинные проверки, не откладывайте фиксы уязвимостей и регулярно обсуждайте, что можно сделать лучше. Старайтесь строить процессы так, чтобы основная инфраструктура и сервисы работали по принципу «по кнопке». Это позволит быстрее реагировать на запросы бизнеса. Эволюция DevSecOps продолжится внедрением интеллектуальных инструментов и новых практик: для сохранения баланса «скорость–стабильность–безопасность» командам предстоит освоить AI-помощников в разработке, zero-trust подход в архитектуре и повышать прозрачность.
Напоследок, поздравляю всех с наступающим 2026 годом! Пусть в новом году все баги остаются только в тестах, а инфраструктура работает как часы :)
И помните: DevSecOps — это не конечная точка, а путь постоянного развития и поиска баланса между скоростью, стабильностью и безопасностью. Чем чаще вы будете собирать обратную связь и корректировать свои процессы, тем ближе окажетесь к зрелой, эффективной и безопасной IT-инфраструктуре.
Автор: h1000h500
