Всем привет!
Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Наша команда разрабатывает модуль визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. В предыдущих статьях мы рассказывали вам о том, как можно оценить риски ИБ, зрелость подхода Shift Left и эффективность обработки обнаруженных уязвимостей. Сегодня мы разберем еще один дашборд для оценки процессов безопасности в разработке и поговорим о проекции метрик DORA на DevSecOps.
Что такое DORA?
DevOps имеет давнюю историю и сегодня является стандартом автоматизации процесса разработки программного обеспечения. Анализом этой методологии с 2018 года занимается команда DevOps Research and Assessment (DORA) из Google. Она же определила ключевые метрики зрелости DevOps, так называемые «Четыре ключа»:
Deployment Frequency — частота развертывания
Lead Time for Changes — общее время изменений (от коммита до релиза)
Change Failure Rate — частота сбоев при развертывании
Time to Restore Service — время восстановления после сбоя
ИБ в DevOps
Роль безопасности в практиках DevOps долгое время оставалась неопределенной. Пока в 2021 году в ежегодном отчете команды DORA не появилось следующее заявление: «Безопасность больше не может быть второстепенной задачей — ее необходимо интегрировать на каждом этапе жизненного цикла разработки для создания безопасной цепочки поставок ПО».
К 2022 году взаимосвязь между безопасностью и DevOps стала важной частью ежегодного исследования DORA. Из отчета прошлого года следует, что наиболее распространенная практика безопасности — встраивание сканирования информационной безопасности в системы непрерывной интеграции (CI/CD). Около 63% респондентов заявили, что в их компаниях внедрены проверки ИБ на всех этапах жизненного цикла ПО.
Действительно, регулярное автоматическое сканирование безопасности при разработке приложений – это то, без чего нельзя интегрировать безопасность в DevOps и построить DevSecOps. Чтобы оценить эффективность внедрения и применения проверок ИБ для отдельных программ и всех систем в целом, крайне важно иметь возможность измерять различные аспекты сканирования, такие как:
Давайте посмотрим поближе на эти метрики и их пересечение с DORA:
Частота сканирования ИБ
Как считаем
Частота сканирования (Security Scan Frequency) равна количеству запусков сканирований ИБ за период: месяц/неделю/день.
Анализ
Метрика позволяет оценить, достаточно ли часто ваши системы проверяются на предмет уязвимостей и других потенциальных угроз. Обычно рассматривается в разрезе отдельного приложения. Для оценки нескольких систем можно использовать производную метрику, нормированную на количество приложений – «Средняя частота сканирований на приложение». Высокое значение показывает, что анализируется каждое изменение и уязвимости идентифицируются на ранних стадиях. Другими словами, мы имеем так называемый сдвиг влево (Shift Left). Низкий показатель говорит о том, что сканирования осуществляются недостаточно часто и, скорее всего, вручную. Возможно, автоматический запуск проверок безопасности не встроен в CI/CD.
Связь с DORA
Частота сканирования напрямую связана с частотой развертывания (DORA: Deployment Frequency) и при внедренном DevOps должна рассматриваться в сравнении с ней.
Частота развертывания отражает скорость доставки изменений в производственную среду. Когда Deployment Frequency высока и изменения внедряются регулярно, важно, чтобы и частота сканирования безопасности была на том же уровне. Тогда мы имеем ситуацию, при которой каждое развертывание подвергается анализу ИБ и минимизирует риски, связанные с поставкой нового функционала.
При высоком уровне зрелости DevOps частота сканирований должна быть значительно выше частоты развертывания. Это означает, что проверки безопасности внедряются на ранних стадиях разработки и код (артефакты сборки, стенды) проверяется не один раз.
Ограничения
У разных приложений частота релизов (а значит и частота сканирования) различается. Метрика не позволяет сравнить достижение целевых значений у разных приложений или выявить, что проверки проводятся редко. Скорее, она подсвечивает общий тренд
Даже высокие значения частоты сканирования не гарантируют ее эффективности, если не предусмотрено полное покрытие тестами безопасности всех частей приложения
На дашборде
Метрика показывает, что за август 2023 года сканирование ИБ запускалось 63 раза, и это на 57% больше, чем в прошлом месяце. Вероятно, в контур безопасной разработки добавились команды или часть проверок была встроена в DevOps.
Среднее время успешных сканирований
Как считаем
Среднее время успешных сканирований (Security Scan Time) – это среднее количество времени, которое занимает одна успешно завершенная проверка ИБ (от запуска до получения результата).
Анализ
Метрика показывает среднюю скорость работы инструментов ИБ.
Значения выше ожидаемых могут говорить о неэффективности или неверной настройке используемых сканеров или неоптимальном использовании вычислительных ресурсов. В сочетании с частотой проверок Security Scan Time позволяет оценить загруженность всех мощностей инструментов безопасности. С ее помощью можно сделать прогноз на расширение текущих лицензий или обосновать потраченные средства на сканеры.
Связь с DORA
Security Scan Time напрямую связана со второй метрикой DORA — Lead Time for Changes (время внесения изменений), так как среднее время сканирования – один из компонентов общего времени доставки изменений до конечного пользователя. В командах с высокой зрелостью DevOps «Lead Time for Changes» составляет несколько часов, а то и минут, и для них длительные сканирования могут затянуть процесс развертывания.
Быстрые сканирования способствуют получению оперативной обратной связи о безопасности вносимых изменений. Разработчики могут быстро учитывать результаты проверок и вносить необходимые коррективы. Таким образом можно ускорить поставку новых изменений, что является ключевым аспектом в контексте DevOps.
Ограничения
Среднее время сканирования может варьироваться в зависимости от сложности приложения, его размеров, языка программирования и других факторов. При интерпретации метрики необходимо учитывать контекст и стек технологий конкретного приложения.
На дашборде
Security Scan Time в августе — 2 минуты, по отношению к прошлому месяцу он снизился на 67%. Это является неплохим показателем и говорит о том, что инструменты проверки были перенастроены или произошла замена сканера на более быстрый и эффективный.
Коэффициент пройденных контрольных точек
Как считаем
Точки контроля в терминах инструмента AppSec.Hub – это Quality Gates, которые настраиваются на уровне организации, команды или пайплайна в зависимости от уровня зрелости команд. А применяются они уже к результатам сканирования. Таким образом выполняется оценка критериев качества в контексте безопасности и принимается решение о прохождении данной точки контроля.
Коэффициент пройденных контрольных точек (Passed Security Gates Ratio) – отношение сканирований, прошедших установленные точки контроля качества (Quality Gates), к общему числу успешных проверок.
Анализ
Низкое значение метрики указывает то, что команды не справляются с выставленными критериями качества. Возможно, разработчики не уделяют должного внимания безопасности или не считают практики ИБ обязательными. Также это может говорить о том, что уровень зрелости как отдельных команд, так и всей компании переоценен.
Если Passed Security Gates Ratio высокий, значит выпускаемое ПО соответствует установленным критериям качества. Это может быть результатом эффективной интеграции безопасности в процесс разработки. Также это может быть сигналом о том, что ваша команда достигла более высокого уровня зрелости и необходимо пересмотреть корпоративную политику ИБ и оптимизировать критерии качества.
Связь с DORA
Частота сбоев при развертывании (Change Failure Rate) отвечает в широком смысле за качество ПО: показывает процент неудачных изменений кода, которые вызывают сбои или проблемы в производственной среде. Коэффициент пройденных контрольных точек (Passed Security Gates Ratio) также фокусируется на качестве кода, но на другом аспекте качества — информационной безопасности. Эта метрика непосредственно влияет на частоту сбоев.
Если команда разработки строго соблюдает стандарты ИБ, а код соответствует установленным критериям качества, то снижается риск неудачных изменений. Безопасность, встроенная в процесс разработки, уменьшает вероятность появления ошибок, которые могут привести к сбоям.
Ограничения
Метрика зависит от эффективности инструментов проверки ИБ. Если используемые сканеры не обнаруживают какие-то виды уязвимостей или имеют высокий уровень ложных срабатываний, она может не полностью отражать реальный уровень безопасности кода.
На дашборде
Текущий показатель Passed Security Gates Ratio — 23%. Мы видим, что менее четверти результатов всех успешно завершенных сканирований соответствует установленным критериям безопасности. Это довольно низкий показатель – требуется провести оценку критериев ИБ и соответствия их уровню зрелости команды.
Выводы
DevSecOps неотрывно связан с DevOps – это факт. И в процессе безопасной разработки можно применить те же метрики DORA, к которым привыкли все DevOps-инженеры и их руководители, но с акцентом на ИБ:
Частота сканирования в зрелом процессе разработки выше частоты развертывания
Среднее время сканирования – один из важных компонентов общего времени доставки изменений
Коэффициент пройденных контрольных точек влияет на частоту сбоев: если ваша команда соблюдает стандарты безопасности, а код соответствует установленным критериям качества, снижается риск неудачных деплоев.
Связывая метрики ИБ с принципами DORA (DevOps Research and Assessment), мы понимаем, что безопасность становится ключом к высокой производительности организаций в разработке и поставке ПО. Показатели сканирования — важный инструмент оценки эффективности ИБ-процессов.
При этом визуализация метрик вносит существенный вклад в анализ и улучшение стратегий безопасности. Она дает представление о том, насколько успешно внедряются и применяются практики ИБ, обеспечивает качественный мониторинг долгосрочных трендов и позволяет адаптировать стратегию в ответ на их изменения. Для этого в рамках платформы безопасной разработки AppSec.Hub мы создаем модуль визуализации метрик DevSecOps.
До новых встреч!