6 Analyzing Data¶
6.1 Using the Dashboard¶
The OPENVAS REPORT Dashboard provides an overview of the detected and imported assets and their vulnerabilities.
6.1.1 Dashboard Structure¶

Fig. 6.1 Dashboard¶
The dashboard consists of the following charts:
- Number of assets
Total number of imported assets.
- Top 10 most vulnerable assets
Host names of the ten assets with the highest number of vulnerabilities with Critical severity. Clicking on an asset name opens the asset details (see Chapter 6.2.2.2).
The assets are sorted by the number of Critical vulnerabilities, then by the number of High vulnerabilities and then by the number of Medium vulnerabilities.
If an asset does not have a host name, the IP address of the asset is displayed.
- Vulnerability trends
Total number of vulnerabilities with Critical, High and Medium severity for up to the last 14 days.
Note
There are various reasons why the number of vulnerabilities change over time, for example:
Vulnerabilities were fixed.
New assets with vulnerabilities were imported from existing appliances.
New vulnerabilities were detected because of new Greenbone vulnerability tests.
Data was imported from additional Greenbone Enterprise Appliances.
Greenbone Enterprise Appliances were removed from OPENVAS REPORT.
- Top 10 critical vulnerabilities
Names of the ten vulnerabilities with Critical severity that were detected most frequently on assets.
Clicking on the number of affected assets opens the Affected assets page (see Chapter 6.4.1.3). If the dashboard is filtered (see Chapter 6.1.2), the filter is passed over to the Affected assets page.
- Top 10 high vulnerabilities
Names of the ten vulnerabilities with High severity that were detected most frequently on assets.
Clicking on the number of affected assets opens the Affected assets page (see Chapter 6.4.1.3). If the dashboard is filtered (see Chapter 6.1.2), the filter is passed over to the Affected assets page.
- Top 10 medium vulnerabilities
Names of the ten vulnerabilities with Medium severity that were detected most frequently on assets.
Clicking on the number of affected assets opens the Affected assets page (see Chapter 6.4.1.3). If the dashboard is filtered (see Chapter 6.1.2), the filter is passed over to the Affected assets page.
6.1.2 Filtering the Dashboard Content¶
The dashboard can be filtered as described in Chapter 4.3.
When a filter is added, all charts automatically change according to the filter criteria.
Note
If a filter returns no results, the dashboard shows 0 for the Number of assets chart and We did not find any vulnerabilities. Please check your filter. for all other charts.
This can also happen partially, for example when the filter returns no assets with critical, high or medium vulnerabilities.
6.1.3 Exporting Reports from the Dashboard View¶
The dashboard view can be exported as a PDF report. Two report types are available:
- Management summary
This report type includes the following for the selected time frame, taking into account the currently applied filter:
Total number of assets
Vulnerability trends diagram
Top 10 most vulnerable assets bars
Lists for top 10 critical, high and medium vulnerabilities
- Most vulnerable assets with vulnerability details
This report type includes the following for the selected time frame, taking into account the currently applied filter:
Total number of assets
Vulnerability trends diagram
Top 10 most vulnerable assets bars
Lists for top 10 critical, high and medium vulnerabilities
For the selected number of assets, a full list of vulnerabilities detected on each asset. The assets included in the report are selected in descending order of criticality.
A report can be exported as follows:
Click Export as report.
Fig. 6.2 Exporting a report from the dashboard¶
Select the desired report type in the drop-down list Template.
Select the period to be covered in the report in the drop-down list Timeframe of trend.
If the report type Most vulnerable assets with vulnerability details has been chosen, select the number of assets for which vulnerability details are to be included in the report in the drop-down list Number of assets.
Click Export.
Note
Only reports up to 100 pages long can be exported. If the requested report would exceed this limit, a message is displayed and the report is not generated.
The following can be tried to reduce the page number:
Limiting the number of assets to be exported, in case the report type Most vulnerable assets with vulnerability details has been chosen.
Refining the desired results using the filter.
Afterwards, the export can be started again.
Fig. 6.3 Warning when exceeding the page limit¶
6.2 Managing Assets¶
6.2.1 Creating Assets¶
Assets are created during the data import from a connected Greenbone Enterprise Appliance (see Chapter 5.3).
The following cases are possible:
An asset already exists in OPENVAS REPORT
If an asset already exists for an appliance, the imported vulnerability data is assigned to the existing asset, and all corresponding changed data is updated, for example the IP address for assets with the same host name and dynamic IP addresses.
An asset does not yet exist in OPENVAS REPORT
If an asset does not yet exist for an appliance, the asset is created based on the host name (first criterion, for assets with a host name) or the IP address (second criterion, for assets without a host name).
Note
It is possible that more than one asset exists with the same host name. The appliance that provides the asset data is taken into account when creating assets, for example to support assets with the same host name in separate networks.
Assets that have not been updated for more than 180 days, meaning that no new data has been imported for them, are automatically removed from OPENVAS REPORT.
6.2.2 Viewing Assets¶
6.2.2.1 Viewing the Overall List of Assets¶
All existing assets can be displayed by selecting Analysis > Assets in the menu (see Fig. 6.4).

