Перейти к содержанию

Аналитика

Метрики DevSecOps

В AppSec.Hub реализованы сбор и визуализация метрик DevSecOps, что позволяет осуществлять эффективный анализ и управление безопасной разработкой приложений. Визуализация данных в системе осуществляется с помощью инструмента Apache Superset.

Выберите пункт меню Metrics. На сегодняшний день в системе доступны следующие дашборды:

  • Технический долг устранения уязвимостей (Security vulnerability debt).
  • Уязвимости в OWASP Top 10:2021 (Top 10 OWASP vulnerabilities 2021).
  • Объем и структура исходного кода (Volume and structure of source code).
  • Дефекты ИБ (Information security defects).
  • Уязвимости по практикам ИБ (Vulnerabilities by information security practices).

С помощью пунктов меню «», расположенного в правом верхнем углу, можно:

  • Обновить дашборд, включая все расположенные на нем метрики.
  • Сохранить дашборд в формате PDF или JPEG, выбрав соответствующий подпункт меню.
  • Задать интервал обновления метрик дашборда на время текущей сессии, выбрав частоту обновления в окне Интервал обновления и нажав не кнопку Сохранить на время текущей сессии.

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

Метрики содержат информацию о примененных фильтрах:

Каждая из метрик дашборда содержит меню «» в правом верхнем углу.

С помощью пунктов этого меню можно:

  • Обновить данные метрики.
  • Перевести метрику в Полноэкранный режим.
  • Показать SQL-запрос, используемый для формирования метрики. SQL-запрос содержит список используемых при построении метрики приложений, к которым пользователь имеет доступ в системе.
  • Показать в виде таблицы данные метрики.
  • Сохранить метрику в формате CSV, Excel или JPEG, выбрав соответствующий подпункт меню.

Технический долг устранения уязвимостей

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

  • Открытая уязвимость (Open issue) – это обнаруженная и переданная в разработку уязвимость, получившая статус Open.
  • Устраненная уязвимость (Resolved issue) – это переданная в разработку и затем закрытая уязвимость (не обнаруженная в последнем сканировании, то есть сменившая статус Open на статус Fixed).

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

  • Открытые уязвимости (Vulnerability Open Rate, VOR) за отображаемый период. VOR – это количество уязвимостей, получивших в выбранный период статус Open.
  • Устраненные уязвимости (Vulnerability Resolved Rate, VRR) за отображаемый период. VRR – это количество уязвимостей, сменивших в выбранный период статус Open на статус Fixed.
  • Технический долг (неустраненные) – это количество неустраненных на текущую дату уязвимостей.
  • Open to Resolved Ratio (OTRR) за отображаемый период. OTRR – это отношение количества открытых в выбранном периоде уязвимостей к количеству устраненных в выбранном периоде уязвимостей. OTRR должен быть менее 100%, что означает: мы за отображаемый период устраняем больше уязвимостей, чем открываем новых, а значит, сокращаем технический долг.

Технический долг (неустраненные уязвимости)

  • Серьезность уязвимости – разбивка уязвимостей из технического долга по критичности.
  • Практика ИБ – разбивка уязвимостей из технического долга по практикам ИБ, с помощью которых они были обнаружены.
  • Приложения – разбивка уязвимостей из технического долга по приложениям, в которых они были обнаружены.
  • Инструменты ИБ – разбивка уязвимостей из технического долга по инструментам ИБ, с помощью которых они были обнаружены.

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

% Open to Resolved – отношение количества открытых в выбранном периоде уязвимостей к количеству устраненных в выбранном периоде уязвимостей с разбивкой уязвимостей по критичности и по практикам ИБ, с помощью которых они были обнаружены.

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

Технический долг (приложения), динамика

  • Приложения – состояние суммарного технического долга в разработке продуктов с течением времени с данными по устраненным и открытым уязвимостям с разбивкой по приложениям.
  • Инструменты ИБ – состояние суммарного технического долга в разработке продуктов с течением времени с данными по устраненным и открытым уязвимостям с разбивкой по инструментам ИБ, с помощью которых они были обнаружены.
  • Практика ИБ – состояние суммарного технического долга в разработке продуктов с течением времени с данными по устраненным и открытым уязвимостям с разбивкой по практикам ИБ, с помощью которых они были обнаружены.
  • Серьезность уязвимости – состояние суммарного технического долга в разработке продуктов с течением времени с данными по устраненным и открытым уязвимостям с разбивкой по критичности.

Устранение уязвимостей (серьезность) – количество открытых и устраненных уязвимостей с разбивкой по критичности и показателем Open to Resolved Ratio для каждого уровня серьезности.

Уязвимости в OWASP Top 10:2021

