Аналитика

Метрики DevSecOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, и числу уязвимостей с разбивкой по приложениям и по критичности с возможностью сортировки по столбцам.

Уязвимости в 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, а также количество найденных уязвимостей.

Время обработки уязвимостей

Дашборд Время обработки уязвимостей содержит следующие метрики:

Среднее время обнаружения

MTTD (дни) (Среднее время обнаружения, Mean Time to Detect, MTTD) — это среднее время с момента начала работы над релизом (этапом) до момента обнаружения уязвимости. Учитывается только первичное обнаружение уязвимости в каждом релизе. Обнаруженные уязвимости делятся по стадиям релизного цикла (длина релизного цикла, разделенная на 4 части, по квартилям). Метрика рассчитывается в среднем за выбранный период.
Обнаруженные уязвимости - общее количество обнаруженных уязвимостей за выбранный период с разбивкой по критичности.
Изменение MTTD за период с течением времени.
Стадия обнаружения уязвимостей (Практика ИБ). Чтобы не привязываться к конкретным временным периодам, при анализе учитываются квартили релизов (считаем, что по окончании второго квартиля наступает середина релизного цикла). В идеале уязвимости должны детектироваться в первом квартиле, триажиться — во втором, исправляться — в третьем, проверяться — ближе к четвертому. Также данная метрика содержит разбивку уязвимостей по практикам ИБ, с помощью которых они были обнаружены.
Обнаруженные уязвимости (по стадии обнаружения) - эта метрика отображает динамику обнаружения уязвимостей в контексте этапов релизного цикла на выбранном промежутке времени.
Топ приложений (наиболее позднее обнаружение относительно релизного цикла) – здесь перечислены наиболее проблемные приложения по данному показателю.
Среднее время обнаружения (приложения) содержит сводную информацию по MTTD приложений в табличном виде. Для каждого приложения приведены данные по среднему релизному циклу (в днях), количеству обнаруженных уязвимостей, среднему и медианному значениям MTTD (в днях).

Среднее время триажа

MTT (дни) (Среднее время триажа, Mean Time to Triage, MTT) — это среднее время, прошедшее с момента обнаружения уязвимости до момента ее разбора (анализа) специалистом ИБ. Метрика рассчитывается в среднем за выбранный период.
Проанализированные уязвимости - общее количество проанализированных уязвимостей за выбранный период с разбивкой по критичности.
Изменение MTT за период с течением времени.
SLA триажа (практика ИБ) - SLA длительности триажа рассчитывается в сравнении с длиной релизного цикла: Быстро - если время триажа меньше четверти длительности релизного цикла, Средне - от четверти до половины релизного цикла, Медленно - от половины до 3/4 релизного цикла, Очень медленно - более 3/4 релизного цикла. Хорошим показателем считается период, укладывающийся в один квартиль.
Проанализированные уязвимости (SLA длительности триажа) - эта метрика отображает динамику MTT в контексте этапов релизного цикла на выбранном промежутке времени.
Топ приложений (наибольшее время триажа) – здесь перечислены наиболее проблемные приложения по данному показателю.
Среднее время триажа (приложения) содержит сводную информацию по MTT приложений в табличном виде. Для каждого приложения приведены данные по среднему релизному циклу (в днях), количеству проанализированных уязвимостей, среднему и медианному времени триажа (в днях).

Среднее время устранения

MTTR (дни) (Среднее время устранения, Mean Time to Resolve, MTTR) — это среднее время с момента передачи уязвимости в дефект-трекинговую систему команды разработки до ее устранения. Учитываются только переданные в разработку и устраненные уязвимости. Метрика рассчитывается в среднем за выбранный период.
Устраненные уязвимости - общее количество устраненных уязвимостей за выбранный период с разбивкой по критичности.
Изменение MTTR за период с течением времени.
SLA устранения (практика ИБ) - SLA длительности устранения рассчитывается в сравнении с длиной релизного цикла: Быстро - если время устранения меньше четверти длительности релизного цикла, Средне - от четверти до половины релизного цикла, Медленно - от половины до 3/4 релизного цикла, Очень медленно - более 3/4 релизного цикла.
Устраненные уязвимости (SLA длительности устранения) - эта метрика отображает динамику MTTR в контексте этапов релизного цикла на выбранном промежутке времени.
Топ приложений (наибольшее время устранения) – здесь перечислены наиболее проблемные приложения по данному показателю.
Среднее время устранения (приложения) содержит сводную информацию по MTTR приложений в табличном виде. Для каждого приложения приведены данные по среднему релизному циклу (в днях), количеству устраненных уязвимостей, среднему и медианному времени устранения (в днях).

