> ## Documentation Index > Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # CVE Analysis > Prioritize known vulnerabilities, assign them to a person, reject them with a reason and back them with controls. *Analysis* › *CVE Analysis* matches known vulnerabilities against the systems you have captured. The matching runs in the background; you create nothing here. In the interface you decide what to tackle first, who takes it, and what deliberately stays as it is. Not to be confused with ISMS › *Risk Management* › *Vulnerabilities*: that is the catalog of abstract vulnerabilities used to build risks. CVE Analysis works with concrete, published vulnerabilities that the matching assigns to your systems. ## CVSS and severity | Value | What it is | | - | - | | *CVSS* | a number from 0 to 10 that quantifies the severity | | *Severity* | one of four levels: *Critical*, *High*, *Medium*, *Low* | If both are present, the severity applies; if only the number is present, the level is derived from it — from 9 critical, from 7 high, from 4 medium, below that low. The same thresholds determine the *Remediation Deadline*. ## By CVEs and by Assets The inventory stands in two lists: * *By CVEs* — one row per vulnerability. A click in the *CVE ID* column opens it. * *By Assets* — one row per affected system, with the full distribution across all four severity levels. The second list does **not** open a vulnerability: a click leads to the detail page of the system. From there you reach the individual entries via its *CVEs* tab. For the question "what first?", *Analysis* › *Dashboard* is enough: *Critical CVEs* names the number and opens the *By CVEs* list filtered to the severity *Critical*. The filter appears as a *Critical CVEs* filter button and can be deselected. *Patches available* opens the same list, filtered to CVEs with an available patch. ## CVSS metrics The *Overview* tab shows the *CVSS* value, the level in plain text and a grid with the individual metrics of the rating. If the vulnerability has neither a severity nor metrics, *Not Rated* stands in place of the level. **Two vulnerabilities rarely show the same metrics.** Only what the source supplies is shown, and each vulnerability fills only one CVSS version. The grid lists the metric names of versions 2, 3 and 4 side by side: *Attack Complexity*, *Privileges Required* and *User Interaction* belong to versions 3 and 4, *Scope* only to version 3, *Access Complexity* and *Authentication* only to version 2, *Attack Requirements* only to version 4. Version 4 splits the impacts into the vulnerable system and subsequent systems, for example *Confidentiality (Vulnerable System)* and *Confidentiality (Subsequent Systems)*; these six rows replace *Scope*, *Confidentiality*, *Integrity* and *Availability* there. For version 4, only the base metrics appear. Which version the rating followed is stated as version and vector above the grid and, in addition, in its first row *CVSS Version*; that row's info icon explains the scale of the version — for version 2 also that it has no *Critical* level and *High* is the highest. ## Recording an assessment On the detail page of a vulnerability, only the *Assessment* tab accepts entries: a pencil icon next to a section heading switches it into edit mode, recognizable by the *Editing CVE* bar. The *Journal* tab holds the change history of the vulnerability. The *Relations* tab lists all of the vulnerability's relations, grouped. It is the same view as under [Inventory › Relationships](/docs/en/assets/relations); columns and handling are described there. Switching tabs leaves edit mode and **discards your entries** without asking. Save before you switch to *Affected Assets* or *Controls*. ### Status *New* · *Assessed* · *In Progress* · *Resolved* · *Accepted* · *False Positive* **For *Accepted* and *False Positive* a *Reason* is mandatory.** As long as the field is empty, the save button stays disabled. The other four statuses require nothing. Two optional entries go with it, neither of which affects the status: *Responsible* for who takes care of it and *Due Date* for the deadline. The save button also stays disabled while nothing has changed, or while *Due Date* holds an unreadable date. ### Remediation deadline and due date The *Remediation Deadline* in the *General* section **cannot be entered** — it is calculated from the *CVSS* value: | CVSS | Deadline | | - | - | | from 9 | 7 days | | from 7 | 30 days | | from 4 | 90 days | | below that, or no value | 180 days | A *Remediation Deadline* of seven days can sit next to a *Due Date* three months out. The deadline follows from the severity, the due date from your own agreement; the deadline takes neither the date nor the status into account. The *Category* is set in the same section — *Software*, *Operating System* or *Hardware*. The remaining rows — *Detected*, *Published*, *Source* and *CVSS* — come from the matching and are display only. ### Risk assessment The *Risk Assessment* section carries the same risk matrix as the [ISMS](/docs/en/isms/understanding-risk-management), here with the vulnerability as its subject. If nothing has been assessed yet, only a sentence stands there — the matrix appears **only** once you switch to edit mode. ### Assessing several CVEs In the *By CVEs* list you assess several vulnerabilities in one step. *Edit* opens the same fields as the *Assessment* tab for the selected rows; the *By Assets* list has no selection. With one selected row, the fields are prefilled with that vulnerability's values. With several rows they are empty, and each field has a check box in front of it. Only checked fields are written. The other fields of the selected vulnerabilities stay unchanged, even though the form shows them empty. Multi-edit does not process more than 1000 selected rows; *Edit* then stays disabled. The same limit applies when you select all rows through a filter. ## Controls In the *Controls* tab, the *Control* button opens the *Add Control* dialog: *Create New* creates a new one, *Link Existing* picks one that already exists. Above the list you see how many of the linked controls are implemented. The tab is a second view of the same data as under [ISMS › Controls](/docs/en/isms/controls), **not a control management of its own**. The same control can treat a vulnerability and satisfy a compliance objective. Only what is **implemented** counts toward the progress. Controls in progress sit in a line of their own below it and do not fill it. Five linked controls, two of them implemented and two in progress, make 40 percent; the fifth appears in neither number. *Remove Relation* only dissolves the relation between the vulnerability and the control; the control itself stays in the ISMS. ## Affected Assets and Software *Affected Assets* names the systems, *Affected Software* the individual installations with version and host. **The counters of the two tabs count different things.** *Affected Assets* lists each system once, even if it carries several affected installations; the counter above counts systems. *Affected Software* counts installations and heads its table *Affected Installations*; this counter can be larger than the number of systems. The *Affected Assets* column of the *By CVEs* list also counts systems and matches the *Affected Assets* tab, not the *Affected Software* tab. The *Overview* tab has a similarly named section, *Affected Products*. It names something else: the product data of the vulnerability itself — *Vendor*, *Product*, *Version*, *Vulnerable* — regardless of whether that product is installed in your inventory. ## CVEs on the asset On the asset itself, the overview and the *CVEs* tab show the section for that one device. At the top stands the number of vulnerabilities per severity level — *Critical*, *High*, *Medium*, *Low* — and below it, under *Open CVEs*, the list of this asset's CVEs. The four severity levels are filters at the same time: one click limits the list to the level you clicked. Together with the search field, this picks out a single entry. On the overview, *CVEs* shows the number of critical ones and below it the number of all open ones; both places read the same source and show the same value. Each entry leads to the same detail page as the lists. Assessment, status and controls live in one place, no matter which way in you take. Prioritizing across the whole inventory remains the job of the two lists under *CVE Analysis*. ## Related The systems and their software come from [scanning](/docs/en/scan/understanding-scanning); you track the controls under [Controls](/docs/en/isms/controls). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.