Дашборд Уязвимости в OWASP Top 10:2021 содержит следующие метрики:

  • Количество уязвимостей, обнаруженных в приложениях на текущий момент и относящихся к списку уязвимостей OWASP Top 10.
  • Количество CWE – общее количество уникальных CWE, к которым относятся обнаруженные уязвимости из OWASP Top 10.
  • Уязвимости по категориям OWASP->CWE ID – количество уязвимостей, относящихся к OWASP Top 10, с разбивкой по категориям OWASP Top 10 и по CWE.
  • Приложения по количеству уязвимостей – приложения с данными по количеству обнаруженных уязвимостей, относящихся к OWASP Top 10.
  • Серьезность уязвимостей в категориях OWASP – количество обнаруженных уязвимостей, относящихся к категориям OWASP Top 10, с разбивкой по критичности.
  • Количество уникальных CWE в категории (серьезность) – количество уникальных CWE обнаруженных уязвимостей, относящихся к категориям OWASP Top 10, с разбивкой по критичности.
  • Уязвимости по практикам ИБ – количество обнаруженных уязвимостей, относящихся к категориям OWASP Top 10, с разбивкой по практикам тестирования безопасности.
  • Количество уникальных CWE в категории (практика ИБ) – количество уникальных CWE обнаруженных уязвимостей, относящихся к категориям OWASP Top 10, с разбивкой по практикам тестирования безопасности.
  • Описание CWE категорий – список уникальных CWE, к которым относятся обнаруженные уязвимости из OWASP Top 10, с возможностью сортировки по столбцам. Для каждого CWE список содержит категорию OWASP Top 10, CWE ID, название и описание CWE, а также количество найденных уязвимостей.

Объем и структура исходного кода

В метриках объема и структуры исходного кода используется понятие SLOC.

SLOC (Source lines of code) – это метрика для измерения размера приложения путем подсчета количества строк в тексте исходного кода программы. Учитываются только значимые строки без пустых строк и комментариев.

SLOC подсчитывается для приложений (applications) с разбивкой по кодовым базам (cobebases) и языкам программирования (languages).

Дашборд Объем и структура исходного кода содержит следующие метрики:

  • Приложения - количество уникальных приложений, представленных на дашборде.
  • Языки программирования - количество уникальных языков программирования.
  • Кодовые базы – количество уникальных кодовых баз.
  • Файлы – количество уникальных файлов.
  • Строки кода (SLOC) – общее количество строк кода во всех представленных на дашборде приложениях.

Объем кода приложений

  • Размер приложений, в SLOC – для всех представленных приложений.
  • Структура кода приложений по языкам программирования – для каждого приложения приводится количество строк кода на каждом из языков программирования.
  • Размер приложений (ТОП), в разбивке по кодовым базам – на этом графике представлены самые большие по размеру (в SLOC) приложения, при этом для каждого приложения приведены используемые кодовые базы и их размер.

Объем кода на языках программирования

  • Объем кода по языкам, SLOC – объем кода всех представленных на дашборде приложений на каждом из языков программирования.
  • Структура кода на языках программирования по приложениям – на этом графике представлен общий объем кода на каждом из языков программирования с разбивкой по приложениям, в которых он используется.

Динамика изменения объема кода

  • Объем кода (текущий период), SLOC – общее количество строк кода во всех представленных на дашборде приложениях в текущем периоде по сравнению с предыдущим. Текущий период устанавливается в фильтре Текущий период в поле фильтров дашборда.
  • Динамика изменения общего объема кода во всех представленных на дашборде приложениях. Период времени для отображения устанавливается в фильтре Отображаемый период, выбор временного шага отображения - в фильтре Детализация даты в поле фильтров дашборда.
  • Динамика изменения объема кода (приложения) в каждом из приложений. Период времени для отображения устанавливается в фильтре Отображаемый период, выбор временного шага отображения - в фильтре Детализация даты в поле фильтров дашборда.

Дефекты ИБ

Дашборд Дефекты ИБ содержит следующие метрики:

Технический долг (на текущий момент)

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

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

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

    Эта метрика дает возможность грамотно приоритизировать работу с упором на долю проблем, требующих немедленного внимания.

  • Средний возраст дефекта (Mean Defect Age, MDA) - средний возраст незакрытых дефектов в днях, рассчитывается от момента направления уязвимости в дефект-трекинговую систему команды разработки.

    Средний возраст дефекта показывает эффективность команды разработки в сокращении технического долга: чем он меньше, тем успешнее команда закрывает накопленный тех. долг. Высокий MDA говорит о том, что приоритетно устраняются вновь открытые дефекты, но технический долг не уменьшается.

Взвешенный индекс риска в контексте дефектов

Взвешенный индекс риска (Weighted Risk Index, WRI) позволяет одним числом показать подверженность риску, учитывая критичность (как уязвимостей, так и самих разрабатываемых приложений). WRI – это произведение суммы неисправленных уязвимостей приложения, доступных для эксплуатации в промышленной среде, взвешенных с учетом серьезности и индекса риска приложения.

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

  • Взвешенный риск, WRI (ТОП приложений) - Weighted Risk Index показывает уровень потенциального риска в разнотипных приложениях и дает возможность сравнивать их между собой. Чем выше приоритет исправления дефектов и критичность системы, тем больше значение WRI. Метрика помогает приоритизации и ресурсному планированию для устранения дефектов в продуктах с высоким индексом риска.

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

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

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

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

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

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

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

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

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

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

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

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