Средний возраст неустраненных уязвимостей

MVA (дни) (Средний возраст уязвимости, Mean Vulnerability Age, MVA) — это среднее время, прошедшее с момента обнаружения уязвимости до момента измерения (текущего момента). Учитываются только неустраненные на момент измерения уязвимости. Метрика рассчитывается на текущий момент или конец выбранного периода и в динамике.
Неустраненные уязвимости (конец периода) - общее количество неустраненных уязвимостей на конец периода с разбивкой по критичности.
Изменение MVA за период с течением времени.
Соответствие SLA (практика ИБ), конец периода - SLA среднего возраста рассчитывается в сравнении с длиной релизного цикла: менее половины релизного цикла, от 0.5 до 1 длительности релизного цикла, от 1 до 2 релизных циклов, боле 2 релизных циклов.
Неустраненные уязвимости (соответствие SLA), динамика - эта метрика отображает динамику MVA в контексте продолжительности релизного цикла на выбранном промежутке времени.
Топ приложений (с наибольшим средним возрастом уязвимостей), конец периода – здесь перечислены наиболее проблемные приложения по данному показателю.
Средний возраст неустраненных уязвимостей (приложения), конец периода содержит сводную информацию по MVA приложений в табличном виде. Для каждого приложения приведены данные по среднему релизному циклу (в днях), количеству неустраненных уязвимостей, среднему и медианному возрасту уязвимостей (в днях).

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

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