Fig. 6.4 Assets page¶
For all assets, the following information is displayed:
- Host name
Name of the asset. The name is displayed as
if the asset does not have a host name.
Clicking on the host name opens the details page of the asset (see Chapter 6.2.2.2).
- IP address
IP address of the asset.
- Operating system
Detected operating system of the asset, for example Windows 10 Enterprise 21H2 or FreeBSD 12.2.
- Appliance name
Name that was specified for the appliance when it was connected to OPENVAS REPORT (see Chapter 5.2).
- Last scan
Date and time the asset was last scanned.
- Asset ID
Internal identifier that makes an asset unique. If assets in separate networks have the same host name, the asset ID can be used to differentiate between the assets.
- Criticality
The bars show the number and distribution of vulnerabilities with critical, high and medium severity.
Moving the cursor over a bar shows the number of vulnerabilities for the corresponding severity class.
When sorting by this column, the assets are sorted by the number of Critical vulnerabilities, then by the number of High vulnerabilities and then by the number of Medium vulnerabilities.
- Tags
Tags linked to the asset (see Chapter 6.3).
All tags can be displayed by clicking on the number of additional tags, for example,
(see Fig. 6.5).
Fig. 6.5 Displaying additional tags¶
For all assets, the following action is available:
6.2.2.2 Viewing Asset Details¶
In the overall list of assets (see Chapter 6.2.2.1), click on the host name of an asset to display the details page of an asset (see Fig. 6.6).

