List security issues inside XS
- XWiki
- Design
- Active
Description
- Requirements
- Implementation
- UC1: collect the CVEs for installed extensions
- UC2: Provide a dashboard to list the CVEs
- UC3: Inform Admins of existing CVEs on the notifications pane
- UC4: admins should be able to configure the scheduler
- UC103: provide additional contextual information for known CVEs
- UC106: be able to run the CVEs collection from maven
Requirements
The goal of this extension is to list relevant CVEs inside the wiki, to inform admins of security issues impacting the current wiki instance.
Requirements for MVP
- UC1: collect the CVEs for installed extensions

- UC2: Provide a dashboard to list the CVEs

- UC3: Inform Admins of existing CVEs on the notifications pane

- UC4: admins should be able to configure the scheduler

Additional requirements (future versions)
- UC101: collect the CVEs for core extensions
- UC102: notify users with admins rights

- UC103: provide additional contextual information for known CVEs (e.g., to explain why a CVE is not relevant in the context of XWiki Standard)
- UC104: display the CVEs in the EM admin page in addition to the dashboard
- UC105: provide a manual mapping between extension id and CVEs (e.g., in the case where a CVE is linked to a javascript artifact that we use through webjars)
- UC106: be able to run the CVEs collection from maven, to be able to be informed of vulnerabilities early (at build time).
Implementation
UC1: collect the CVEs for installed extensions
- Identify a good source of CVEs. See https://forum.xwiki.org/t/source-of-cves-for-the-security-dashboard/12623 the chosen default source is https://osv.dev/
- The collection is executed first when the extensions indexing is done, then once every X hours (24 by default)
- for each known extension, run a query to get the CVEs impacting the current extension version

- update the EM solr core to have a field to store the CVEs details

- provide an API to access the CVEs

- for each known extension, run a query to get the CVEs impacting the current extension version
UC2: Provide a dashboard to list the CVEs
Additional information:
- date of last update dd/mm/yyyy hh:mm (or the local format)
- status of last update: success/failure/deactivated + explanation

Use the Live Data Macro with a custom source to list and filter the known CVEs
| Column Name | Type | Filterable | Sortable | Content Example | Note |
|---|---|---|---|---|---|
| Name | link | true (ignore case + substring) | true | 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 for easier upgrade | |
| Extension ID | String | true (ignore case + substring) | true | org.xwiki.platform:xwiki-platform-refactoring-ui/15.4 | |
| Wikis | String | true | false | xwiki, subwiki, subwiki2 | |
| Max CVSS | Float | true | true | 8.4 | |
| CVE IDs | html | true | false | link to CVE1 (4.5) link to CVE2 (8.4) [...] link to CVE5 (7.3) | |
| Latest Fix Version | String | true | false | 15.4 | The closest version where the issue is fixed |
| Advice | String | false | false | An explanation in natural language explaining what to do to fix the security issue. |
UC3: Inform Admins of existing CVEs on the notifications pane
Use the Alerts UIXP to display and additional section in the notification pane where at least one CVEs is listed.
UC4: admins should be able to configure the scheduler
By default, UC1 polls the new CVEs periodically.
Admins should be able to:
- deactivate the polling
- configure the url of the CVEs source endpoint.

UC103: provide additional contextual information for known CVEs
Some vulnerabilities can be available for a given extension id. But, after further review, is identified as non-applicable in the context of XWiki or one of it extension.
Therefore, it should be possible to emit a Review for a CVE (possibly specifically for a given ExtensionID).
But, the Review can be relevant only in the context of another extension depending on the extension with an associated CVE. In this case, it should be possible to explicit the scope for which the review is applicable
Conceptual Diagram
Rest Endpoint
Schema
openapi: 3.1.0
info:
title: Security List
contact: {}
description: Security List
version: 1.0.0
paths:
# Whole board operations
/reviewedVulnerabilities:
get:
summary: Get the reviews
operationId: ok
tags: ["ok"]
description: Get the review
responses:
"200":
description: "OK"
content:
application/json:
schema:
type: object
properties:
reviewedVulnerabilities:
type: object
properties:
cveId:
type: array
items:
type: object
properties:
explanation:
type: string
scope:
type: string
impact:
type: string
enum:
- safe
- unsafe
servers:
- url: 'http://localhost:8080'Examples
CVE with only safe reviews
{
"reviewedVulnerabilities": {
"cve-id-123": [
{
"explanation": "This CVE is safe because XXX",
"impact": "safe",
}
]
}
}CVE with safe reviews on a single extension and not for another one
{
"reviewedVulnerabilities": {
"cve-id-123": [
{
"explanation": "This CVE is safe because XXX",
"scope": "xwiki-platform",
"impact": "safe",
}, {
"explanation": "This CVE is NOT safe because YYYY",
"scope": "org.xwiki.contrib:my-app",
"impact": "unsafe",
}
]
}
}UC106: be able to run the CVEs collection from maven
Existing maven plugin with the same scope https://github.com/fasten-project/fasten-maven-plugin