Открытая уязвимость (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 для каждого уровня серьезности.

Дефекты ИБ

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

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

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

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

Эта метрика дает возможность грамотно приоритизировать работу с упором на долю проблем, требующих немедленного внимания.
Средний возраст дефекта (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 дня до недели" и далее по возрастанию.

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

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

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

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

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

Отчет по приложениям

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

Сканирование и покрытие практиками ИБ

Примечание

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

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

Частота сканирования (Security scan frequency). Частота сканирования равна количеству запусков сканирований ИБ за период. Частота сканирования должна соответствовать количеству изменений и частоте релизов приложений. Высокое значение показывает, что анализируется каждое изменение, уязвимости идентифицируются на ранних стадиях. Это является показателем сдвига влево (Shift left).
Среднее время успешных сканирований (Security scan time) – это среднее количество времени, которое занимает одна успешно завершенная проверка ИБ (от запуска до получения результата). Метрика показывает среднюю скорость работы инструментов ИБ. Значения выше ожидаемых могут говорить о неэффективности или неверной настройке используемых сканеров или неоптимальном использовании вычислительных ресурсов.
% пройденных контрольных точек (Passed Security Gates Ratio) - это отношение сканирований с успешно пройденными точками контроля (критериями качества, quality gates) к общему количеству сканирований (закончившихся успешно и неуспешно). Низкое значение метрики указывает то, что команды не справляются с выставленными критериями качества.
% поврежденных пайплайнов (Broken Scan Rate). Отношение незавершенных (broken) сканирований к общему числу сканирований за период.
Количество запусков по дням отображает в календарном виде число выполненных каждый день сканирований. Дни выделены различными цветами в зависимости от количества запусков. Точное число сканирований отображается при наведении курсора на выбранный день.

Покрытие пайплайнами

Покрытие практиками AppSec показывает, какая часть элементов ПО, относящихся к приложениям, покрыты практиками DevSecOps (т. е. для них настроены пайплайны) от объема зарегистрированных в AppSec.Hub. Целевое значение для метрики рассчитывается исходя из уровня внедрения DevSecOps.
% покрытия, динамика отображает изменение покрытия практиками AppSec с течением времени.
Покрытие практиками AppSec элементов ПО содержит сводную информацию по покрытию практиками AppSec элементов ПО в табличном виде. Для каждого типа элементов ПО (кодовые базы, артефакты, стенды) приведены количество элементов и процент покрытия практиками.
Покрытые практиками элементы, динамика - эта метрика отображает количество элементов ПО, охваченных и неохваченных практиками ИБ, на выбранном промежутке времени.

Применение практик ИБ

На текущую дату/конец периода - эта метрика показывает, какая часть элементов ПО, относящихся к приложениям, сканируются вовремя (элемент приложения сканировался хотя бы один раз в последний целевой период) от объема покрытых пайплайнами. Данные приводятся отдельно по практикам SAST, SCA и DAST. Целевой показатель применения практик ИБ при внедренном DevSecOps должен стремиться к 100%. Целевой период сканирования устанавливается в настройках приложения в AppSec.Hub, по умолчанию составляет 90 дней.
% применения практик ИБ, динамика отображает изменение применения практик AppSec с течением времени. Приводятся суммарный показатель и отдельные данные по практикам SAST, SCA и DAST.
% применения практик ИБ по типам элементов (конец периода) содержит сводную информацию по применению практик AppSec в табличном виде. Для каждого типа элементов ПО (кодовые базы, артефакты, стенды) приведены количество элементов и процент применения практик SAST, SCA и DAST.
Применение практик ИБ к элементам ПО, динамика - эта метрика отображает количество элементов ПО, которые сканируются или не сканируются вовремя, на выбранном промежутке времени.

Отчет по несканируемым элементам

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

Внизу дашборда расположена Сравнительная таблица покрытия приложений и применения практик ИБ (текущая дата/конец периода) с данными по каждому приложению. В ней отражены: целевой период сканирования, количество элементов ПО в каждом приложении, количество выполненных сканирований за последний целевой период, а также показатели, связанные с покрытием и применением практик ИБ в каждом приложении.

Риски ИБ

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

Технический долг ИБ (Security Technical Debt, STD) является базовой и наиболее интуитивно понятной метрикой для оценки риска ИБ приложения. Он равен количеству неисправленных уязвимостей приложения, доступных для эксплуатации в промышленной среде. Технический долг ИБ измеряется на момент выпуска релиза. Если данные о релизах не заполнены, STD определяется как количество неопровергнутых и неисправленных уязвимостей.

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

Плотность риска ИБ рассчитывается как количество неисправленных уязвимостей приложения на 1000 строк кода (1000(K) Source lines of code, КSLOC). Учитываются только неисправленные проблемы в промышленной среде с учетом их серьезности, и значимые строки кода без пробелов и комментариев. Risk Density определяет долю проблем безопасности в вашем коде к его объему. Может дать представление о качестве кода при разработке приложений.
Взвешенный индекс риска (Weighted Risk Index, WRI) также углубляет метрику STD, позволяя одним числом показать подверженность риску, учитывая критичность (как уязвимостей, так и самих разрабатываемых приложений). Компания может разрабатывать десятки и сотни продуктов, и не все они имеют одинаковый уровень риска. Риск-профиль приложения зависит от величины финансовых, юридических, клиентских и репутационных потерь при успешной атаке.

WRI - это произведение суммы неисправленных уязвимостей приложения, доступных для эксплуатации в промышленной среде, взвешенных с учетом серьезности и индекса риска приложения. WRI измеряется на момент выпуска релиза и позволяет сравнить приложения между собой по степени риска – чем выше серьезность уязвимостей, тем выше будет значение метрики. Здесь критичные для бизнеса системы будут иметь показатель выше, чем системы уровня office productivity при равном количестве вышедших в промышленную среду уязвимостей.

Технический долг ИБ (Security Technical Debt, STD)

STD на конец периода - общий технический долг ИБ для всех приложений с разбивкой по критичности уязвимостей.
STD приложений на конец периода - технический долг ИБ для каждого приложения.
Изменение тренда технического долга ИБ (STD) с течением времени с разбивкой по критичности уязвимостей.
Изменение тренда технического долга ИБ (STD) приложений с течением времени с разбивкой по приложениям.

Плотность риска ИБ (Risk Density)

Плотность риска (Risk density), динамика - эта метрика отображает изменение плотности риска с течением времени.
Технический долг ИБ (Security Technical Debt - STD) - уязвимости в ПРОД - изменение общего технического долга ИБ для всех приложений с разбивкой по критичности уязвимостей с течением времени.
Изменение размера исходного кода с течением времени.

Взвешенный индекс риска (Weighted Risk Index, WRI)

WRI на конец периода для каждого приложения.
Изменение тренда взвешенного риска - по неделям с разбивкой по приложениям.
WRI приложений на конец периода содержит сводную информацию по WRI приложений в табличном виде. Для каждого приложения приведены значения WRI (по уязвимостям), WRI (по критичным уязвимостям), количество уязвимостей, процент критичных уязвимостей (уровней high и critical) и размер приложения (SLOC).