Новые стандарты DevSecOps и GitLab +5


Довольно много дебатов ведется относительно того, какой термин более правилен: DevSecOps, SecDevOps, или же вообще "sec" часть этого термина является лишней. В компании GitLab мы выработали довольно четкую точку зрения: принципы DevSecOps позиционируют безопасность как центровой концепт разработки и цикла DevOps, где им собственно и самое место. Мы считаем, что вопросы безопасности должны оставаться прозрачной и как можно более стандартизированной частью процесса, они не должны быть спрятаны или где-то глубоко захоронены. Автоматизация процессов и политик позволяет вооружить как разработчиков, так и профессионалов ИБ, нужной им информацией для выполнения своих обязанностей.

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

GitLab уже сегодня является катализатором изменений во всем, что касается эволюции DevSecOps в сравнении с более традиционными инструментами тестированием безопасности приложений. Давайте разберемся, из чего же собственно состоит эта эволюция.

Тестирование безопасности

Традиционные инструменты: Тестирование выполняется специалистами ИБ с использованием собственных инструментов, как правило, в конце цикла разработки.

Новые возможности GitLab: Тестирование автоматизировано за счет конвейеров Continuous Integration, а результаты становятся доступны разработчику до завершения текущей итерации. 

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

Непрерывная интеграция и безопасность

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

Новые возможности GitLab: Возможности объединены в один инструмент, не требуют дорогостоящей интеграции и обслуживания; требуют только одной лицензии.

Устранение уязвимостей

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

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

С технической стороны вопроса, GitLab был одним из первых вендоров собравших в одном инструменте большое количество сканеров:

  • SAST

  • DAST

  • Сканирование зависимостей

  • Сканирование контейнеров

  • Secrets Detection

  • Fuzz testing

  • Сканирование и анализ лицензий

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

Благодаря всем этим усилиям и полученным результатам, GitLab был в 2021 году включен в Gartner Magic Quadrant for Application Security Testing за полноту планов и способности их воплощения. Мы считаем, что это только подтверждает нашу веру в то, что будущее DevSecOps - в вовлечении разработчиков в процессы ИБ и вооружении их адекватными инструментами. 

Надо отметить также, что мы не останавливаемся на достигнутом и продолжаем активно инвестировать в улучшение компонентов продукта, связанных с понижением рисков и повышением уровня безопасность программных продуктов. Вот только некоторые улучшения, которые были добавлены в GitLab за последние 6 месяцев (с момента, когда мы были включены в квадрант Gartner):

После множества последних атак (например, SolarWinds и последующей атаки на газопровод в США), внимание специалистов становится все более чаще привлекается к вопросам обеспечения безопасности приложений.

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

Если же вам интересно узнать на практике, как работают решения ИБ в контекста GitLab, как мы на практике реализуем работу с уязвимостями и автоматизируем процессы их обнаружения, а также обсудить нашу дорожную карту, приглашаем посеть GitLab Security Virtual Workshop (на английском языке) 27 октября. Регистрация уже открыта!




К сожалению, не доступен сервер mySQL