Fig. 6.6 Asset details¶
The following information is displayed:
- Host name
Name of the asset. The name is empty if the asset does not have a host name.
- IP address
IP address of the asset.
- Operating system
Detected operating system of the asset, for example Windows 10 Enterprise 21H2 or FreeBSD 12.2.
- Appliance name
Name that was specified for the appliance when it was connected to OPENVAS REPORT (see Chapter 5.2).
- Last scan
Date and time the asset was last scanned.
A table below displays all vulnerabilities detected for the asset. For all vulnerabilities, the following information is displayed:
- Severity
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS). CVSS is an industry standard for describing the severity of vulnerabilities.
CVSS v2.0 and CVSS v3.x consist of three metric groups: Base, Temporal, and Environmental.
CVSS v4.0, the current version, consists of four metric groups: Base, Threat, Environmental, and Supplemental.
Note
If a vulnerability contains data of more than one CVSS version, the newest is always used.
The National Vulnerability Database (NVD) provides CVSS assessments of Base metrics since they are the intrinsic characteristics of a vulnerability. Assessments for Temporal, Threat, Environmental, or Supplemental metrics are not provided as they strongly depend on time, on the particular organization in which they occur and on additional context.
Base score metrics rate the exploitability of a vulnerability and its impact on the target system. This includes, among other things, assessing the accessibility of the target system and whether the confidentiality, integrity or availability of the target system is at risk.
The severity includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class. Regardless of the CVSS version, the severity class is determined using the following grading:
Critical: 9.0–10.0
High: 7.0–8.9
Medium: 4.0–6.9
Low: 0.0–3.9
Existing overrides are imported from the connected appliance together with the scan results. If an override exists for a vulnerability, this is indicated by
next to the severity. Moving the cursor over the severity displays the original severity.
- Vulnerability name
Name of the vulnerability.
Clicking on the vulnerability name opens the details page of a vulnerability (see Chapter 6.4.1.2).
- QoD
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 and 100, with 100 being the most reliable.
For more information see Chapter 6.4.4.
- Solution type
Type of measure to remedy the vulnerability. The following solution types exist:
Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. There can be none, one or more workarounds available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product and they may or may not be officially sanctioned by the document producer.
Vendor fix: Information is available about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
None available: Currently there is no fix available.
Vendor will not fix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated. Information should contain details about why there will be no fix issued.
For all vulnerabilities, the following action is available:
View vulnerability details as an overlay (see Chapter 6.4.1.2).
6.2.3 Filtering Assets¶
The overall list of assets as well as the details page of an asset can be filtered as described in Chapter 4.3.
Note
If a filter delivers no results, the table with the list of assets shows No data available. Please check your filter.
6.2.4 Exporting Assets¶
6.2.4.1 Exporting a List of Assets¶
The list of assets (see Chapter 6.2.2.1) can be exported as a CSV file. If the asset list is filtered, only the filtered assets are exported.
Note
If no data is imported or the filter delivers no results, the export functionality is disabled. Data has to be imported from connected Greenbone Enterprise Appliances (see Chapter 5.3) or the filter has to be adjusted (see Chapter 4.3).
A list of assets can be exported as follows:
Select Analysis > Assets in the menu.
Filter the assets to all those that should be exported (see Chapter 6.2.3).
Click Export and select Export from the drop-down list.
→ The list of assets is exported.
Note
The file name consists of the static text
asset_list
, the indication if the list is filtered (filtered
) or unfiltered (unfiltered
), and the export date in the format YYYY-MM-DD. Example:asset_list_unfiltered_2025-04-10.csv
The CSV file contains the following information for each asset:
Host name
IP address
Operating system
Appliance name
Last scan
Asset ID
6.2.4.2 Exporting a List of Assets with All Their Vulnerabilities¶
The list of assets (see Chapter 6.2.2.1) with details about all their vulnerabilities can be exported as a CSV file. If the asset list is filtered, only the filtered assets are exported.
Note
If no data is imported or the filter delivers no results, the export functionality is disabled. Data has to be imported from connected Greenbone Enterprise Appliances (see Chapter 5.3) or the filter has to be adjusted (see Chapter 4.3).
A list of assets with all their vulnerabilities can be exported as follows:
Select Analysis > Assets in the menu.
Filter the assets to all those that should be exported (see Chapter 6.2.3).
Click Export and select Export data with details from the drop-down list.
→ The list of assets is exported.
Note
The file name consists of the static text
assets_with_vulnerabilities
, the indication if the list is filtered (filtered
) or unfiltered (unfiltered
), and the export date in the format YYYY-MM-DD. Example:assets_with_vulnerabilities_unfiltered_2025-04-10.csv
The CSV file contains the following information for each asset:
Host name
IP address
Operating system
Appliance name
Last scan
Severity (if overrides exist, the CSV file will only show the new severity without indicating the overridden severity)
Vulnerability name
Solution type
Solution
QoD
Summary
Impact
Affected software/operating system
Specific result
CVE references
CERT references
6.2.4.3 Exporting Asset Details¶
The details of a specific asset (see Chapter 6.2.2.2) can be exported as a CSV file. The exported file contains a list of the vulnerabilities detected for the asset. If the vulnerability list is filtered, only the filtered vulnerabilities are exported.
The asset details can be exported as follows:
Select Analysis > Assets in the menu.
Click on the host name of an asset to display the asset details.
Click Export.
→ The asset details are exported.
Note
The file name consists of the host name of the asset (or the IP address if the asset does not have a host name), the indication if the list is filtered (
filtered
) or unfiltered (unfiltered
), and the date of the export in the format YYYY-MM-DD. Example:server12_unfiltered_2025-04-10.csv
The CSV file contains the following information:
Host name
IP address
Operating system
Appliance name
Last scan
Severity (if overrides exist, the CSV file will only show the new severity without indicating the overridden severity)
Vulnerability name
Solution type
Solution
QoD
Summary
Impact
Affected software/operating system
CVE references
CERT references
Note
Host name, IP address, operating system, appliance name and last scan are the same for all vulnerabilities because they were all detected for the same asset. This allows to make the reference for which asset the vulnerabilities were exported.
6.2.5 Deleting Assets¶
Note
Assets that have not been updated for more than 180 days, meaning that no new data has been imported for them, are automatically removed from OPENVAS REPORT.
Assets can be deleted manually as follows:
Select Analysis > Assets in the menu.
-
→ A warning dialog is displayed asking to confirm the deletion.
Note
The asset and all associated data is removed.
If the asset is included in future scans on the Greenbone Enterprise Appliance, it will be imported again to OPENVAS REPORT during the next import from the appliance.
Fig. 6.7 Confirming the deletion¶
Click Delete asset.
→ The asset is removed from OPENVAS REPORT.
Note
Since all associated data is also removed, deleting an asset may take a while.
6.4 Managing Vulnerabilities¶
Note
Vulnerabilities with the severity classes Log and False Positive on the Greenbone Enterprise Appliance are not displayed in OPENVAS REPORT.
6.4.1 Viewing Vulnerabilities¶
6.4.1.1 Viewing the Overall List of Vulnerabilities¶
All existing vulnerabilities can be displayed by selecting Analysis > Vulnerabilities in the menu (see Fig. 6.10).

