Vulnerability Triage Process

This document describes the triage process for new security vulnerabilities reported by the security scanners (as of the time of writing, trivy, reported into the security dashboard).

Caveats and Notes

As with most things, there is no one size fits all solution. As such, the authors of this document acknowledge that this process may need to be deviated from from time to time. Nonetheless, it is the hope of the authors that this process is appropriate for most vulnerabilities reported.

Likewise, this process is only applicable to new vulnerabilities. In case of a non-trivial unaudited backlog a more lightweight triage process needs to be used.

Lastly, special care needs to be placed on issues that are marked as Has known exploits. When in doubt, the created issue should then be marked as "internal" or replaced by an e-mail to the security of the respective component or CIVITAS/CORE (see also).

Process description

In the following, we define a step-by-step guide on how to triage and assess reported vulnerabilities.

Nota Bene: This list is numbered, but due to markdown restrictions it is also bulleted to achieve correct indentation. The authors are ever so sorry.

• 1. Identify the root container/component. This can be done either in the overview (bottom line) or the detail view of a vulnerability (line demarkated with Image:). If the line contains a -> arrow, the Docker image on the left is the component, and the one on the right the image that is the root cause of the issue (e.g. a base image).
• 2. Check for whether the affected component has a corresponding issue in the component issue tracker. Check if the component has a corresponding issue.
  • 2a. If so, check if there is an update available.
    • 2aa. If there is an update available, move on to step 3.
    • 2ba. If there is no update available, file an issue in the CIVITAS/CORE issue tracker to update the affected component when an update is made available. You are then done with this process for now.
  • 2b. If there is no corresponding issue, check if there is an update that resolves the underlying issue anyway through an update.
    • 2ba. If there is an update available, move on to step 3.
    • 2bb. If there is no update available, file an upstream issue and an issue in the CIVITAS/CORE issue tracker than refers to that issue. Unless you want to work on fixing this yourself, you are then done with this process for now.
• 3. Ensure that the vulnerability is not captured by an outstanding update/merge request. Before panicking, make sure that there are no outstanding merge requests or issues that already capture the vulnerability. If so, leave a comment on the issue or merge request kindly informing the parties working on them that there is an issue that would be resolved by this update. If there is an outstanding issue, you are done with this process.
• 4. File an issue to update the affected component. You do not have to rush to action (unless you want to and have time to do so), filing an issue that the component needs to be updated for security reasons is enough.

When creating an issue, feel free to use the button at the bottom of the issue’s detail page labelled Create issue. It will prefill some values, but might not reflect the state of your investigation, so some manual work on the wording will be required.

If the upstream component is not fixed in a reasonable amount of time (what constitutes reasonable is always case-specific), the team should consider contributing a fix themselves if technically feasible. If a component is unmaintained or maintainers are unwilling to fix issues that constitute exploitable security risks (non-exploitability must be reasonably justified), consider exchanging the component altogether or forking it if the maintenance burden can be tolerated.

Process frequency and expected timelines

Triage should happen at least once a week.

Critical and High severity issues should complete the triage process immediately. For medium and lower vulnerabilities, this may be postponed, but it should be tracked via the issue tracker if it is.

Other notes

The severity of an issue should usually not be reset manually. If there is a Critical or High severity issue that is definitely not exploitable (e.g. the component is not used or the affected module is not shipped), it may be demoted to Low to keep the backlog clean and a note should be added to the vulnerability.

If you have the permissions to edit a vulnerability, you can also dismiss a vulnerability if applicable. See the GitLab documentation for more detail. This should only be done if the vulnerability can definitely be dismissed, and "Acceptable Risks" should be discussed internally beforehand.