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

Introduction

It has been almost half a year since the previous release of Dependency-Track v4.11. On October 1, a new release of Dependency-Track v4.12.0 was released, and recently – release v4.12.1. We have tried the new functionality and are ready to talk about the changes that seemed most interesting to us.

This release was mainly dedicated to working with tags. A new interface for working with policy violations was also added, and the rules for working with the API were changed. But first things first.

Tags

1. Alerts can be linked to projects with specific tags.

Alerts can now come not only by projects, but also by specified tags.

2. Projects can be included or excluded for BOM validation through tags.

Thus, you can enable (or disable) BOM validation for all projects, except for those assigned specific tags.

3. Projects can be tagged as part of the BOM upload request. For PUT/POST requests to api/v1/bom, a projectTags field has been added to immediately specify tags when uploading SBOM.

4. Tag fields on the frontend now offer autocomplete.

5. A new Tag Management view has appeared, allowing you to manage tags, including through REST API endpoints. Now you can track how many tags exist and to which projects, policies, and alerts they are linked. Projects, policies, and alerts can be unlinked from tags, and tags can be deleted.

The interface is a list of all tags in the system associated with projects, policies, alerts (each entity is a separate column).

You can open a dialog box that allows:

1. Fall inside — available only for the project;

2. Unlink one or more entities from this tag;

3. Delete the tag.

   

The tag can be deleted even if other entities are linked to it (i.e., it is not necessary to unlink all projects/alerts/policies attached to the tag to delete it). To delete, you need to add the TAG_MANAGEMENT right to the user or team. By default, the system administrator does not have these rights, so after updating Dependency-Track to a new version, this right needs to be added manually.

After adding the rights, you need to log in to the system again, then you can delete the tag.

Working with policies

1. Global policy violation audit interface. Similar to the global vulnerability view from version 4.11.0, this release added an interface for working with policy violations.

   Read also:

   • 5 single-board PCs for various tasks: November news

   

It is now possible to search by the following fields:

• by violation type (Fail, Warn, Info),

• by risk type (License, Security, Operational),

• by analysis status (Not Set, Rejected, Approved),

• by appearance dates,

• by policy name, license, component, and project name,

• by triggers of specific policies you have set up in Dependency-Track.

Unfortunately, long loading issues remain. As with the vulnerability interface, loading takes a significant amount of time — an average of 46 seconds for a violation volume of 44,912 triggers.

2. Added support for policies based on EPSS.

EPSS (Exploit Prediction Scoring System) allows predicting how likely a vulnerability is to be exploited.

Previously, each project already had a system for predicting exploitation based on the EPSS / CVSS chart. The closer the vulnerability is to the upper right corner of the chart, the more dangerous it is and the higher the likelihood that it will be exploited.

Therefore, having conditions in the policy that can set EPSS tracking is a very good help in vulnerability triage, especially if EPSS is specified in conjunction with the criticality of the vulnerability.

API Changes

1. The GET ​/v1​/bom​/token​/{uuid} endpoint is declared deprecated, and it is recommended to use /v1/event/token/{uuid} instead.

2. Similarly, for the GET /api/v1/tag/{policyUuid} endpoint, you can use GET /api/v1/tag/policy/{uuid} in your integrations instead.

3. Modernization. The Dependency-Track technology stack has been updated – from Swagger v2 to OpenAPI v3. As a result, the API description is available at the new address: /api/openapi.json).

4. Authentication has been added to badges.

A badge is an SVG icon with project status information. Based on the Dependency-Track analysis, it can be uploaded to the repository with the original project via the API.

Previously, Dependency-Track could export information about policy violations and the number of vulnerabilities without authentication, but this created security issues for the project, so this feature was disabled by default. In this release, unauthorized access has been marked as deprecated. Now, to upload a badge, you need to do the following:

1. Grant the team responsible for the project the VIEW_BADGES permission;

   

2. Create an API key for the team to request the badge. It can be used in the X-API-Key header or in the apiKey parameter in the URI;

3. Use the key in HTML or Markdown (examples can be found here)

This can be combined with project portfolio access control, so the key can access the Badges of a subset of projects. The link to the full documentation is here.

Additional changes

In addition to the updates described above, the Dependency-Track v4.12.0 release includes:

1. Modernization. Dependency-Track has moved from Java 17 to Java 21, from Java EE to Jakarta EE 10, from Jetty 10 to Jetty 12. We mentioned the transition from Swagger v2 to OpenAPI v3 above.

2. If Dependency-Track is installed in k8s and you use a read-only file system, the frontend container will not be able to start after the update. More details: frontend/#940.

3. The new SBOM processing method “BOM Processing V2”, which we wrote about in the previous article on v4.11, is now set by default and is the only available option.

4. A new notification type BOM_VALIDATION_FAILED has been added — now in case of BOM validation error, a notification with InvalidBomProblemDetails is sent.

5. When creating a project, you can now immediately link it to a team:

In summary

Three weeks after the release of Dependency-Track v4.12.0, no critical issues have appeared in the project's GitHub. Moreover, version 4.12.1 with minor fixes has been released, and we recommend that you upgrade to it immediately.

We consider the development towards tag management an interesting solution, and the interface for working with violated policies a logical continuation after the same interface in version 4.11.