Vulnerability register
One row per CVE, two display modes over one dataset, and what every column in the register means.
The register holds one row per CVE. The feed arrives at a finer grain — one row per vulnerability and affected server — and ingest folds it into a single row per vulnerability, carrying the server list, the products and the patch together.
Two display modes, one dataset
A switch in the toolbar changes how the same rows are presented.
| Mode | Row grain | What it is for |
|---|---|---|
| By patch (default) | Patch | Deciding what to schedule. Working by patch |
| By CVE | Vulnerability | Editing, archiving and deleting a record |
Each mode carries its own saved views and its own filters: they share no column, and a view built on one would land on the other as an empty filter set.
Columns in By CVE mode
| Column | What it holds |
|---|---|
| CVE | The identifier, with the title beneath it |
| Patch | The patch that closes the vulnerability; older records show a KB number instead |
| Title | A short free-text description |
| Type | A one- or two-word class label — RCE, privilege escalation |
| Severity | The level, with the CVSS score beside it |
| Product | The affected products |
| Operating system | The OS family, with the version pattern beneath it if one was recorded |
| Servers | How many servers the feed named |
| Patch date | When the patch was released |
| Status | The handling state |
The Type column is sized for a short label. Records ingested before the format changed still hold a full paragraph in that field; it is shown in full on hover and in the exposure panel, and the row does not grow to fit it.
Severity is derived from CVSS
In the feed and on manual entry the level follows the score, using the NVD bands, and the form allows an explicit override:
| Score | Level |
|---|---|
| 9.0 and above | Critical |
| 7.0–8.9 | High |
| 4.0–6.9 | Medium |
| Below 4.0 | Low |
In the add form the level tracks the score until one of the level buttons is pressed. From that point it is manual and stops changing.
Statuses
| Status | Meaning | Shown in the register |
|---|---|---|
| Open | Not handled | Yes |
| In progress | Someone is working on it | Yes |
| Resolved | The work was done | Yes |
| Archived | Taken out of the work queue, the record is kept | Only with “Show archive” |
| Not relevant | Decided not to apply here | Only with “Show archive” |
The last two are hidden by default and are not deleted. See Exceptions.
Filtering and actions
Above the table sit severity chips (Critical · High · Medium · Low), status chips (Open · In progress · Resolved) and a Show archive toggle. They intersect with the column filters, the facet rail and the search box, and in By patch mode they filter the vulnerabilities before grouping — so a row's counters always agree with the filter on screen.
Clicking a row opens the exposure panel: which servers are exposed, why, and what has already been scheduled or marked as handled. The full explanation is in How a vulnerability is matched to a server.
Who may do what
| Permission | What it opens |
|---|---|
vulnerabilities.view | The register and the exposure panel |
vulnerabilities.manage | Add, edit, archive and import from a file |
vulnerabilities.mark_host | Marking a single server as handled |
vulnerabilities.purge | Clearing legacy records |
vulnerabilities.export | CSV and Excel export |
Permanent deletion exists, and the register asks about it explicitly and offers archiving instead. Archiving keeps the record, its history and its per-server handled marks; deletion does not.
Updated
This page is the file content/docs/en/v1/risk/vulnerabilities.mdx