Top.Mail.Ru
Колонки

DevSecOps в России: как заставить методологию работать «на себя»

Колонки
Дмитрий Бутмалай
Дмитрий Бутмалай

Директор департамента продвижения и развития Rubytech

Ахмед Садулаев

Одной из самых сложных задач интеграций, по мнению директора департамента продвижения и развития Rubytech Дмитрия Бутмалая, является внедрение подразделения информационной безопасности в процесс непрерывной разработки.

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

DevSecOps в России: как заставить методологию работать «на себя»
  1. Колонки

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

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

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

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

 

DevSecOps as is

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

Освободите время и зарабатывайте больше с помощью ИИ! Пройдите курс и получите в подарок лучшие промты для решения бизнес-задач.

Следование этой концепции помогает устранить «пропасть» между подразделениями разработки (Dev), информационной безопасности (Sec) и операционной деятельности (Ops).

https://lh3.googleusercontent.com/rAU81XeeqAaM7pFVR2updhgSiUevgDFTNS98AQUAKPjjRt7SpzrHeeAnJ0qmoFcVc8VM9dGAhH08-cnSfHc11HM6ubYyw4h09ZY5GwNhYl90zxWVTlCQYAhx-25thVtUw_dSigc

Авторы методологии подчеркивают, что важно использовать коллективный опыт для снижения рисков ИБ на каждом этапе разработки программного продукта. Его устойчивость к угрозам (resilient software) возможна только на стыке качества, стабильности и безопасности. Вокруг этого принципа выстраиваются процессы разработки и формируются компетенции команд.

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

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

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

 

Зачем это нужно бизнесу?

Экономия ресурсов

Для многих организаций, в том числе финансовых, основная ценность перехода к DevSecOps заключается не столько в экономии ресурсов, сколько в возможности наиболее быстрого вывода программного продукта на рынок (time-to-market). Разумеется, не в ущерб отказоустойчивости и безопасности. 

Принцип Shift Left («сдвиг влево») в рамках DevSecOps означает, что задачи безопасности перемещаются как можно ближе к началу цикла доставки программного продукта, а сама безопасность становится неотъемлемой частью процесса.

 

Больше обнаружений

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

 

Снижение трудозатрат

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

 

Повышение скорости входа в проект

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

 

Особенности методологии

Infrastructure as Code должна у вас быть

Стоит учитывать, что DevSecOps — не универсальная методология, которая подходит каждой компании для разработки любого программного продукта. Она работает только применительно к определенной архитектуре приложений и использует определенный технологический стек. К примеру, внедрить DevSecOps можно, только применяя подход Infrastructure as Code, который предполагает использование контейнеров в качестве среды исполнения.

 

Внедрение DevSecOps требует существенных ресурсов 

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

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

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

Полный список того, что следует учесть перед внедрением DevSecOps, всегда зависит от особенностей компании, отрасли и продукта. 

Вот лишь примерный перечень проблем, с которыми можно столкнуться:

  • отсутствие необходимых компетенций у сотрудников и нехватка кадров;
  • страх перемен, недостаток поддержки руководства;
  • отсутствие проработанной стратегии;
  • слишком высокие риски не окупить вложения;
  • нехватка финансирования;
  • отсутствие необходимой инфраструктуры.

 

Роль службы ИБ

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

Как правило, из-за специфики своей деятельности наиболее чувствительно к таким переменам подразделение ИБ. Но именно их мотивация станет решающей для внедрения DevSecOps. 

Встроить стратегию внедрения DevSecOps-практик в каждодневную работу команды поможет глубокое понимание угроз и скрытых рисков и того, какое влияние они способны оказать на конечный продукт. Например, если используются Open Source решения, необходимо организовать проверку их на уязвимости в рамках новой системы: аналитики компании в сфере кибербезопасности «Ростелеком-Солар» выявили, что пять из десяти приложений с открытым кодом включают критические уязвимости. 

 

Технологическая база

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

 

Нюансы законодательства

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

Например, к кредитным организациям предъявляется ряд жестких регуляторных требований, касающихся банковской тайны, так что даже для обеспечивающих в другой отрасли достаточный уровень безопасности инструментов DevOps и других решений потребуется проводить аудит ИБ и, возможно, ограничивать их функционал или вовсе отказываться от них. Законодательство может выставлять ограничения на использование отдельных решений — например, в рамках программ по импортозамещению ПО.

 

Команды

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

Комплексный подход к внедрению DevSecOps в компании подразумевает:

  • Готовность топ-менеджмента и исполнителей к организационным изменениям.
  • Инвестиции в автоматизацию процессов разработки, в том числе тестирования безопасности.
  • Понимание принципов разработки.
  • Осознание каждым участником кросс-функциональной команды своей роли.
  • Повышение прозрачности процессов, открытый доступ к ИБ-отчетности.
  • Грамотный выбор и применение ИТ-инструментов DevSecOps.

 

Подводя итоги

Хотя внедрение DevSecOps выглядит весьма сложным и протяженным по времени процессом, помимо существенных затрат и организационных изменений оно влечет за собой ряд заменых выгод для бизнеса. 

Вот лишь главные:

  • Обучение команды разработчиков правилам написания безопасного кода и улучшение продукта за счет изменения культуры разработки. 
  • Уменьшение time-to-market.
  • Снижение затрат на поддержку продукта.
  • Повышение отказоустойчивости продукта.
  • Автоматизация процессов, исключение влияния человеческого фактора.
  • Внутренняя инфраструктурная безопасность облачной среды.

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

Фото на обложке: Pexels

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

ЛАНИТ
Как создать MVP на заказ: cтоимость разработки, выбор подрядчика, этапы и сроки
Подробнее