Комплексная защита при создании программных продуктов может превратиться в барьер, который замедляет выпуск релизов. Однако сложностей можно избежать. О том, как превратить безопасность в драйвер скорости с помощью методологии разработки ПО, объединяющей команды разработки, безопасности и эксплуатации для интеграции проверок безопасности на всех этапах жизненного цикла — DevSecOps, рассказывает IT-World.
При создании защищенных программных продуктов часто возникает конфликт задач. С одной стороны, бизнесу надо быстрее выпустить ПО, поскольку любая задержка стоит денег и грозит потерей клиентов. С другой стороны, отдел безопасности выступает за долгие тщательные проверки. Они замедляют разработку, но без них могут возникнуть проблемы со стороны регуляторов, киберугрозы и утечки данных.
С таким подходом контроль безопасности становится «воротами» в конце каждого цикла разработки. Отправляя программный код на проверку, разработчики сталкиваются с «черным ящиком ожидания». Между тем руководители не понимают, сколько времени займет выпуск очередного релиза. Альтернативой для такой схемы работы может стать методология разработки ПО, объединяющая команды разработки (Dev), безопасности (Sec) и эксплуатации (Ops) для интеграции проверок безопасности на всех этапах жизненного цикла — DevSecOps.
Методология разработки ПО DevSecOps позволяет интегрировать требования безопасности на всех этапах жизненного цикла ПО: от планирования и проектирования до развертывания и мониторинга. Это не просто инструмент, а подход, встроенный в процесс разработки. Одни из основных механик этой методологии — как можно раньше находить уязвимости и заменять ручной контроль автоматизированными проверками кода и конфигураций на каждой стадии. Ключевой принцип DevSecOps — общая ответственность за безопасность. Ее разделяют между собой участники проекта: от разработчиков и DevOps-инженеров до специалистов по ИБ и тестированию.
На практике реализация DevSecOps часто отклоняется от эталонной схемы, потому что компании выбирают модель с контролем безопасности на завершающем этапе. В таких условиях не всегда удается обеспечивать ранний поиск уязвимостей, а у разработчиков и отдела безопасности могут быть разные инструменты автоматизированной проверки, которые не охватывают все этапы жизненного цикла. Как правило, нет и общей ответственности. В результате безопасность продолжает играть роль «ворот», не пропускающих релизы, а разработчики остаются один на один с проблемами, которые лучше решать коллективно. Это удлиняет циклы создания ПО, хотя и обеспечивает требуемый уровень защищенности.
Избежать таких трудностей помогает смена парадигмы, а именно внедрение DevSecOps как сервиса. В этом случае применение требований безопасности превращается из контроля, основанного на запретах, в сервис, который показывает, как лучше защитить ПО и данные. Тогда функции безопасности встраиваются в процесс разработки и становятся такими же доступными, как, например, облачный хостинг или система сборки.
Реализовать DevSecOps как сервис можно за пять основных шагов:
Внедрение DevSecOps как сервиса делает фундаментом процессов концепцию партнерства, что открывает для бизнеса важные преимущества. Благодаря инструментам самообслуживания и автоматизации разработчики могут больше не направлять запросы и не ждать отчеты от службы ИБ. Вместо этого команда сама оперативно получает данные для максимально быстрого устранения уязвимостей. Инструменты проверки интегрируются в среду разработки с самых ранних этапов. Единые правила и механизмы контроля применяются на всем жизненном цикле, а требования информационной безопасности к коду фиксируются уже на стадии проектирования.
В результате формируется культура общей ответственности за результат: служба ИБ организовывает и поддерживает процесс, а команда разработки ему следует, чтобы достичь общей цели. Так вместо конфликта скорости и защищенности появляется их синергия, а качественная безопасность становится драйвером выпуска релизов.
Эффективность DevSecOps как сервиса можно оценить на примере крупной компании, руководство которой решило наладить процессы безопасной разработки. По плану, сформированному аудиторами, организация закупила для этого новые инструменты и внедрила их в CI/CD-процессы. В частности, в разработку были интегрированы средства сканирования кода.
Из-за отсутствия отлаженных процессов и методик нововведение заблокировало выпуск релизов на два месяца, превратив его подготовку в зацикленный процесс. Разработчики направляли программный код на проверку, служба ИБ находила уязвимости и формировала о них отчет, блокируя релиз. Тогда разработчики вносили исправления, базы уязвимостей обновлялись и цикл повторялся снова.
Эксперты выбрали наиболее готовую к изменениям процессов команду, поэтапно обучили в ней разработчиков и представителей службы ИБ правильно взаимодействовать и выстроили их совместные действия, внедрив проверки на каждом из этапов цикла разработки. Разработчики приобрели новые навыки и стали самостоятельно выполнять проверки. Сотрудники службы безопасности больше сконцентрировались на определении правил проверки, помощи с поиском путей и приоритизации устранения уязвимостей, аудите процесса в целом. В результате выпуск релизов возобновился, а закупленные средства проверки кода не были заброшены. Проект показал, что для обеспечения ИБ недостаточно просто внедрить новые инструменты — важны организация процессов и культура безопасной разработки.
Решение о том, стоит ли переходить на DevSecOps как сервис, зависит от особенностей конкретной компании. Чтобы сделать правильный выбор, в первую очередь следует взвесить ценность релиза для бизнеса и риски, которые могут возникнуть в случае выпуска ПО с теми или иными уязвимостями. Если ценность окажется выше рисков, переход к новой методологии будет оптимальным решением.