Fig. 6.10 Vulnerabilities page¶
For all vulnerabilities, the following information is displayed:
- Severity
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS). CVSS is an industry standard for describing the severity of vulnerabilities.
CVSS v2.0 and CVSS v3.x consist of three metric groups: Base, Temporal, and Environmental.
CVSS v4.0, the current version, consists of four metric groups: Base, Threat, Environmental, and Supplemental.
Note
If a vulnerability contains data of more than one CVSS version, the newest is always used.
The National Vulnerability Database (NVD) provides CVSS assessments of Base metrics since they are the intrinsic characteristics of a vulnerability. Assessments for Temporal, Threat, Environmental, or Supplemental metrics are not provided as they strongly depend on time, on the particular organization in which they occur and on additional context.
Base score metrics rate the exploitability of a vulnerability and its impact on the target system. This includes, among other things, assessing the accessibility of the target system and whether the confidentiality, integrity or availability of the target system is at risk.
The severity includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class. Regardless of the CVSS version, the severity class is determined using the following grading:
Critical: 9.0–10.0
High: 7.0–8.9
Medium: 4.0–6.9
Low: 0.0–3.9
Existing overrides are imported from the connected appliance together with the scan results. If an override exists for a vulnerability, this is indicated by
next to the severity. Moving the cursor over the severity displays the original severity.
- Vulnerability name
Descriptive name of the vulnerability.
Clicking on the vulnerability name opens the details page of the vulnerability (see Chapter 6.4.1.2).
- QoD
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 and 100, with 100 being the most reliable.
For more information see Chapter 6.4.4.
- Affected assets
Number of assets for which this vulnerability was detected.
Clicking on the number of affected assets opens the Affected assets page (see Chapter 6.4.1.3).
- Solution type
Type of measure to remedy the vulnerability. The following solution types exist:
Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. There can be none, one or more workarounds available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product and they may or may not be officially sanctioned by the document producer.
Vendor fix: Information is available about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
None available: Currently there is no fix available.
Vendor will not fix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated. Information should contain details about why there will be no fix issued.
6.4.1.2 Viewing Vulnerability Details¶
In the overall list of vulnerabilities (see Chapter 6.4.1.1), click on the vulnerability name to display the details page of a vulnerability (see Fig. 6.11).