Уязвимости по практикам ИБ

Дашборд Уязвимости по практикам ИБ содержит следующие метрики:

  • Количество выявленных уязвимостей на текущий момент.
  • Серьезность уязвимостей – количество обнаруженных уязвимостей с разбивкой по их критичности.
  • Статус уязвимостей – количество обнаруженных уязвимостей с разбивкой по их статусу.
  • Уязвимости по практикам ИБ – количество обнаруженных уязвимостей с разбивкой по практикам тестирования безопасности.

SAST

  • По приложениям.

    • Топ приложений по уязвимостям, выявленным SAST – приложения с наибольшим числом уязвимостей, обнаруженных практикой SAST, с разбивкой уязвимостей по критичности.
    • Серьезность уязвимостей - приложения – количество уязвимостей, обнаруженных практикой SAST, с разбивкой по критичности и по приложениям, в которых они были найдены.
    • Уязвимости, выявленные SAST, по приложениям – список приложений с данными по общему числу уязвимостей, обнаруженных практикой SAST, и числу уязвимостей с разбивкой по приложениям и по критичности с возможностью сортировки по столбцам.
  • По категориям уязвимостей.

    • Топ категорий по уязвимостям, выявленным SAST – категории уязвимостей с наибольшим числом обнаруженных практикой SAST уязвимостей с разбивкой по критичности.
    • Серьезность уязвимостей - категории – количество уязвимостей, обнаруженных практикой SAST, с разбивкой по критичности и по категориям.
    • Уязвимости, выявленные SAST, по категориям – список категорий с данными по общему числу уязвимостей, обнаруженных практикой SAST, и числу уязвимостей с разбивкой по категориям и по критичности с возможностью сортировки по столбцам.

SCA Security

  • По приложениям.

    • Топ приложений по Security-уязвимостям, выявленным SCA – приложения с наибольшим числом Security-уязвимостей, обнаруженных практикой SCA, с разбивкой уязвимостей по критичности.
    • Серьезность уязвимостей - приложения – количество Security-уязвимостей, обнаруженных практикой SCA, с разбивкой по критичности и по приложениям, в которых они были найдены.
    • Security-уязвимости, выявленные SCA, по приложениям – список приложений с данными по общему числу Security-уязвимостей, обнаруженных практикой SCA, и числу уязвимостей с разбивкой по приложениям и по критичности с возможностью сортировки по столбцам.
  • По компонентам.

    • Топ компонент по Security-уязвимостям, выявленным SCA – компоненты с наибольшим числом обнаруженных практикой SCA Security-уязвимостей с разбивкой по критичности.
    • Серьезность уязвимостей - компоненты – количество Security-уязвимостей, обнаруженных практикой SCA, с разбивкой по критичности и по компонентам.
    • Security-уязвимости, выявленные SCA, по компонентам – список компонентов с данными по общему числу Security-уязвимостей, обнаруженных практикой SCA, и числу уязвимостей с разбивкой по компонентам и по критичности с возможностью сортировки по столбцам.

SCA Compliance

  • По приложениям.

    • Топ приложений по Compliance-уязвимостям, выявленным SCA – приложения с наибольшим числом Compliance-уязвимостей, обнаруженных практикой SCA, с разбивкой уязвимостей по критичности.
    • Серьезность уязвимостей - приложения – количество Compliance-уязвимостей, обнаруженных практикой SCA, с разбивкой по критичности и по приложениям, в которых они были найдены.
    • Compliance-уязвимости, выявленные SCA, по приложениям – список приложений с данными по общему числу Compliance-уязвимостей, обнаруженных практикой SCA, и числу уязвимостей с разбивкой по приложениям и по критичности с возможностью сортировки по столбцам.
  • По open-source лицензиям.

    • Топ лицензий по Compliance-уязвимостям, выявленным SCA – лицензии с наибольшим числом обнаруженных практикой SCA Compliance-уязвимостей с разбивкой по критичности.
    • Серьезность уязвимостей - лицензии – количество Compliance-уязвимостей, обнаруженных практикой SCA, с разбивкой по критичности и по лицензиям.
    • Compliance-уязвимости, выявленные SCA, по лицензиям – список лицензий с данными по общему числу Compliance-уязвимостей, обнаруженных практикой SCA, и числу уязвимостей с разбивкой по лицензиям и по критичности с возможностью сортировки по столбцам.

DAST

  • Топ приложений по уязвимостям, выявленным DAST – приложения с наибольшим числом уязвимостей, обнаруженных практикой DAST, с разбивкой уязвимостей по критичности.
  • Серьезность уязвимостей - приложения – количество уязвимостей, обнаруженных практикой DAST, с разбивкой по критичности и по приложениям, в которых они были найдены.
  • Уязвимости, выявленные DAST, по приложениям – список приложений с данными по общему числу уязвимостей, обнаруженных практикой DAST, и числу уязвимостей с разбивкой по приложениям и по критичности с возможностью сортировки по столбцам.
К началу