Как успешно внедрить DevSecOps?

Безопасность на протяжении всего жизненного цикла разработки ПО важна, но иногда это сложно.

DevOps помогает преобразовать и ускорить доставку, тестирование и развертывание ПО в производственной среде. Это то самое “обещание DevOps”, которое делает его востребованным. А сейчас оборотов популярности набирает DevSecOps.

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

Что может помешать внедрить DevOps? Причин много, но главная — безопасность. Плохая культура безопасности получается, когда ею занимаются в конце внедрения DevOps. Если подход к безопасности вообще не меняется, это деморализует команду, задерживает проекты и создаёт финансовые проблемы.

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

Процесс DevSecOps

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

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

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

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

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

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

DevSecOps должен выглядеть вот так. Безопасность встроена в цикл доставки и может повторяться каждый раз, когда нужно изменение или корректировка.

Препятствия для DevSecOps

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

Какие у вас могут быть препятствия?

DevSecOps определяет поставщик: это означает, что принципы и процессы сосредоточены на уже готовых решениях, и организация не сможет разработать свой подход. Вместо этого они будут ограничены тем, что предоставляет поставщик.
Нервные менеджеры: страх потерять контроль — настоящая проблема. Часто тревога влияет на принятие решений менеджерами.
“Работает — не трогай”: это нормальное мышление, и вы действительно не можете обвинять людей за такую позицию. Но эту идею стоит оспорить: всегда появляются новые и лучшие методы чего угодно. Чтобы адаптироваться к гибкому жизненному циклу приложения, вам нужно изменить процессы для поддержки необходимой скорости и гибкости.
Эффект Netflix и Uber: обе компании успешно внедрили DevSecOps, поэтому многие организации хотят им подражать. Тут следует задать себе два вопроса: 1) нужно ли это вам и 2) хотите ли вы именно так? Часто ответы будут негативными.
Отсутствие метрик: трансформация DevSecOps должна оцениваться с точки зрения поставленных целей. Метрики могут включать производительность доставки программного обеспечения или общую производительность организации с течением времени.
Безопасность на основе контрольных списков: если вы так делаете — вы используете старый подход. Это бесполезно для современных технологий, которые разработчики используют для упрощения и гибкости доставки. Внедрение подхода “Security as Code” требует, чтобы специалисты по безопасности научились программировать.
Отдельная команда безопасников: это особенно актуально в организациях, переходящих от старых способов доставки ПО. Часто в таких компаниях есть команда безопасности и команда DevOps отдельно. Из-за разделения доверие между разработчиками, администраторами и безопасниками низкое. Это приведёт к тому, что безопасники будут тратить ненужное время на анализ и управление процессами DevOps + строить конвейеры вместо того, чтобы сотрудничать с разработчиками и администраторами для улучшения потока поставки ПО.

Как успешно внедрить DevSecOps

Внедрить DevSecOps непросто, но знание подводных камней — ключ к вашему успеху.

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

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

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

Следующий шаг — метрики. Внедрение DevSecOps нужно измерять по таким параметрам:

время для изменения;
частота развёртывания;
среднее время на восстановление;
ошибки изменений.

Именно эти показатели важны для определения процессов и всего, что можно улучшить. Именно так вы будете понимать, хорош ваш DevSecOps или плох. Эта методология называется event-driven transformation или изменение, движимое событиями.

Вывод

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

Приходим к выводу, что для внедрения DevSecOps нужны: