Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Postpone deprecation of unauthenticated access to Badge API #4502

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 10 additions & 7 deletions docs/_docs/integrations/badges.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,22 +8,25 @@ order: 10
Dependency-Track supports badges in Scalable Vector Graphics (SVG) format. Support for badges is configurable on a team
basis via permission or globally for unauthenticated access.

> **Deprecation Notice**
>
> Unauthenticated access to badges as a global configuration is deprecated and slated for removal in Dependency-Track
> v4.13.

To enable badges for a team, activate the permission `VIEW_BADGES`. To deactivate badges, remove the permission. To
retrieve a badge, use a team's API key either in the badge API header `X-API-Key` or in the URI parameter `apiKey`.

As a legacy feature, badges can also be accessed without authentication. On new Dependency-Track installations, this is
As an alternative, badges can also be accessed without authentication. On new Dependency-Track installations, this is
disabled by default. On Dependency-Track installations updated from ≤ v4.11, where (unauthenticated) badge support
was enabled, badges will remain accessible for unauthenticated requests. If this is disabled, badges will be accessible
for authenticated and authorized requests.

> Enabling unauthenticated access to badges will provide vulnerability and policy violation metric information to
> unauthenticated users. Any anonymous user with network access to Dependency-Track and knowledge of a projects
> information will be able to view the SVG badge.
>
> It is however offered as an alternative in case publishing badge URLs containing an API key raises security concerns
> or compliance issues with your Dependency-Track installation.
> Be aware of the following risks that go with publishing API keys, even if scoped entirely to badges:
> * a developer could accidentally commit and push the wrong API key in the Dependency-Track badge URL, e.g. in their
> project's README.md, and thus publish a secret API key, creating a security incident
> * contradicts common compliance rules to never publish secrets like API keys, raising the complexity of a
> technological environment.

Dependency-Track ships with a default team "_Badge Viewers_" dedicated to badges that already has the necessary
permission and an API key.
Expand All @@ -32,7 +35,7 @@ permission and an API key.
> for the badge request should have minimal scope to prevent unintended access beyond that badge. Ideally, the API
> key belongs to a single-purpose team, having just the `VIEW_BADGES` permission, with only one API key and access to
> only the projects/project versions whose badges are displayed at one site--the latter requiring _Portfolio Access
> Control_.
> Control_.

In all following examples, replace `{name}`, `{version}`, `{uuid}`, and `{apiKey}` with their respective values. For
brevity, the examples use the URI query parameter as the method of authentication, however, they also work with
Expand Down
Loading