Dependency-Track v4.12: обзор обновлений

Введение

Прошло почти полгода с момента предыдущего релиза Dependency-Track v4.11 (о котором мы также писали в этой статье). 1 октября вышел новый релиз Dependency-Track v4.12.0, а на днях – релиз v4.12.1. Мы опробовали новый функционал и готовы рассказать о тех изменениях, которые показались нам наиболее интересными.

Этот релиз в основном был посвящен работе с тегами. Также был добавлен новый интерфейс для работы с нарушениями политик и изменены правила работы с API. Но обо всем по порядку.

Теги

1. Алерты могут быть привязаны к проектам с определенными тегами.

Оповещения теперь могут приходить не только по проектам, но и по заданным тегам.

2. Проекты могут быть включены или исключены для валидации BOM через теги.

Таким образом можно включить (или отключить) валидацию BOM для всех проектов, за исключением тех, которым присвоены определенные теги.

3. Проекты могут быть тегированы как часть запроса загрузки BOM. Для запросов PUT/POST на api/v1/bom добавилось поле projectTags, чтобы сразу указывать теги при загрузке SBOM.

4. Поля с тегами на фронтенде сейчас предлагают автозаполнение.

5. Появилось новое представление Tag Management, благодаря которому можно управлять тегами, в том числе через REST API эндпоинты. Теперь можно отслеживать, сколько тегов существует и к каким проектам, политикам и алертам они привязаны. Проекты, политики и алерты могут быть отвязаны от тегов, а теги могут удаляться.

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

Можно открыть диалоговое окно, позволяющее:

1. Провалиться внутрь — доступно только для проекта;

2. Отвязать одну или несколько сущностей от данного тега;

3. Удалить тег.

   

Тег можно удалить даже в случае, если к нему привязаны другие сущности (то есть необязательно отвязывать от тега все прикрепленные к нему проекты/алерты/политики, чтобы удалить его). Для удаления необходимо добавить пользователю или команде право TAG_MANAGEMENT. По умолчанию , администратор системы не имеет данных прав, так что после обновления Dependency-Track на новую версию это право нужно добавить вручную.

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

Работа с политиками

1. Глобальный интерфейс аудита нарушений политик. Аналогично глобальному представлению уязвимостей из версии 4.11.0 в этом релизе был добавлен интерфейс для работы с нарушениями политик.

   

Появилась возможность поиска по следующим полям:

• по типу нарушения (Fail, Warn, Info),

• по типу риска (License, Security, Operational),

• по статусу анализа (Not Set, Rejected, Approved),

• по датам появления,

• по названию политики, лицензии, компоненту и имени проекта,

• по срабатываниям конкретных политик, заведенных вами в Dependency-Track.

Увы, проблемы с долгой загрузкой остаются. Как и в случае с интерфейсом для уязвимостей, загрузка занимает значительное время — в среднем 46 секунд для объема нарушений, равного 44912 срабатываниям.

2. Добавлена поддержка политик на основании EPSS.

EPSS (Exploit Prediction Scoring System — прогноз эксплуатации уязвимости) позволяет предсказать, насколько вероятна эксплуатация той или иной уязвимости.

Ранее для каждого проекта уже существовала система предсказания эксплуатации на основании графика EPSS / CVSS. Чем ближе уязвимость к верхнему правому краю графика, тем более она опасна и тем выше вероятность, что она будет проэксплуатирована.

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

Изменения в API

1. Ручка GET ​/v1​/bom​/token​/{uuid} объявлена как устаревшая (deprecated), вместо неё предлагается использовать /v1/event/token/{uuid}.

2. Аналогично с ручкой GET /api/v1/tag/{policyUuid}, можно использовать вместо неё GET /api/v1/tag/policy/{uuid} в своих интеграциях.

3. Модернизация. Технологический стек Dependency-Track был обновлен – c Swagger v2 на OpenAPI v3. В связи с этим описание API доступно по новому адресу: <hostname>/api/openapi.json).

4. Добавлена аутентификация в бейджи.

Бейдж (badge) – это SVG-значок с информацией о состоянии проекта (подробнее здесь.) На основании анализа Dependency-Track его можно загружать в репозиторий с оригинальным проектом через API.

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

1. Выдать команде, ответственной за проект, право VIEW_BADGES;

   

2. Создать API-ключ команды для запрашивания бейджа. Его можно использовать в заголовке X-API-Key или в параметре apiKey в URI;

3. Использовать ключ в HTML или в Markdown (примеры можно посмотреть здесь)

Это можно объединить с контролем доступа к портфелю проектов, так что по ключу можно получить доступ к Badges подмножества проектов. Ссылка на полную документацию здесь.

Дополнительные изменения

Кроме описанных выше обновлений, в релиз Dependency-Track v4.12.0. были добавлены:

1. Модернизация. Dependency‑Track переехал с Java 17 на Java 21, с Java EE на Jakarta EE 10, с Jetty 10 на Jetty 12. Про переход со Swagger v2 на OpenAPI v3 мы упомянули выше.

2. Если Dependency‑Track установлен в k8s и вы используете read‑only файловую систему, контейнер frontend не сможет запуститься после обновления. Подробнее: frontend/#940.

3. Новый способ обработки SBOM «BOM Processing V2», о котором мы писали в прошлой статье по v4.11, сейчас настроен по умолчанию и является единственной доступной опцией.

4. Добавлен новый тип нотификации BOM_VALIDATION_FAILED — теперь в случае ошибки валидации BOM отправляется уведомление с InvalidBomProblemDetails.

5. При создании проекта теперь можно сразу привязать его к команде:

Подводя итог

За три недели после релиза Dependency‑Track v4.12.0 в GitHub проекта не появилось критических issue. К тому же вышла версия 4.12.1 с небольшими исправлениями, и мы рекомендуем вам переходить сразу на нее.

Мы считаем развитие в сторону менеджмента тегов интересным решением, а интерфейс работы с нарушенными политиками — логичным продолжением после такого же интерфейса в версии 4.11.