Fig. 6.11 Vulnerability details¶
The following information is displayed:
- Name (displayed at the top below the headline Vulnerability details)
Descriptive name of the vulnerability.
- Severity (displayed as a graphical element)
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS). CVSS is an industry standard for describing the severity of vulnerabilities.
CVSS v2.0 and CVSS v3.x consist of three metric groups: Base, Temporal, and Environmental.
CVSS v4.0, the current version, consists of four metric groups: Base, Threat, Environmental, and Supplemental.
Note
If a vulnerability contains data of more than one CVSS version, the newest is always used.
The National Vulnerability Database (NVD) provides CVSS assessments of Base metrics since they are the intrinsic characteristics of a vulnerability. Assessments for Temporal, Threat, Environmental, or Supplemental metrics are not provided as they strongly depend on time, on the particular organization in which they occur and on additional context.
Base score metrics rate the exploitability of a vulnerability and its impact on the target system. This includes, among other things, assessing the accessibility of the target system and whether the confidentiality, integrity or availability of the target system is at risk.
The severity includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class. Regardless of the CVSS version, the severity class is determined using the following grading:
Critical: 9.0–10.0
High: 7.0–8.9
Medium: 4.0–6.9
Low: 0.0–3.9
Existing overrides are imported from the connected appliance together with the scan results. If an override exists for a vulnerability, the new severity is displayed in the graphical element. The original severity is indicated by
. Moving the cursor over
displays the original severity.
- Solution type
Type of measure to remedy the vulnerability. The following solution types exist:
Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. There can be none, one or more workarounds available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product and they may or may not be officially sanctioned by the document producer.
Vendor fix: Information is available about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
None available: Currently there is no fix available.
Vendor will not fix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated. Information should contain details about why there will be no fix issued.
- Solution
Description of how the vulnerability can be remediated.
- Vulnerability insight
Details about the cause of the vulnerability.
This information is not available for all vulnerabilities.
- Summary
Further details about the vulnerability.
- Impacts
Possible consequences if the vulnerability is exploited, for example, remote-code execution.
This information is not available for all vulnerabilities.
- Affected software/operating system
Products, including version and operating system, that are affected by the vulnerability.
This information is not available for all vulnerabilities.
- Affected assets link
Link to an overview of assets for which this vulnerability was detected (see Chapter 6.4.1.3).
- Family
Group of vulnerability tests the test that detected the vulnerability belongs to.
- Quality of detection
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 and 100, with 100 being the most reliable.
For more information see Chapter 6.4.4.
- CVE references
Common Vulnerabilities and Exposure (CVE) references for the vulnerability.
CVE was founded by MITRE in order to avoid multiple naming of the same vulnerability by different organizations and to ensure a uniform naming convention. Every vulnerability is assigned a unique identifier, which consists of the release year and a simple number, and serves as a central reference.
CVEs are published and made accessible by the National Institute of Standards and Technology (NIST) in the National Vulnerability Database (NVD). The NVD complements the CVEs with information regarding the elimination, severity, potential impact and affected products of the vulnerability.
The vulnerability can have no CVE references, one CVE reference or several CVE references.
Clicking on a reference opens the Greenbone SecInfo Portal in a separate browser tab. Click Sign In as Guest to view the CVE details.
- Other references
Any other available references, for example more details from the software vendor. The vulnerability can have no other references, one other reference or several other references.
Links opens in separate browser tabs.
6.4.1.3 Viewing Affected Assets¶
In the overall list of vulnerabilities (see Chapter 6.4.1.1), click on the number of affected assets to display all assets for which this vulnerability was detected (see Fig. 6.12).

