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

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

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

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

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

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

DevSecOps as is

Как правило, идеология 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 в компании.