Оценка технического долга: метрики дефектов ИБ для команд разработки

Всем привет!

Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Наша команда разрабатывает модуль визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. В предыдущих статьях мы говорили об оценке рисков ИБ, подходе Shift Left, обработке уязвимостей, проекции DORA на DevSecOps и анализе AppSec Coverage. Сегодня речь пойдет о не менее важном артефакте в парадигме ASOC – дефектах ИБ. Мы расскажем о метриках, с помощью которых команды разработки могут отслеживать текущее состояние безопасности и эффективность процессов исправления проблем в коде.

Определимся с терминологией

Уязвимость и дефект информационной безопасности — это два термина, которые иногда применяются взаимозаменяемо. Они описывают потенциальную проблему в системе или слабое место, которые могут быть использованы для несанкционированного доступа, кражи активов и других серьезных киберпреступлений. Чтобы избежать недопонимания, рассмотрим данные понятия в контексте DevSecOps, в частности, инструмента класса ASOC (Application Security Orchestration and Correlation).

Прежде всего разберемся с термином «уязвимость». Важно различать два вида:

1. Уязвимость (vulnerability). Это конкретный недостаток в ПО с открытым кодом, идентифицированный и зарегистрированный в публичной/приватной базе, например, CVE Program или GitHub Advisory, с присвоенным уникальным ID – CVE-2024-23898 или GHSA-53ph-2r2x-vqw8.

2. Выявленная уязвимость (issue). Это проблема, обнаруженная конкретным сканером ИБ в определенном программном обеспечении. Инженеры безопасности иногда называют ее «сработкой» или «срабатыванием». Эта уязвимость требует действий со стороны специалистов: ревью (триажа) и устранения. В рамках проверок OSA/SCA выявленный недостаток напрямую связан с vulnerability.

Именно issue — основной объект для подсчета метрик DevSecOps. Расчет показателей рисков ИБ, времени выявления, триажа и закрытия уязвимостей опирается на анализ количества и статусов уязвимостей, обнаруженных различными сканерами. Эти метрики отражают эффективность процессов и работы команд информационной безопасности.

Но еще один важный участник этой деятельности – команда разработки, устраняющая выявленные уязвимости. И для оценки эффективности процессов исправления можно использовать метрики дефектов ИБ. 

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

Жизненный цикл дефекта ИБ 

Жизненный цикл дефекта ИБ в инструменте класса ASOC включает в себя несколько этапов:

1. Создание дефекта из одной или нескольких уязвимостей

Уязвимости можно объединить в один дефект на основании правил корреляции (принципов подобия). Это могут быть идентичные недостатки кода в одном и том же файле, выявленные разными сканерами ИБ или разные версии уязвимой библиотеки. Инженер безопасности объединяет однотипные проблемы в меньшее количество дефектов, а затем добавляет комментарии и рекомендации по их устранению. 

2. Экспорт в систему отслеживания дефектов команды разработки

Созданный дефект автоматически перемещается в дефект-трекинговую систему в виде понятного систематизированного отчета. Это улучшает взаимодействие команд безопасности и разработки и сокращает время на анализ и решение проблем ИБ.

3. Тестирование и верификация

После внесения исправлений статус дефекта автоматически синхронизируется с инструментом ASOC, и инженер безопасности проверяет, действительно ли уязвимости успешно устранены.

4. Закрытие дефекта

После успешного исправления и верификации инженер ИБ отмечает дефект как закрытый.

Метрики дефектов

Чтобы помочь командам ИБ и разработки лучше понимать текущее состояние безопасности и эффективность процессов исправления уязвимостей, мы разработали дашборд «Метрики дефектов». Его основные показатели:

1. Технический долг безопасности

2. Средний возраст дефекта

3. Взвешенный риск ИБ в контексте дефектов

4. Среднее время исправления 

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

Технический долг безопасности

Метрики

1. Количество открытых дефектов (технический долг), подлежащих исправлению в команде разработки, но еще не устраненных (нет подтверждения закрытия от инженера ИБ).

