А выгрузи-ка мне отчётик из инструмента: обзор dt-report-generator

от автора

Всем привет! Сегодня хочу рассказать вам про свой инструмент, который помогает автоматически выгружать отчёты из OWASP Dependency Track. Этот инструмент я разработал с целью упростить процесс работы с отчётами и сделать его доступным даже для тех, кто ранее мог испытывать трудности с анализом данных напрямую из Dependency Track.

Почему нужен инструмент для выгрузки отчётов?

OWASP Dependency Track — мощный инструмент композиционного анализа, который позволяет отслеживать зависимости проекта и выявлять уязвимые из них. Однако штатных средств для выгрузки данных в нем нет. Пользователи либо работают через веб-интерфейс, либо прибегают к помощи сторонних решений класса ASOC (Application Security Orchestration and Correlation) / ASPM (Application Security Posture Management) / VM (Vulnerability Management).

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

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

Но что делать, если вам нужно просто и быстро экспортировать данные для анализа или для передачи руководству в удобном формате? Например:

  • Подготовить таблицу с результатами сканирования для аудита.

  • Собрать отчёт для compliance.

  • Быстро проанализировать результаты разового сканирования внутреннего проекта.

Вот здесь и приходит на помощь dt-report-generator.

Функциональные возможности и сценарии использования

dt-report-generator предоставляет простой и интуитивно понятный веб-интерфейс. Вы заполняете несколько параметров через форму и мгновенно получаете отчёт в одном из поддерживаемых форматов.

Основные возможности:

  • Поддержка форматов: выгрузка отчётов доступна в формате .docx (для текстовых отчётов) и .xlsx (для табличных данных).

  • Совместимость: инструмент работает с версиями OWASP Dependency Track начиная с v4.10.0. Не исключено, что и с предыдущими версиями будет отлично работать (если не было изменений в API), но не тестировал — не пишу.

  • Гибкость в развертывании: вы можете развернуть dt-report-generator как локальный сервис или установить его в инфраструктуре вашей организации. Это особенно полезно для компаний, которые часто проводят разовые сканирования.

Когда это полезно:

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

  • Когда требуется автоматизация процесса генерации отчётов для аудитов, compliance или других проверок.

Пошаговое руководство по использованию

Давайте на примере разберем кейс использования «от и до»:

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

  1. Открыв терминал, клонируем репозиторий

git clone <https://github.com/denimoll/dt-report-generator.git>
  1. С использованием Docker (инструкция по установке) разворачиваем сервис

docker build -t dt-report:v1 . # собираем образ контейнера docker run -d -p 5000:5000 dt-report:v1 # запускаем контейнер
  1. В браузере переходим по адресу localhost:5000 и видим сие чудо

1.png

Интерфейс
  1. Для получение отчёта заполняем форму и жмём «Get report»

    • URL — адрес вашего Dependency Track. Например, https://dependencytrack.org.

    • Token — API ключ (инструкция по получению)

    • Project — ID проекта (параметр Object Identifier в Project Details или идентификатор из URL после .../projects/)

    • Severities — интересующие уровни критичности

    • Report type — формат отчёта

Под капотом выполняется обращение к ручкам:

  • /api/v1/project/<id> # информация о проекте

  • /api/v1/component/project/<id> # используемые компоненты

  • /api/v1/vulnerability/project/<id> # уязвимости в компонентах

На выходе получаем примерно следующее:

docx-документ:

Стартовая информация о проекте и таблица уязвимых компонентов, критичность уязвимостей которых соответствует значению параметра Severities из формы

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

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

excel-документ:

Вкладка “Общая информация”

Вкладка «Общая информация»
Вкладка “critical, high, medium компоненты”. Название и содержание зависит от выбранных уровней в параметре Severities в форме

Вкладка «critical, high, medium компоненты». Название и содержание зависит от выбранных уровней в параметре Severities в форме
Вкладка “Все срабатывания”

Вкладка «Все срабатывания»
  1. Подзабыли о сервисе, ребутнули машину, хочется ещё. Не беда, просто запускаем существующий контейнер и побежали на localhost:5000 снова.

docker start <container id или name> # запускает конейнер

Перспективы развития

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

На ближайшее будущее у меня есть несколько идей, как сделать dt-report-generator ещё лучше:

  1. Форматы отчётов. Добавить новые форматы и/или скорректировать существующие.

  2. Поиск проектов. Упростить поиск проектов через предоставленную ссылку и токен.

  3. Дашборды с обзорной информацией. Визуализировать данные в виде различных графиков для наглядного анализа.

  4. Приоритезация уязвимостей. Реализовать логику, которая поможет оценить, какие уязвимости требуют первоочередного исправления (идея уже в процессе разработки, и я надеюсь скоро представить её).

  5. Безопасность. Прикрутить Dependabot’а, добавить SAST проверки.

  6. Релизная политика. Сформировать правила выпуска релизов и публиковать сразу Docker-образы.

Если инструмент найдет себе место в узком кругу пользователей, то буду дополнять информацию по часто задаваемым вопросам на GitHub (например, как решать распространенные проблемы при установке или использовании).

Спасибо за внимание и приятной работы с инструментом! 😊


ссылка на оригинал статьи https://habr.com/ru/articles/860536/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *