Dependency-Track 5.2.0 Is Out

Dependency-Track 5.2.0 is now available.

Most of this release is about the CI pipelines, scanners, and scripts that talk to Dependency-Track. Until now they all used team API keys that never expire. 5.2.0 gives them identities of their own, and lets CI jobs authenticate without storing a key.

Highlights of Dependency-Track 5.2.0

• Service accounts. A service account is a named, non-human user. It gets permissions directly or through teams and has its own API keys, which expire after 30 days unless you pick another date. Suspending it stops all its keys at once, and the audit log names the service account instead of a team. Team API keys keep working, but service accounts are now the recommended way to connect integrations. The documentation has the details.
• Workload identity federation. GitHub Actions, GitLab CI, Kubernetes, and other platforms already give each job or workload a short-lived identity token. A job can now exchange that token for a session as a service account, so the CI system stores no Dependency-Track secret. Administrators decide which platforms to trust, and add bindings that say which pipelines may act as which service account, for example only builds of the main branch. It uses standard OAuth 2.0 token exchange, so existing OAuth clients work without custom code. The documentation walks through the setup.
• Control over where Dependency-Track connects. A single setting now decides where the server may connect, replacing the separate settings each subsystem had in earlier versions. It applies the same way to notifications, vulnerability data sources, package repositories, analyzers, and integrations like DefectDojo. Connections to the server’s own host and to cloud metadata addresses are blocked unless an operator allows them.
• Signed webhooks. Webhook notifications can now be signed with a secret set on the notification rule, so the receiver can check that they really came from Dependency-Track.
• Policies that skip tagged projects. Applying a license policy to every project except those tagged internal-tool no longer means tagging every other project.
• Analyzer fixes and options. Trivy no longer requires an API token. Snyk can optionally match Maven components by checksum, so it checks the artifact itself, not only its name and version. New vulnerability notifications now say which analyzer reported the finding.
• Smaller things. Operators can mount extra JDBC drivers, such as the AWS JDBC wrapper. OIDC logins accept team claims in the format AWS Cognito sends. Filtering the project list by tag, team, or classifier now shows matching child projects too. The dependency graph view loads in a few batched database queries instead of one per component, and policy checks on dependency relationships got cheaper.

Moving off long-lived API keys

A team API key has no name, no owner, and no expiry. A leaked key works until someone notices and deletes it, and unused keys pile up because nothing forces a review. The OWASP Non-Human Identities Top 10 lists keys that never expire as a risk of their own.

Expiry limits how long a leaked key works, but someone still has to create the key, store it in CI, and rotate it. Federation skips all three, and the token a job presents instead is valid for minutes. To cut a pipeline off, delete its binding or suspend the service account, which also ends its open sessions.

A sensible order is to move each integration to a service account with an expiring key first, then to federation where its platform issues identity tokens. Each team’s API key list now suggests a service account. The move is manual, though. Someone has to create the service account and its key, update the integration, and delete the old team key.

Expiring keys need a process around them, since Dependency-Track does not warn before a key expires yet. An expired key fails the same way as a wrong one, so check its expiry date in the service account view.

Upgrading

Some changes in 5.2.0 need action before or during the upgrade. Read the upgrade notes before starting.

Availability

Dependency-Track 5.2.0 is available now as container images from Docker Hub and the GitHub Container Registry. Documentation is at the project documentation site. Full release notes are published for the API server and the frontend. Dependency-Track is free and open source under the OWASP Foundation.