Fig. 6.12 Assets affected by a vulnerability¶
Note
The filter bar on this page offers a read-only view. This helps to assess whether the list of displayed assets is complete or not.
It is complete if no filter is used or if a filter is used with only vulnerability attributes. It may be incomplete if a filter with at least one asset attribute is used.
The following information about the vulnerability is displayed:
- Vulnerability name (displayed after the static text Assets affected by in the headline of the page)
Descriptive name of the vulnerability.
- Solution type
Type of measure to remedy the vulnerability. The following solution types exist:
Workaround: Information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability is available. There can be none, one or more workarounds available. This is usually the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability is available but that does not resolve the vulnerability on the affected product. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product and they may or may not be officially sanctioned by the document producer.
Vendor fix: Information is available about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
None available: Currently there is no fix available.
Vendor will not fix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, is no longer maintained or otherwise deprecated. Information should contain details about why there will be no fix issued.
- Solution
Description of how the vulnerability can be remediated.
- Severity (displayed as a graphical element on the right)
Qualitative measure of a vulnerability’s severity according to the Common Vulnerability Scoring System (CVSS). CVSS is an industry standard for describing the severity of vulnerabilities.
CVSS v2.0 and CVSS v3.x consist of three metric groups: Base, Temporal, and Environmental.
CVSS v4.0, the current version, consists of four metric groups: Base, Threat, Environmental, and Supplemental.
Note
If a vulnerability contains data of more than one CVSS version, the newest is always used.
The National Vulnerability Database (NVD) provides CVSS assessments of Base metrics since they are the intrinsic characteristics of a vulnerability. Assessments for Temporal, Threat, Environmental, or Supplemental metrics are not provided as they strongly depend on time, on the particular organization in which they occur and on additional context.
Base score metrics rate the exploitability of a vulnerability and its impact on the target system. This includes, among other things, assessing the accessibility of the target system and whether the confidentiality, integrity or availability of the target system is at risk.
The severity includes a severity score, which is a number from 0.0 to 10.0, with 10.0 being the most severe, and a severity class. Regardless of the CVSS version, the severity class is determined using the following grading:
Critical: 9.0–10.0
High: 7.0–8.9
Medium: 4.0–6.9
Low: 0.0–3.9
Existing overrides are imported from the connected appliance together with the scan results. If an override exists for a vulnerability, the new severity is displayed in the graphical element. The original severity is indicated by
. Moving the cursor over
displays the original severity.
Clicking on the right side displays the following additional information:
- Vulnerability insight
Details about the cause of the vulnerability.
This information is not available for all vulnerabilities.
- Summary
Further details about the vulnerability.
- Impacts
Possible consequences if the vulnerability is exploited, for example, remote-code execution.
This information is not available for all vulnerabilities.
- Affected software/operating system
Products, including version and operating system, that are affected by the vulnerability.
This information is not available for all vulnerabilities.
- Family
Group of vulnerability tests the test that detected the vulnerability belongs to.
- Quality of detection
Short for “Quality of Detection”. The QoD describes the reliability of the executed vulnerability detection. It is a value between 0 and 100, with 100 being the most reliable.
For more information see Chapter 6.4.4.
For all affected assets of the vulnerability, the following information is displayed:
- Host name
Name of the asset. The name is empty if the asset does not have a host name.
- IP address
IP address of the asset.
- Operating system
Detected operating system of the asset, for example Windows 10 Enterprise 21H2 or FreeBSD 12.2.
- Appliance name
Name that was specified for the appliance when it was connected to OPENVAS REPORT (see Chapter 5.2).
- Last scan
Date and time the asset was last scanned.
6.4.2 Filtering Vulnerabilities¶
The overall list of vulnerabilities can be filtered as described in Chapter 4.3.
Note
If a filter delivers no results, the table with the list of vulnerabilities shows No data available. Please check your filter.
6.4.3 Exporting Vulnerabilities¶
6.4.3.1 Exporting a List of Vulnerabilities¶
The list of vulnerabilities (see Chapter 6.4.1.1) can be exported as a CSV file. If the vulnerability list is filtered, only the filtered vulnerabilities are exported.
Note
If no data is imported or the filter delivers no results, the export functionality is disabled. Data has to be imported from connected Greenbone Enterprise Appliances (see Chapter 5.3) or the filter has to be adjusted (see Chapter 4.3).
A list of vulnerabilities can be exported as follows:
Select Analysis > Vulnerabilities in the menu.
Filter the vulnerabilities to all those that should be exported (see Chapter 6.4.2).
Click Export and select Export from the drop-down list.
→ The list of vulnerabilities is exported.
Note
The file name consists of the static text
vulnerability_list
, the indication if the list is filtered (filtered
) or unfiltered (unfiltered
), and the export date in the format YYYY-MM-DD. Example:vulnerability_list_unfiltered_2025-04-10.csv
The CSV file contains the following information for each vulnerability:
Severity (if overrides exist, the CSV file will only show the new severity without indicating the overridden severity)
Vulnerability name
QoD
Summary
Total assets
Solution type
6.4.3.2 Exporting a List of Vulnerabilities with All Their Affected Assets¶
The list of vulnerabilities (see Chapter 6.4.1.1) with details about all their affected assets can be exported as a CSV file. If the vulnerability list is filtered, only the filtered vulnerabilities are exported.
Note
If no data is imported or the filter delivers no results, the export functionality is disabled. Data has to be imported from connected Greenbone Enterprise Appliances (see Chapter 5.3) or the filter has to be adjusted (see Chapter 4.3).
A list of vulnerabilities with all their affected assets can be exported as follows:
Select Analysis > Vulnerabilities in the menu.
Filter the vulnerabilities to all those that should be exported (see Chapter 6.4.2).
Click Export and select Export data with details from the drop-down list.
→ The list of vulnerabilities is exported.
Note
The file name consists of the static text
vulnerabilities_with_affected_assets
, the indication if the list is filtered (filtered
) or unfiltered (unfiltered
), and the export date in the format YYYY-MM-DD. Example:vulnerabilities_with_affected_assets_unfiltered_2025-04-10.csv
The CSV file contains the following information for each vulnerability:
Severity (if overrides exist, the CSV file will only show the new severity without indicating the overridden severity)
Vulnerability name
Solution type
Solution
QoD
Summary
Impact
Affected software/operating system
Specific result
CVE references
CERT references
Host name
IP address
Operating system
Appliance name
Last scan
6.4.3.3 Exporting a List of Affected Assets¶
The list of assets affected by a specific vulnerability (see Chapter 6.4.1.3) can be exported as a CSV file. If the list of affected assets is filtered by an asset attribute (see Chapter 4.3.3, tab Assets (overall list)), only the affected assets that match the filter are exported.
The list of affected assets can be exported as follows:
Select Analysis > Vulnerabilities in the menu.
Click on the number of assets in the Affected assets column.
Click Export.
→ The list of affected assets is exported.
Note
The file name consists of the vulnerability name, the static text
affected_assets
, the indication if the list is filtered (filtered
) or unfiltered (unfiltered
), and the date of the export in the format YYYY-MM-DD. Example:operating_system__os__end_of_life__eol__detection_affected_assets_filtered_2025-04-10.csv
The CSV file contains the following information:
Severity (if overrides exist, the CSV file will only show the new severity without indicating the overridden severity)
Vulnerability name
Solution type
Solution
QoD
Summary
Impact
Affected software/operating system
CVE references
CERT references
Host name
IP address
Operating system
Appliance name
Last scan
Note
Severity, vulnerability name, solution type, solution, QoD, summary, impact, affected software/operating system, CVE references and CERT references are the same for all assets because they are all affected by the same vulnerability. This allows to make the reference by which vulnerability the assets are affected.
6.4.4 Quality of Detection (QoD) Concept¶
The quality of detection (QoD) is a value between 0 and 100 describing the reliability of the executed vulnerability detection or product detection.
While the QoD range allows to express the quality quite fine-grained, most tests use a standard methodology. Therefore, QoD types are associate with a QoD value. The current list of types may be extended over time.
Note
The QoD of a “discovery” result is higher than that of an actual “vulnerability” result as it reflects the quality of the product detection itself – which is reliable – and not the quality of the associated vulnerability tests, which may be unreliable for various reasons (see table).
The lowest QoD that could apply is always used, for example in case of multiple detection methods (remote or local/authenticated).
QoD |
QoD Type |
Description |
---|---|---|
100 |
exploit |
The detection happened via an exploit and is therefore fully verified. |
99 |
remote_vul |
Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response clearly shows the presence of the vulnerability. |
98 |
remote_app |
Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response clearly shows the presence of the vulnerable application. |
97 |
package |
Authenticated package-based checks for Linux(oid) systems. |
97 |
registry |
Authenticated registry based checks for Microsoft Windows systems. |
95 |
remote_active |
Remote active checks (code execution, traversal attack, SQL injection etc.) in which the response shows the likely presence of the vulnerable application or of the vulnerability. “Likely” means that only rare circumstances are possible in which the detection would be wrong. |
80 |
remote_banner |
Remote banner checks of applications that offer patch level in version. Many proprietary products do so. |
80 |
executable_version |
Authenticated executable version checks for Linux(oid) or Microsoft Windows systems where applications offer patch level in version. |
75 |
If results without any QoD information are processed, they are assigned this value. |
|
70 |
remote_analysis |
Remote checks that do some analysis but which are not always fully reliable. |
50 |
remote_probe |
Remote checks in which intermediate systems such as firewalls might pretend correct detection so that it is actually not clear whether the application itself answered. For example, this can happen for non-TLS connections. |
30 |
remote_banner_unreliable |
Remote banner checks of applications that do not offer patch level in version identification. For example, this is the case for many open source products due to backport patches. |
30 |
executable_version_unreliable |
Authenticated executable version checks for Linux(oid) systems where applications do not offer patch level in version identification. |
30 |
package_unreliable |
Authenticated package-based checks which are not always fully reliable for, for example, Linux(oid) systems. |
1 |
general_note |
General note on potential vulnerability without finding any present application. |