Support for Badges

[msymons]

It would be useful if Dependency-Track Server implemented support for "badges". ie, as available in more recent versions of SonarQube Server, from Jenkins Embeddable Build Status Plugin, and seen all over GitHub with repos displaying badge for Travis, etc.

This would provide current info to the viewer of the badge and a link to the project within DT.

I think that this does not go against the DT philosophy of "no reporting tools" because what is displayed would be current (dynamic). DT is still the source of truth.

The current API has:

/v1/metrics/project/{uuid}/current

...although this does not cater for license metrics.

For implementation, the icon for vulnerabilities might display something similar to what is already displayed in DT:

(although perhaps something not quite so wide might be preferable).

The badge would be useful in GitHub, Confluence, etc. Additionally, could it be used by dependency-track plugin to display status within Jenkins? Especially if synchronous mode is not being used.

[stevespringett]

I like this idea and likely wouldn't be hard to implement.

Basically, we'd have a new API that would dynamically generate svg's from the existing metrics.

[stevespringett]

Here are actual SVGs to serve as the basis for this feature going forward.

No Vuln Example
https://gist.github.com/stevespringett/72795f003307596e344584bd0ac0c18e

With Vulns Example
https://gist.github.com/stevespringett/41944c29349ff18a81e4e57f2e509eb1

[stevespringett]

Badges need to be displayed on external sites without requiring authentication. This is an information disclosure vulnerability and could be leveraged by adversaries during recon. Therefore a new permission: PORTFOLIO_METRICS or BADGES or similar, should be created.

The permission should be assigned to a dedicated user or team and the API key supplied on the URL to the badge. Possibly even create a “badge” user by default on new systems and upgrades.

So although the API key will be in a GET, it should be the only key associated to a user/team as to prevent unauthorized access. However, by doing this, it would then be possible to restrict what projects have badge data available and which ones do not / or use different keys for access once #140 is implemented. The key could always be revoked thus preventing all existing access from working.

[stevespringett]

I think the permissions would be a good future enhancement, however, for MVP, there will be a checkbox (disabled by default) that provides the capability to generate badges.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.