Dashboard for Security issues inside XWiki Standard

Hello all,

This post is in the context of Display security issues directly inside XWiki Standard (in summary, being able to display known security issues of installed extensions in the wiki), with a focus on the dashboard and its content.

The dashboard would be displayed in a new section in the administration (I’m thinking of Extensions -> Security Dashboard).

Following a discussion with @tmortagne we realized that the information could be presented in two ways:

  1. one row per extension with known vulnerabilities
  2. on row per vulnerability

While a focus on vulnerabilities can be interesting, we agreed that the first goal is to know which extensions have know vulnerabilities, and the details of which ones comes second.

Therefore, I propose to list the following information:

Column Name Content Example
Name Refactoring Application + link to http://localhost:8080/xwiki/bin/admin/XWiki/XWikiPreferences?section=XWiki.Extensions&extensionId=org.xwiki.platform%3Axwiki-platform-refactoring-ui&extensionVersion=15.4
Current Version 15.4
Id org.xwiki.platform:xwiki-platform-refactoring-ui
Max CVSS 8.4
CVEs link to CVE1, link to CVE2, […], link to CVE5
Number of CVEs 5

Which would be displayed as follows (see the design page for more details on the content of the columns, filtering, etc.)

dashboard mockup

Let me know if this is the correct way to present information, or if you think some column should be added.
And if the location as an entry in the administration is the right one.


It’s not very clear what you exactly mean by “current”, what is current installed (which is what “current” feels like in this context) or the latest compatible version found in the index (which is what you have in the Name column seems to indicate, but in this case we should probably indicate what is currently installed somewhere) ?

For the CVE column I would only display the CVE id (and have it be a link to nvd probably).


I have a few suggestions regarding this table:

  • For core extensions, proposing an update doesn’t seem that useful as in most cases this is a bad idea/not even possible. I think we should clearly mark core extensions to make this clearer to admins. Maybe even mention if an XWiki version upgrade is required before the table.
  • It might be good to indicate if an update to a fixed version is available (should always be with our current policy but there might be situations where it isn’t, like for an unmaintained extension). If there is no upgrade available, uninstalling the extension could be suggested. It could be good to indicate both the first version for which no vulnerabilities are known and the latest available version.
  • I think the score will say nothing to most admins. Indicating the severity as string (low/medium/high/critical) seems more useful to me, maybe even with a colored background. The numeric value could still be indicated and used for sorting. A concrete example I imagine could be Critical (9.9/10).

Sounds good to me, thanks.

What is the purpose of knowing the extension id for the user?

Wrong link, the good one is: List security issues inside XS (Proposal.ListSecurityIssuesInsideXS) - XWiki

What do you do if there are, say 50 CVEs?

Is the version the latest version available? If you’re on a LTS branch does it propose the latest LTS tag?

I’d have added a column named “Suggested Upgrade” displaying a version and link to the EM to upgrade. And in the name column I’d have put a link to the documentation page (if it exists) so that the user knows what extension it’s about.

I was about to suggest to add a fix version column. In our CVE I think there’s always a fix version, so always a possible update (which doesn’t mean that it’s possible for the users to update but we don’t know that until we computed the update plan). Now it’s not necessarily always true (?) so maybe we should indeed plan when there’s no fix version for a CVE…

Hopefully we don’t :wink: but in this case one entry would take a lot of vertical space.
I feel like it’s a marginal case that we don’t need to address (at least not for the MVP)

Actually, following Thomas’s idea of only displaying the CVE id, a comma-separated list would work fine.

Another idea would be to put a single link that lists all the CVEs for a given id (if it’s possible to find such a URL for nvd).

First version implemented in Loading...