2. % критичных дефектов – доля незакрытых проблем с блокирующим и критическим приоритетом исправления.

3. 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.

Эффективность исправления дефектов

Метрики

1. Mean Time to Resolve (MTTR) – среднее время исправления от момента передачи дефекта в баг-трекинговую систему до подтвержденного инженером ИБ его устранения.

2. Приоритет и скорость исправления – количество закрытых дефектов, разбитых по приоритету, а также уровню производительности команды по сроку устранения. Например, недостатки безопасности могут быть классифицированы как блокирующие, критичные, средние или низкие. По скорости исправления они заранее определяются такими временными интервалами, «менее 1 дня», «от 1 дня до недели» и далее по возрастанию.

3. Исправленные дефекты – количество устраненных проблем, разбитых по уровню производительности.

Все метрики рассчитываются за выбранный период времени.

Анализ

• Среднее время исправления дефектов показывает, насколько оперативно команда реагирует на обнаруженные проблемы в коде или инфраструктуре. Метрику нужно рассматривать вместе со средним возрастом незакрытых уязвимостей. Если MTTR меньше, чем MDA, это значит, что разработчики склонны быстрее реагировать и исправлять недавно обнаруженные, а не старые проблемы;

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

• Количество исправленных дефектов за выбранный период показывает, сколько времени потребуется разработчикам для устранения текущих открытых уязвимостей и снижения общего технического долга.

На дашборде

MTTR в январе 2024 года – 280 дней. Средний возраст незакрытых дефектов превышает год, поэтому можно сделать вывод, что команда разработки отдает приоритет исправлению новых проблем. Это подчеркивается тем, что 15% дефектов устранены очень быстро, менее чем за 1 час.

За последний год было исправлено 28 дефектов, технический долг – 92. Для его полного устранения при текущем темпе закрытия потребуется более 3 лет. Это говорит о необходимости пересмотра стратегий и процессов разработки. Возможно, стоит также поднять вопрос о выделении дополнительных ресурсов.

Изменение технического долга

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

Анализ

Изменение объема технического долга отражает динамику и эволюцию количества открываемых, исправляемых и незакрытых дефектов с течением времени. Данный показатель позволяет команде оценить эффективность управления дефектами и прогнозировать тенденции в работе по их устранению. Это важный инструмент для мониторинга и координации процесса разработки, который направлен на улучшение качества ПО и обеспечение безопасности.

На дашборде

Мы видим, что объем технического долга резко увеличился в конце 2021 года для приложения Digital Service App, из-за чего оно и сейчас имеет высокий уровень риска. Большинство открытых дефектов в того времени остаются незакрытыми. 

Исключив данные по Digital Service App, мы видим, что и в остальных командах разработки дефектов ИБ открывается больше, чем исправляется. Наблюдается устойчивая тенденция к росту технического долга. Поэтому следует оценить текущие процессы, практики и ресурсы в командах разработки, чтобы выявить возможные причины негативного тренда.  

---

Выводы

Мы рассказали о дефектах ИБ в концепции ASOC и о метриках, с помощью которых можно отслеживать текущее состояние безопасности и процессов исправления проблем командами разработки.

Дашборд представляет собой визуальное отображение следующих ключевых метрик:

• Технический долг позволяет оценить текущую нагрузку на команду разработки и ресурсы для исправления проблем ИБ, в том числе в разрезе приоритета исправления. Изменение ТД в динамике показывает тенденции работы с дефектами;

• Средний возраст дефекта измеряет эффективность команды разработки в сокращении технического долга;

• Взвешенный индекс риска в контексте дефектов позволяет сравнить приложения по уровню риска ИБ, выявить проблемные зоны и приоритеты в обеспечении безопасности;

• Среднее время исправления показывает, насколько оперативно команда реагирует на обнаруженные проблемы в коде или инфраструктуре.

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

Визуализация показателей помогает найти в данных тенденции и паттерны, облегчает сравнение между ПО или за разные периоды времени. Разрабатываемый модуль аналитики DevSecOps в рамках платформы AppSec.Hub делает прозрачнее анализ стратегий безопасности в целом.