Как работает DevSecOps: принципы, этапы, инструменты
DevOps
-
Что такое DevSecOps? Это не что иное, как методология DevOps с акцентом на реализацию процессов и внедрение контролей безопасности в процессы разработки ПО.
Конечно, методология DevSecOps имеет свои отличительные особенности, но тем не менее DevOps является началом/предтечей.
Всё началось с Agile — методики, которая привнесла итеративность в процесс разработки. Если ранее в случае типичного «водопада» релизный цикл сервиса мог составлять месяцы/кварталы/годы, то сейчас речь идёт о днях/неделях. Любая, даже небольшая новая фича или несколько небольших баг-фиксов могут породить новый релиз.
Для того чтобы выдержать такую скорость разработки, модель эксплуатации тоже должна поменяться: больше нельзя содержать отдельную OPS-команду, которая не знает, из чего состоит проект, и работает отдельно от команды разработки. Здесь произошло рождение DevOps, методологии, которая подразумевает сближение команд эксплуатации и разработки и объединение навыков, процессов и инструментов обеих команд.
Всё началось с Agile — методики, которая привнесла итеративность в процесс разработки. Если ранее в случае типичного «водопада» релизный цикл сервиса мог составлять месяцы/кварталы/годы, то сейчас речь идёт о днях/неделях. Любая, даже небольшая новая фича или несколько небольших баг-фиксов могут породить новый релиз.
Для того чтобы выдержать такую скорость разработки, модель эксплуатации тоже должна поменяться: больше нельзя содержать отдельную OPS-команду, которая не знает, из чего состоит проект, и работает отдельно от команды разработки. Здесь произошло рождение DevOps, методологии, которая подразумевает сближение команд эксплуатации и разработки и объединение навыков, процессов и инструментов обеих команд.
DevOps-подход предполагает соблюдение некоторых принципов:
- Культура: эксплуатация и разработка выступают единой командой, отвечающей за качество конечного продукта, поэтому работают сообща.
- Автоматизация: все процессы, относящиеся к DevOps: сборка, тестирование, релиз, — максимально автоматизированы и не зависят от человеческого фактора.
- Бережливость: процессы оптимизации, улучшения и совершенствования всегда являются частью бэклога команды эксплуатации.
- Измерение: все процессы обязаны иметь свои метрики для оценки качества и зрелости для принятия взвешенных решений об их улучшениях.
- Обмен: применение общих инструментов и лучших практик усиливает доверие и уровень коммуникации между командами.
Преимущества использования DevOps-практик:
- Отказоустойчивость: DevOps помогает компаниям проектировать и внедрять отказоустойчивые системы.
- Гибкость: в условиях постоянно меняющегося ландшафта технологий бизнес должен оставаться гибким и быстрым, DevOps помогает в этом.
- Скорость: DevOps позволяет выводить продукты на рынок / релизить быстрее.
- Надёжность: DevOps снижает частоту сбоев и обеспечивает оперативную обратную связь.
- DevOps — это набор практик для сокращения времени между произведённым коммитом в репозиторий и выкаткой сервиса в производственное окружение, с соблюдением необходимого уровня качества.
Методология DevOps циклична в сравнении с классическим «водопадом», в котором работа заканчивается с очередным релизом.
Жизненный цикл DevOps состоит из восьми стадий:
- Планирование (формирование спринта из задач в бэклоге).
- Разработка.
- Сборка/публикация артефакта.
- Автоматическое тестирование перед влитием в общую ветку.
- Публикация готовой новой версии сервиса; развёртывание в т. н. препродуктовой среде, финальные тесты.
- Развёртывание (автоматический релиз новой версии сервиса).
- Эксплуатация (ИТ-инфраструктура должна быть развёрнута и настроена для выполнения и публикации сервиса).
- Наблюдение (автоматические уведомления в случае инцидентов).
Так выглядит современный цикл разработки
Теперь вернёмся к моделям выстраивания подходов к реализации процессов безопасности в разных методиках разработки. Как выглядел подход проверки кода/сервиса, когда разработка велась по «водопаду»? Специалисты по информационной безопасности выполняли ряд проверок перед релизом нового сервиса в продуктивную среду. То есть, по сути, в самом конце цикла разработки. При этом в случае, если были найдены какие-либо проблемы, разработка сервиса могла откатиться назад аж до стадии проработки архитектуры, поскольку проблемы могли найтись, например, в процессе авторизации. Как вы понимаете, данный подход, когда ИБ стоит с «жезлом» перед выкладкой сервиса в продуктивную среду, не является оптимальным, хотя был частью нашей реальности совсем недавно.
DevSecOps и отличия от DevOps
В тот момент, когда появилась методология DevOps, основные практики DevSecOps и были изменены принципы и подходы к реализации процессов разработки, ИБ не могло оставаться в стороне, также продолжая разрывать цепочку разработки.
Agile привёл команды разработки к быстрым релизам, вплоть до нескольких в день. Здесь кроется проблема: как команде информационной безопасности проверить все эти релизы? Ведь каждый релиз может содержать потенциальные проблемы безопасности, которые, если не обрабатываются вовремя, могут плодиться в геометрической прогрессии.
Agile привёл команды разработки к быстрым релизам, вплоть до нескольких в день. Здесь кроется проблема: как команде информационной безопасности проверить все эти релизы? Ведь каждый релиз может содержать потенциальные проблемы безопасности, которые, если не обрабатываются вовремя, могут плодиться в геометрической прогрессии.
«Вы что, хотите сказать, мы должны делать пентест для каждого релиза? Нас же двое!» — возразил бы наш безопасник, не знающий про DevSecOps.
И дело не в том количестве людей, которое он назвал. Сколько бы он ни назвал, этого количества AppSec-инженеров (именно они, как правило, ответственны за обеспечение безопасности продукта) всегда мало в соотношении с количеством разработчиков. В разных источниках можно найти соотношение 100: 1 или 500: 1, очевидно в пользу разработчиков.
Ответ на вопрос нашего виртуального возмущённого безопасника: «И да, и нет».
Мы точно должны найти способ, как анализировать каждый релиз, возможно выполняя какие-то простые проверки безопасности в пайплайнах сборки/деплоя, и вместе с тем реализовать процесс, при котором проводим необходимо проводить ручные и более сложные проверки циклично, выбирая периодичность одним из следующих способов:
Ответ на вопрос нашего виртуального возмущённого безопасника: «И да, и нет».
Мы точно должны найти способ, как анализировать каждый релиз, возможно выполняя какие-то простые проверки безопасности в пайплайнах сборки/деплоя, и вместе с тем реализовать процесс, при котором проводим необходимо проводить ручные и более сложные проверки циклично, выбирая периодичность одним из следующих способов:
- раз в N месяцев / раз в квартал;
- каждый мажорный релиз;
- каждый минорный релиз, в котором изменены функции безопасности.
Тут мы наконец всё ближе от проблем разработки и методологии DevOps переходим к DevSecOps. Но позвольте последнюю ремарку: почему мы всё же так много внимания уделили DevOps? Дело в том, что DevOps по определению содержит тему обеспечения безопасности в части эксплуатации (Operations). Однако индустрия безопасности настояла на внесении бОльшего количества акцентов на теме безопасности, исходя из чего родилось отдельное направление, которое впоследствии стало носить аббревиатуру DevSecOps.
- DevSecOps (Development, Security, Operations) — методология, акцентирующая внимание на обеспечении безопасности продукта на всём жизненном цикле его разработки и эксплуатации.
При этом, как и в случае с DevOps, DevSecOps цикличен, не имеет чёткого конца и начала и, как ни странно, наследовал те же восемь этапов жизненного цикла, однако подразумевая на этих этапах собственный набор контролей и процессов.
Чтобы решить проблемы, возникающие в головах виртуальных возмущённых безопасников («разработка ускорилась, релизы участились -> необходимо чаще выполнять проверки, чтобы не допускать критических проблем безопасности в продуктивной среде -> нас, AppSec-инженеров, больше не стало -> мы не сможем делать пентест каждого релиза»), обратим внимание на техники и практики, на которых основывается DevSecOps:
Чтобы решить проблемы, возникающие в головах виртуальных возмущённых безопасников («разработка ускорилась, релизы участились -> необходимо чаще выполнять проверки, чтобы не допускать критических проблем безопасности в продуктивной среде -> нас, AppSec-инженеров, больше не стало -> мы не сможем делать пентест каждого релиза»), обратим внимание на техники и практики, на которых основывается DevSecOps:
1
Shift Security Left: использовать CI/CD для внедрения проверок/контролей безопасности на более ранних стадиях жизненного цикла разработки. Вместо внедрения проверок безопасности в конце цикла разработки необходимо внедрять проверки на как можно более ранних этапах.
2
Self Service: автоматизировать всё, что поддаётся автоматизации, для как можно меньшего участия команды безопасности в проверках/контролях. Это также подразумевает более осознанное отношение к безопасности со стороны команд разработки и эксплуатации, поскольку их участие в некоторых процессах безопасности неминуемо.
3
Security Champions: поощрять инициативы разработчиков; делегировать на них задачи безопасности, например задачи по триажу (обработке файндингов от сканеров).
4
Everything as Code: реализация процессов харденинга, комплаенса и любых других задач безопасности, подразумевающих конфигурирование или сохранение состояния, с помощью кода — в форматах yaml, toml, json. Здесь есть как минимум два преимущества:
- переиспользование конфигураций;
- применение практик работы с репозиториями: версионирование, хранение истории, содержание информации об авторе, изменения через MR/PR (Merge request / Pull request).
5
Secure by Default: использование сервисов, инструментов и фреймворков, которые закрывают те или иные риски по умолчанию.
6
DevSecOps Maturity Model: использование фреймворков для оценки зрелости внедряемых практик. Есть известный всюду DSOMM, также есть российский фреймворк, включающий все те же практики, — DAF (DevSecOps Assessment Framework). На него, кстати, мы и будем опираться в том числе.
Данные практики позволят решить задачу проведения анализа каждого релиза, не увеличивая в разы количество AppSec-инженеров:
- те проверки безопасности, которые можно сдвинуть «влево», сдвигаем, встраивая в пайплайны разработки;
- автоматизируем все процессы, которые поддаются автоматизации;
- выстраиваем взаимоотношения с разработчиками / командой эксплуатации, пересматривая зоны ответственности в части выполнения задач безопасности и перекладывая ответственность за выполнение некоторых задач на них.
Почему у вас должно получиться пересмотреть зоны ответственности? Необходимо пропагандировать внутри компании подход, при котором об обеспечении безопасности думают не только люди, работающие в отделе информационной безопасности, а все, кто причастен к разработке или эксплуатации продукта. Представьте картинку, когда 100 человек плодят потенциальные проблемы безопасности, совершенно не задумываясь о безопасности, и лишь один пытается что-то исправить.
Безопасность — это неотъемлемая часть качества продукта.
Поэтому любой разработчик, пишущий код с необходимым уровнем качества, обязан задумываться в том числе, например, об использовании безопасных библиотек. А если необходимо реализовать функцию безопасности, авторизации или оплаты, должен пройти архитектурное ревью AppSec-специалиста. Это необходимо, чтобы снизить риски безопасности, а также чтобы снять единоличную ответственность за потенциальные проблемы, которые могут привести к утечке данных или отказу в обслуживании, что грозит снижением лояльности пользователей сервиса и, как следствие, приведёт в лучшем случае к финансовым санкциям для того же разработчика.
Информационная безопасность начинает работать и приносить позитивный эффект, когда становится частью культуры в компании.
Как упоминалось выше, жизненный цикл DevSecOps точно повторяет DevOps с внедрением своих практик/контролей на каждой стадии. Вот как он выглядит:
Разберём основные практики информационной безопасности по стадиям ЖЦ ПО:
1
Планирование — внедрение средств для анализа рисков (например, threat dragon от OWASP).
2
Разработка — внедрение статического анализа (SAST) на разных стадиях разработки: pre-commit/pre-receive / пуш в feature-ветку / создание MR / push в master / создание релиза.
3
Сборка/публикация артефакта — композиционный анализ кода/артефакта (SCA); подпись артефакта.
4
Тестирование — динамический анализ сервиса, развёрнутого на тестовом стенде (DAST).
5
Релиз — возможны любые вышеперечисленные проверки ИБ, а также внедрение механизма автоматической проверки соответствия текущего релиза политике ИБ компании (Security Quality Gate).
6
Развёртывание — проверка контекста информационной безопасности: привилегии пользователя в контейнере, происхождение артефакта, доступные привилегии (capabilities) и другие.
7
Эксплуатация — динамический анализ сервиса; настроенное логирование.
8
Наблюдение — настроенные механизмы корреляции для выявления и предотвращения аномалий в продуктивной среде.
- SSDLC (Secure Software Development Life Cycle) — это более высокоуровневый фреймворк, описывающий, какие практики информационной безопасности должны быть внедрены на каждом этапе процесса разработки.
То есть в классическом SSDLC на стадии «планирования» необходимо формализовать требования к информационной безопасности исходя из функциональных особенностей разрабатываемого продукта, а также пройти архитектурное ревью от команды безопасности ещё до того, как будет написана хоть одна строчка кода. Больше процессной составляющей.
Цель SSDLC — минимизация рисков ИБ. Соответственно, DevSecOps для SSDLC — это набор практик и инструментов для реализации контролей информационной безопасности.
Цель SSDLC — минимизация рисков ИБ. Соответственно, DevSecOps для SSDLC — это набор практик и инструментов для реализации контролей информационной безопасности.
Иными словами, SSDLC отвечает на вопрос «Что?», а DevSecOps — «Как?». Ведь практики ИБ можно встроить и без методологии DevSecOps. Но мы сюда не пойдём.
Реализация практик безопасности
А теперь наконец главная новость на сегодня: поздравляю, вы — новоиспечённый DevSecOps-инженер в компании ООО «Прекрасный E-COM», которая занимается разработкой приложения для доставки non-food-товаров по всей России. Компания бурно развивается и теперь нуждается в том числе в специалисте, который поможет интегрировать практики информационной безопасности в процессы разработки компании. На данный момент в компании 300 разработчиков, написан уже не один десяток микросервисов, в основном на Go. Разработчики, как водится, пьют смузи, живут по Agile, лишь редкие Senior-инженеры что-то слышали о безопасности, единичные активисты сами приходят с вопросами «А можно ли нам использовать какую-то интересную библиотеку?». CI/CD-конвейер настроен, но в нём нет проверок безопасности.
Есть небольшой отдел информационной безопасности, в котором три человека отвечают за продуктовую безопасность, будем их называть AppSec-инженерами, и теперь вы — как человек, который поможет в автоматизации процессов безопасной разработки.
До вашего прихода AppSec-инженеры выстроили свою работу следующим образом:
Есть небольшой отдел информационной безопасности, в котором три человека отвечают за продуктовую безопасность, будем их называть AppSec-инженерами, и теперь вы — как человек, который поможет в автоматизации процессов безопасной разработки.
До вашего прихода AppSec-инженеры выстроили свою работу следующим образом:
- разбились по бизнес-вертикалям, чтобы каждый нёс ответственность за свой пул сервисов. К вашему приходу каждый из них отвечал уже за 10+ сервисов;
- работа каждого AppSec-инженера сводилась к проведению архитектурных ревью, консультациям команд разработки и выполнению ручных аудитов;
- AppSec-инженеры понимали также, что большой пласт рисков кроется именно в коде сервисов, однако ни анализировать регулярно с какой-то периодичностью, ни тем более анализировать каждый релиз они не могли. Поэтому инструментальный анализ с помощью различных сканеров проводился только в момент проведения ручного аудита.
Компания переживает экспоненциальный рост, количество микросервисов и команд разработки растёт, AppSec-специалисты всё меньше сервисов могут проаудировать, вследствие чего CISO компании принимает решение о том, что необходимо внедрять автоматизацию в AppSec-процессы, и нанимает вас.
Более того, CISO, зная, что эффективность внедрённых DevSecOps-практик необходимо проверять и иметь возможность оценить со временем уровень зрелости процессов, даёт задачу:
Более того, CISO, зная, что эффективность внедрённых DevSecOps-практик необходимо проверять и иметь возможность оценить со временем уровень зрелости процессов, даёт задачу:
- Внедрить все базовые инструменты и процессы DevSecOps, придя по всем доменам и практикам к базовому уровню зрелости по фреймворку DAF.
- Помочь AppSec-инженерам привести процессы безопасности разработки к соответствию стандарту ГОСТ Р 56 939−2024. Фактически компании не нужно проходить сертификацию ФСТЭК, однако CISO посчитал набор требований из этого стандарта отличным чек-листом для оценки процессов безопасности приложений.
DAF
- DAF (DevSecOps Assessment Framework) — это фреймворк, описывающий, что и в какой последовательности необходимо реализовать для построения процессов безопасной разработки в компании.
Есть огромное множество фреймворков и стандартов, в основном зарубежных, описывающих, что необходимо делать для обеспечения безопасности в процессе разработки. DAF объединяет практики и контроли некоторых из них (BSIMM, OWASP SAMM, DSOMM), а также ГОСТ 56939-2024 в один большой список, разделённый на домены, поддомены и практики. При заполнении списка практик (заполняя, указываем: Выполняется / Частично выполняется / Не выполняется / Не применимо) мы можем увидеть, какие домены и поддомены реализуются, какой процент практик выполнен в поддомене, какие поддомены к каким уровням зрелости практик информационной безопасности относятся.
DAF представляет из себя excel-документ с тремя важными для нас листами:
- «Практики» — содержит чек-лист со списком практик, который необходимо заполнить. В данном чек-листе практики разбиты на домены и поддомены. Также для каждой практики указано соответствие пунктам известного зарубежного или российского фреймворка/стандарта. Данная страница является входной точкой для заполнения.
- «Результаты аудита» — показывает, какой процент практик выполнен в каждом поддомене, домене и в целом по всему фреймворку.
- «Пирамида зрелости (т.н. Кириллиамида)» — показывает соответствие каждого поддомена и уровню зрелости процессов безопасной разработки в компании. Данная таблица поможет ответить на вопрос «С чего начать?» и сформирует перечень процессов/инструментов, которые должны быть внедрены для соответствия определённому уровню зрелости.
Итоги
- DevSecOps — это не отдельная методология, а развитие DevOps с интеграцией безопасности на всех этапах жизненного цикла разработки.
- Безопасность должна смещаться «влево» — внедряться как можно раньше в процесс разработки и не ограничиваться проверками приложения в конце его разработки.
- Автоматизация и Self-Service позволяют масштабировать безопасность без увеличения числа специалистов по ИБ.
- Каждый участник процесса разработки: разработчик, тестировщик, DevOps-инженер — несёт ответственность за безопасность продукта.
- DevSecOps отвечает на вопрос «Как внедрить безопасность?», в то время как SSDLC определяет «что внедрять».
- Оценка зрелости процессов безопасности по фреймворкам, таким как DAF, помогает системно выстраивать и измерять прогресс в DevSecOps.
Курс по DevSecOps Deep Dive в Inseca
Освойте направление DevSecOps Deep Dive за 3 месяца и получите навыки, необходимые для по построению процессов безопасной разработки. Пройдите полный путь от внедрения инструментов безопасности до построения полноценных процессов. Курс включает практику в реальных кейсах. Подходит DevOps- и инфраструктурным инженерам, которые хотят встроить контроль безопасности в свои процессы и освоить DevSecOps-практики, инженерам по безопасности, которым необходимо получить комплексный взгляд на реализацию процессов безопасной разработки, начинающим DevSecOps-специалистам, которым нужно системное понимание, практические сценарии и уверенность для выхода на уровень middle.
