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

_images/dashboard.png

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:

  1. Click Export as report.

    _images/export-dashboard.png

    Fig. 6.2 Exporting a report from the dashboard

  2. Select the desired report type in the drop-down list Template.

  3. Select the period to be covered in the report in the drop-down list Timeframe of trend.

  4. 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.

  5. 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.

    _images/export-dashboard-2.png

    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).

_images/assets-overview.png

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).

_images/asset-tags.png

Fig. 6.5 Displaying additional tags

For all assets, the following action is available:

  • Create and manage tags of the asset (see Chapter 6.3).

  • Delete the asset (see Chapter 6.2.5).

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).

_images/asset-details.png

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).

Tip

Clicking in the Action column opens the vulnerability details as an overlay on the current page.

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:

  1. Select Analysis > Assets in the menu.

  2. Filter the assets to all those that should be exported (see Chapter 6.2.3).

  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:

  1. Select Analysis > Assets in the menu.

  2. Filter the assets to all those that should be exported (see Chapter 6.2.3).

  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:

  1. Select Analysis > Assets in the menu.

  2. Click on the host name of an asset to display the asset details.

  3. 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:

  1. Select Analysis > Assets in the menu.

  2. Click in the Action column.

    → 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.

    _images/delete-asset.png

    Fig. 6.7 Confirming the deletion

  3. 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.3 Using Tags

Tags are name-value pairs that can be linked to assets in order to filter them by tags. Tags can only be assigned to assets.

6.3.1 Differences in Tags Between Greenbone Enterprise Appliance and OPENVAS REPORT

There are a few differences regarding the handling and behavior of tags between the Greenbone Enterprise Appliance and OPENVAS REPORT:

Greenbone Enterprise Appliance

OPENVAS REPORT

A tag works with only a name, the value is optional.

Both name and value are mandatory.

Tags can be assigned to different resource types.

Tags can only be assigned to assets.

There is a dedicated Tags page on the web interface for managing tags.

Tags are created and managed as part of the Manage tags dialog on the Assets page.

Tags can be created on the Tags page without assigning them to a resource.

When tags are created, they are assigned to the assets in the same step.

6.3.2 Creating Tags

6.3.2.1 Assigning a Tag Directly to an Asset

A tag can be assigned directly to an asset as follows:

  1. Select Analysis > Assets in the menu.

  2. Click in the Action column.

    → The Manage tags dialog is opened. If there are already tags assigned to this asset, they are displayed in a list below the asset’s host name and IP address (see Fig. 6.8).

    _images/add-tag.png

    Fig. 6.8 Adding a tag to an asset

  3. At the bottom of the list, enter a name for the tag in the Name input box.

    Note

    Tag names are case-sensitive and can be at most 128 characters long.

    Already existing tag names are displayed in a drop-down list. This can be used for the following use cases:

    • Existing tags can be assigned (see Chapter 6.3.2.3).

    • Replacing a tag value with a new one. Assets cannot have multiple tags assigned with the same name.

      Example: If a tag with the name Department and the value Sales is already assigned to an asset and a tag with the name Department and the value Marketing is also assigned, the tag with the value Sales is overwritten.

  4. Enter a value for the tag in the Value input box.

    Note

    Tag values are case-sensitive and can be at most 255 characters long.

    Already existing tag values are displayed in a drop-down list. This can be used for assigning already existing tags (see Chapter 6.3.2.3).

  5. Click .

    → The new tag is displayed at the bottom of the list of tags.

  6. Click Save tags.

6.3.2.2 Assigning a Tag to Multiple Assets

A tag can be assigned to multiple assets as follows:

  1. Select Analysis > Assets in the menu.

  2. Filter the assets to display all those to which the tag should be assigned (see Chapter 4.3).

  3. Click Manage tags.

    → The Manage tags dialog is opened. The number of assets to which the tag will be assigned is displayed at the top (see Fig. 6.9).

    All tags that are already assigned to some or all of the filtered assets are displayed in a list. The number to the right of each tag shows to how many assets it is assigned.

    _images/add-tag-2.png

    Fig. 6.9 Adding a tag to an asset

  4. At the bottom of the list, enter a name for the tag in the Name input box.

    Note

    Tag names are case-sensitive and can be at most 128 characters long.

    Already existing tag names are displayed in a drop-down list. This can be used for the following use cases:

    • Existing tags can be assigned (see Chapter 6.3.2.3).

    • Replacing a tag value with a new one. Assets cannot have multiple tags assigned with the same name.

      Example: If a tag with the name Department and the value Sales is already assigned to an asset and a tag with the name Department and the value Marketing is also assigned, the tag with the value Sales is overwritten.

  5. Enter a value for the tag in the Value input box.

    Note

    Tag values are case-sensitive and can be at most 255 characters long.

    Already existing tag values are displayed in a drop-down list. This can be used for assigning already existing tags (see Chapter 6.3.2.3).

  6. Click .

    → The new tag is displayed at the bottom of the list of tags.

  7. Click Save tags.

    Note

    Depending on the number of assets the tag is assigned to, it may take a while until the tag is displayed.

6.3.2.3 Linking an Existing Tag to Assets

An already existing tag can be added to one or multiple assets.

  1. Follow the instruction in Chapter 6.3.2.1 or Chapter 6.3.2.2 until the Manage tags dialog is opened.

  2. At the bottom of the list, click in the Name input box and select a tag name from the drop-down list.

    Note

    Assets cannot have multiple tags assigned with the same name.

    Example: If a tag with the name Department and the value Sales is already assigned to an asset and a tag with the name Department and the value Marketing is also assigned, the tag with the value Sales is overwritten.

  3. Click in the Value input box and select a tag value from the drop-down list.

  4. Click Save tags.

    Note

    Depending on the number of assets the tag is assigned to, it may take a while until the tag is displayed.

6.3.3 Removing Tags from Assets

6.3.3.1 Removing a Tag from One Asset

A tag can be removed from an asset as follows:

  1. Select Analysis > Assets in the menu.

  2. Click in the Action column.

  3. Click for the tag that should be removed.

  4. Click Save tags.

6.3.3.2 Removing a Tag from Multiple Assets

Note

If a tag is removed from all assets it is assigned to, it is deleted completely.

A tag can be deleted as follows:

  1. Select Analysis > Assets in the menu.

  2. Filter the assets to display all those from which the tag should be removed (see Chapter 4.3).

  3. Click Manage tags.

  4. Click for the tag that should be removed.

  5. Click Save tags.

    Note

    Depending on the number of assets the tag is removed from, it may take a while until the tag is not displayed anymore.

6.3.4 Filtering for Tags

Filtering for tags can be done as described in Chapter 4.3.

The operator exists (yes/no) can be used to filter for all assets with or without a tag with a specific name. This can be used to manage the asset tags, for example to ensure that a desired set of assets is tagged with a Department or Location tag.

All used tag names are displayed in a sub-menu.

If no tags are available, the Tag filter is not offered.

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).

_images/vulnerabilities-overview.png

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).

_images/vulnerability-details.png

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).

_images/affected-assets.png

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:

  1. Select Analysis > Vulnerabilities in the menu.

  2. Filter the vulnerabilities to all those that should be exported (see Chapter 6.4.2).

  3. 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:

  1. Select Analysis > Vulnerabilities in the menu.

  2. Filter the vulnerabilities to all those that should be exported (see Chapter 6.4.2).

  3. 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:

  1. Select Analysis > Vulnerabilities in the menu.

  2. Click on the number of assets in the Affected assets column.

  3. 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.