Current Behavior

The current implementation of the authenticated Badge API uses API keys as URL parameters for authn and authz. This was done as a natural way to limit access to Dependency-Track badges to specific projects/project-versions, while still allowing a broad and simple use of the badges, e.g. in Readme Markdowns in GitHub.

#4227 brought to attention some dangers that come with that implementation:

• human error: a developer could accidentally commit and push the wrong API key in the DT badge URL in their Readme, thus creating a security incident
• sets a bad example: contradicts common compliance rules to never publish secrets like API keys, raising the complexity of a technological environment.

So alternative solutions to API keys in URLs should be explored. Until then, API keys should not be enforced for badges and thus the unauthenticated access to badges should remain an alternative.

Proposed Behavior

To allow the use of badges without having to an publish an API key, keep the option to enable unauthenticated access to badges beyond Dependency-Track 4.12.

For this, we could either remove just the removal notice for 4.13, or remove the deprecation altogether. The latter feels more appropriate though:
a functionality should become deprecated when there's a newer one that is planned to replace the current one. But since the new functionality (authenticated Badge API access) has been argued to be flawed, and should thus be reconsidered in favor of a better implementation, why continue calling it deprecated when the replacement likely isn't the final form and a better one isn't known yet?

So the proposal is:

• remove the text about the deprecation of unauthenticated access from the docs and frontend, and removal of unauthenticated access in Dependency-Track 4.13 from the docs
• bring the various security implications of either approaches to badges (unauthenticated and authenticated but with API keys) to the users' attention in the docs.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested