Оценка технического долга: метрики дефектов ИБ для команд разработки
Всем привет!
Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Наша команда разрабатывает модуль визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. В предыдущих статьях мы говорили об оценке рисков ИБ, подходе Shift Left, обработке уязвимостей, проекции DORA на DevSecOps и анализе AppSec Coverage. Сегодня речь пойдет о не менее важном артефакте в парадигме ASOC — дефектах ИБ. Мы расскажем о метриках, с помощью которых команды разработки могут отслеживать текущее состояние безопасности и эффективность процессов исправления проблем в коде.
Определимся с терминологией
Уязвимость и дефект информационной безопасности — это два термина, которые иногда применяются взаимозаменяемо. Они описывают потенциальную проблему в системе или слабое место, которые могут быть использованы для несанкционированного доступа, кражи активов и других серьезных киберпреступлений. Чтобы избежать недопонимания, рассмотрим данные понятия в контексте DevSecOps, в частности, инструмента класса ASOC (Application Security Orchestration and Correlation).
Прежде всего разберемся с термином »уязвимость». Важно различать два вида:
Уязвимость (vulnerability). Это конкретный недостаток в ПО с открытым кодом, идентифицированный и зарегистрированный в публичной/приватной базе, например, CVE Program или GitHub Advisory, с присвоенным уникальным ID — CVE-2024–23898 или GHSA-53ph-2r2x-vqw8.
Выявленная уязвимость (issue). Это проблема, обнаруженная конкретным сканером ИБ в определенном программном обеспечении. Инженеры безопасности иногда называют ее «сработкой» или «срабатыванием». Эта уязвимость требует действий со стороны специалистов: ревью (триажа) и устранения. В рамках проверок OSA/SCA выявленный недостаток напрямую связан с vulnerability.
Именно issue — основной объект для подсчета метрик DevSecOps. Расчет показателей рисков ИБ, времени выявления, триажа и закрытия уязвимостей опирается на анализ количества и статусов уязвимостей, обнаруженных различными сканерами. Эти метрики отражают эффективность процессов и работы команд информационной безопасности.
Но еще один важный участник этой деятельности — команда разработки, устраняющая выявленные уязвимости. И для оценки эффективности процессов исправления можно использовать метрики дефектов ИБ.
В общем смысле дефект информационной безопасности является ошибкой кода или инфраструктуры, которая требует внимания и устранения. В контексте подхода ASOC — это сгруппированный отчет об одной или нескольких уязвимостях, подтвержденных и приоритизированных ИБ-специалистом. Он создается инженером безопасности и экспортируется в дефект-трекинговую систему команды разработки для последующего исправления.
Жизненный цикл дефекта ИБ
Жизненный цикл дефекта ИБ в инструменте класса ASOC включает в себя несколько этапов:
Создание дефекта из одной или нескольких уязвимостей
Уязвимости можно объединить в один дефект на основании правил корреляции (принципов подобия). Это могут быть идентичные недостатки кода в одном и том же файле, выявленные разными сканерами ИБ или разные версии уязвимой библиотеки. Инженер безопасности объединяет однотипные проблемы в меньшее количество дефектов, а затем добавляет комментарии и рекомендации по их устранению.
Экспорт в систему отслеживания дефектов команды разработки
Созданный дефект автоматически перемещается в дефект-трекинговую систему в виде понятного систематизированного отчета. Это улучшает взаимодействие команд безопасности и разработки и сокращает время на анализ и решение проблем ИБ.
Тестирование и верификация
После внесения исправлений статус дефекта автоматически синхронизируется с инструментом ASOC, и инженер безопасности проверяет, действительно ли уязвимости успешно устранены.
Закрытие дефекта
После успешного исправления и верификации инженер ИБ отмечает дефект как закрытый.
Метрики дефектов
Чтобы помочь командам ИБ и разработки лучше понимать текущее состояние безопасности и эффективность процессов исправления уязвимостей, мы разработали дашборд «Метрики дефектов». Его основные показатели:
Технический долг безопасности
Средний возраст дефекта
Взвешенный риск ИБ в контексте дефектов
Среднее время исправления
Дашборд «Метрики дефектов ИБ»
Мы видим, что левая часть дашборда помогает разработчикам оценить текущее состояние технического долга ИБ (когда выявленные дефекты еще не устранены), а также риск в контексте незакрытых проблем. А правая позволяет измерить эффективность исправления дефектов за выбранный период времени и проанализировать динамику изменения технического долга.
Технический долг безопасности
Метрики
Количество открытых дефектов (технический долг), подлежащих исправлению в команде разработки, но еще не устраненных (нет подтверждения закрытия от инженера ИБ).
% критичных дефектов — доля незакрытых проблем с блокирующим и критическим приоритетом исправления.
Mean Defect Age (MDA) — средний возраст незакрытых дефектов в днях, рассчитывается от момента направления уязвимости в дефект-трекинговую систему команды разработки.
Отметим, что метрики рассчитываются на текущий момент времени.
Анализ
Отслеживание количества открытых дефектов, ожидающих исправления, помогает определить уровень нагрузки на команду разработки. Метрика также позволяет оценить ресурсы для текущего объема задач и планировать распределение рабочего времени.
% Критичных дефектов дает возможность грамотно приоритизировать работу с упором на долю проблем, требующих немедленного внимания.
Средний возраст дефекта показывает эффективность команды разработки в сокращении технического долга: чем он меньше, тем успешнее команда закрывает накопленный тех. долг. Высокий MDA говорит о том, что приоритетно устраняются вновь открытые дефекты, но технический долг не уменьшается.
На дашборде
На данный момент технический долг ИБ для команд разработки — 92 незакрытых дефекта. Примерно 16% из них являются блокирующими или критическими, что является довольно весомым показателем. Средний возраст незакрытых проблем превышает год. Всё это говорит о том, что большая часть из них направлена на устранение очень давно. Критичные уязвимости остаются неисправленными в течение длительного времени, а это является серьезной угрозой для безопасности системы.
Возможно, разработчики сталкиваются с высоким объемом работы и приоритезируют исправление дефектов с учетом их влияния на текущие задачи проекта. Также причиной может быть недостаток ресурсов или внимания к аспектам ИБ в культуре разработки.
Взвешенный индекс риска в контексте дефектов
В одной из статей мы уже рассказывали о взвешенном индексе риска (Weighted Risk Index, WRI) в рамках незакрытых уязвимостей. Сегодня поговорим о нем в контексте дефектов. WRI — это инструмент для сравнения уровня риска различных приложений, обусловленного недостаточной эффективностью команд разработки по исправлению дефектов. Данная метрика учитывает не только количество незакрытых проблем, но и приоритет исправления, а также индекс опасности приложения.
Показатель рассчитывается на текущий момент времени и в динамике.
Анализ
Weighted Risk Index показывает уровень потенциального риска в разнотипных приложениях и дает возможность сравнивать их между собой. Чем выше приоритет исправления дефектов и критичность системы, тем больше значение WRI. Метрика помогает приоритизации и ресурсному планированию для устранения дефектов в продуктах с высоким индексом риска.
Большие значения взвешенного индекса риска указывают на присутствие высокоприоритетных дефектов, которые требуют немедленного внимания, так как они могут серьезно повлиять на функциональность и безопасность системы. Низкий показатель может говорить о том, что текущие ресурсы (технические и человеческие) оптимально используются для исправления проблем ИБ.
Изменение WRI в динамике отражает эволюцию уровня риска в разработке продуктов с течением времени. Уменьшение метрики может говорить об эффективности усилий по закрытию проблем в коде, а увеличение — о том, что нужно пересмотреть стратегию управления недостатками безопасности. Показатель также отражает изменения в действиях команды разработки, например, говорит о применении новых практик ИБ или, наоборот, недостаточном внимании к дефектам. Если WRI резко возрастает, то чаще всего это связано с появлением новых угроз или серьезных уязвимостей, на которые необходимо быстро реагировать.
На дашборде
Мы видим, что наибольший WRI на текущий момент у приложения Digital Service App. График изменения показывает, что значительные перемены в рамках всего портфеля приложений произошли в начале 2023 года, когда практически полностью был погашен технический долг ПО с наибольшим риском: Cloud Application Service и AG-Test.
Эффективность исправления дефектов
Метрики
Mean Time to Resolve (MTTR) — среднее время исправления от момента передачи дефекта в баг-трекинговую систему до подтвержденного инженером ИБ его устранения.
Приоритет и скорость исправления — количество закрытых дефектов, разбитых по приоритету, а также уровню производительности команды по сроку устранения. Например, недостатки безопасности могут быть классифицированы как блокирующие, критичные, средние или низкие. По скорости исправления они заранее определяются такими временными интервалами, «менее 1 дня», «от 1 дня до недели» и далее по возрастанию.
Исправленные дефекты — количество устраненных проблем, разбитых по уровню производительности.
Все метрики рассчитываются за выбранный период времени.
Анализ
Среднее время исправления дефектов показывает, насколько оперативно команда реагирует на обнаруженные проблемы в коде или инфраструктуре. Метрику нужно рассматривать вместе со средним возрастом незакрытых уязвимостей. Если MTTR меньше, чем MDA, это значит, что разработчики склонны быстрее реагировать и исправлять недавно обнаруженные, а не старые проблемы;
Разбивка устраненных дефектов по приоритету и скорости закрытия позволяет оценить, насколько эффективно команда разработки реагирует на дефекты различных уровней в пределах заданных временных рамок. Такой анализ помогает оптимизировать процессы управления проблемами в коде и поддерживать требуемый уровень качества продукта;
Количество исправленных дефектов за выбранный период показывает, сколько времени потребуется разработчикам для устранения текущих открытых уязвимостей и снижения общего технического долга.
На дашборде
MTTR в январе 2024 года — 280 дней. Средний возраст незакрытых дефектов превышает год, поэтому можно сделать вывод, что команда разработки отдает приоритет исправлению новых проблем. Это подчеркивается тем, что 15% дефектов устранены очень быстро, менее чем за 1 час.
За последний год было исправлено 28 дефектов, технический долг — 92. Для его полного устранения при текущем темпе закрытия потребуется более 3 лет. Это говорит о необходимости пересмотра стратегий и процессов разработки. Возможно, стоит также поднять вопрос о выделении дополнительных ресурсов.
Изменение технического долга
График визуализирует количество открытых и закрытых дефектов по месяцам с разбивкой по приложениям. Вертикальные столбцы выше линии представляют новые открытые дефекты, а ниже — закрытые проблемы в коде. Высота столбца соответствует количеству дефектов. Линия накопительного технического долга отображает общее количество незакрытых дефектов на данный момент во всех программах.
Анализ
Изменение объема технического долга отражает динамику и эволюцию количества открываемых, исправляемых и незакрытых дефектов с течением времени. Данный показатель позволяет команде оценить эффективность управления дефектами и прогнозировать тенденции в работе по их устранению. Это важный инструмент для мониторинга и координации процесса разработки, который направлен на улучшение качества ПО и обеспечение безопасности.
На дашборде
Мы видим, что объем технического долга резко увеличился в конце 2021 года для приложения Digital Service App, из-за чего оно и сейчас имеет высокий уровень риска. Большинство открытых дефектов в того времени остаются незакрытыми.
Исключив данные по Digital Service App, мы видим, что и в остальных командах разработки дефектов ИБ открывается больше, чем исправляется. Наблюдается устойчивая тенденция к росту технического долга. Поэтому следует оценить текущие процессы, практики и ресурсы в командах разработки, чтобы выявить возможные причины негативного тренда.
Выводы
Мы рассказали о дефектах ИБ в концепции ASOC и о метриках, с помощью которых можно отслеживать текущее состояние безопасности и процессов исправления проблем командами разработки.
Дашборд представляет собой визуальное отображение следующих ключевых метрик:
Технический долг позволяет оценить текущую нагрузку на команду разработки и ресурсы для исправления проблем ИБ, в том числе в разрезе приоритета исправления. Изменение ТД в динамике показывает тенденции работы с дефектами;
Взвешенный индекс риска в контексте дефектов позволяет сравнить приложения по уровню риска ИБ, выявить проблемные зоны и приоритеты в обеспечении безопасности;
Среднее время исправления показывает, насколько оперативно команда реагирует на обнаруженные проблемы в коде или инфраструктуре.
Анализ метрик дефектов и их динамики позволяет командам безопасности и разработки анализировать текущее состояние технического долга, оценить скорость его уменьшения и эффективность исправления проблем безопасности. Также он дает возможность сравнивать результаты между разными приложениями. Эти данные важны для планирования ресурсов и прогнозирования долгосрочных направлений в работе над продуктом.
Визуализация показателей помогает найти в данных тенденции и паттерны, облегчает сравнение между ПО или за разные периоды времени. Разрабатываемый модуль аналитики DevSecOps в рамках платформы AppSec.Hub делает прозрачнее анализ стратегий безопасности в целом.
