Reports & Vulnerability Management

What this covers

How the Greenbone Enterprise Appliance turns scan results into reports and how to work with them end to end: configuring and managing report formats, reading, filtering, exporting and importing reports, triggering alerts, building delta reports, and the Quality of Detection (QoD) concept. It also covers the central result and vulnerability views, vulnerability trend, and the three remediation tools — remediation tickets, notes, and overrides (including false positives).

Source scope

Based on the Greenbone Enterprise Appliance manual (GOS 22.04 / OPENVAS SCAN 22.04), chapter 11, verified June 2026. Report handling is the same in the free Community Edition.

Section references below (e.g. §11.2) point at the manual chapter numbers. Not all appliance models support every menu option — check the model tables in the manual's chapter 3 to confirm a feature is available for your appliance.

The results of a scan are summarized in a report. The appliance saves all reports of all scans ever run in a local database, so historical information stays accessible. Once a scan has started, the report of the results found so far can be viewed; when the scan completes, the status changes to Done and no more results are added.

1. Configuring and Managing Report Formats

A report format defines how a report is generated from the raw scan results. Many formats reduce the available data to present it meaningfully, and they let you export report information into other document formats for processing by third-party applications (connectors). The file name used for an exported report is configurable in the user settings (§8.7).

The native appliance XML format contains all data and is the format to use when importing an exported report onto another appliance — for that, create a container task (§10.5). See Scanning a System for container tasks. (§11.1)

1.1 Default Report Formats

All default report formats are data objects distributed via the feed; they are downloaded and updated with each feed update. (§11.1.1)

note

Report formats may be deprecated. They are marked with (Deprecated) on the web interface and are no longer documented. A deprecated format can no longer be used — an export in such a format may produce an empty or otherwise unusable file.

If no default report formats are available, a feed update may be needed, or the Feed Import Owner may need to be set (§7.2.1.10.1). Default report formats cannot be edited. They can only be deleted temporarily by the Feed Import Owner or a super administrator — they reappear on the next feed update. To delete one permanently, the Feed Import Owner must delete it and then be changed to (Unset).

The following report formats are available by default:

Report format	Use
Anonymous XML	Anonymous version of the XML format; IP addresses are replaced by random IP addresses.
ARF: Asset Reporting Format v1.0.0	Report representing the NIST Asset Reporting Format.
CPE – Common Platform Enumeration CSV Table	Selects all CPE tables into a single comma-separated file.
CSV Hosts	Comma-separated file containing the discovered systems.
CSV Results	Comma-separated file with the results of a scan.
GCR PDF – Greenbone Compliance Report	Complete compliance report for compliance audits, all vulnerabilities in graphical form as PDF. English.
GSR HTML – Greenbone Security Report	Complete security report with all vulnerabilities and results; HTML with dynamically sortable lists (JavaScript required). English.
GSR PDF – Greenbone Security Report	Complete security report, all vulnerabilities in graphical form as PDF. Topology graph omitted above 100 hosts. English.
GXCR PDF – Greenbone Executive Compliance Report	Shortened compliance report for management, graphical PDF. English.
GXR PDF – Greenbone Executive Report	Shortened security report for management, graphical PDF. Topology graph omitted above 100 hosts. English.
LaTeX	LaTeX source text. English.
NBE	Old OpenVAS/Nessus format; no support for notes, overrides and some additional information.
PDF	Complete, neutral report as PDF. English.
TLS Map	Report format for TLS Map scans (§12.6).
Topology SVG	Presents the results as an SVG picture.
TXT	Text file; useful when sent by e-mail. English.
Verinice ISM	Import file for the ISMS tool verinice (§18.1).
Verinice ISM all results	Import file for the ISMS tool verinice (§18.1).
Verinice ITG (obsolete)	Import file for the ISMS tool verinice (§18.1).
Vulnerability Report HTML (recommended)	New complete security report with all vulnerabilities and results; opens in a browser or HTML viewer. English.
Vulnerability Report PDF (recommended)	New complete security report, all vulnerabilities in graphical form as PDF. Limited to the first 500 results per host (a warning is shown on the title page when results are left out). English.
XML	Native XML export. Contains all results and does not format them at all.

1.2 Managing Report Formats

List all report formats via Configuration > Report Formats. For each format the list shows: (§11.1.2)

• Name — name of the report format.
• Extension — the downloaded file name is the report UUID plus this extension; it also helps the browser launch a compatible application when the content type is not recognized.
• Content Type — specifies the format in use and is sent on download so the browser can launch a compatible application. It is also used internally to offer suitable plug-ins in context (for example, all text/* plug-ins are offered when sending a report by e-mail).
• Trust (Last Verified) — each report format plug-in must be digitally signed by Greenbone; signatures are distributed via the Greenbone Enterprise Feed. The trust check is automatic, and its result appears in this column.
• Active — a format is only available in the selection menus when activated. Newly imported formats start deactivated, and a format can only be activated once it is trusted.

List-page actions: move a format to the trashcan (while it stays in the trashcan it is not re-downloaded on the next feed update), and edit a format (only self-created formats can be edited). A drop-down below the list lets you move several formats to the trashcan at once. The details page (click the format name) offers the same actions plus opening the manual chapter and adding a new format.

1.3 Adding a Report Format

caution

To prevent abuse, every additionally imported report format must be reviewed and digitally signed by Greenbone. Formats not signed by Greenbone are not supported in GOS and cannot be used.

To import a report format (§11.1.3):

1. Obtain a report format plug-in that has been reviewed and accepted by Greenbone.
2. Select Configuration > Report Formats, then start the import.
3. Click Browse... and select the plug-in.
4. Click Save. The imported format appears on the Report Formats page.
5. In the format's row, open it for editing.
6. For Active, select the radio button Yes.
7. Click Save.

2. Using and Managing Reports

List every report of every scan via Scans > Reports. The total number of reports for a task is shown on the Tasks page in the Reports column; click that number to open the Reports page filtered to that task. Clicking the date in the Last Report column opens the details page of that task's latest report. (§11.2)

Per report the list shows:

• Date — date and time of report creation.
• Status — status of the corresponding task.
• Task — the corresponding task.
• Severity — highest severity found by the scan.
• High / Medium / Low / Log / False Pos. — number of vulnerabilities found per severity.

Report actions: create a delta report (see section 2.5) and delete the report. A drop-down below the list deletes several reports at once.

2.1 Reading a Report

Click a report's date to open its details. The following registers are available: (§11.2.1)

• Information — general information about the scan.
• Results — all results in this report (see section 2.1.1).
• Hosts — scanned hosts with names, IP addresses, detected operating systems, vulnerability counts per severity, and highest severity found.
• Ports — scanned ports with port name, number of hosts, and highest severity found.
• Applications — scanned applications with CPE, number of hosts, number of result occurrences detecting that CPE, and highest severity found.
• Operating Systems — scanned operating systems with system name, host name, number of scanned hosts, and highest severity found.
• CVEs — CVEs found by the scan.
• Closed CVEs — CVEs of originally detected vulnerabilities already confirmed solved during the scan.
• TLS Certificates — TLS certificates found by the scan.
• Error Messages — errors that occurred during the scan.
• User Tags — assigned tags (§8.4).

Columns can be sorted ascending or descending by clicking the column title. From the upper-left corner you can, among other actions: open the manual chapter; show all report formats; add report contents that have at least a QoD of 70 % and enabled overrides to the assets (or remove report contents from the assets); show the corresponding task; open Results, Vulnerabilities or TLS Certificates filtered to this report; open Performance for the scan's duration; download a filtered report (section 2.2); and trigger an alert to send a report (section 2.4).

2.1.1 Results of a Report

The Results register lists all vulnerabilities detected by the appliance. (§11.2.1.1)

note

By default, overrides are not applied to the results. Apply them by filtering the report and setting Apply Overrides to Yes (see section 2.1.3).

Per result the following is displayed:

• Vulnerability — name of the found vulnerability; click it for vulnerability details. Vulnerabilities with an attached note or an attached ticket are marked with their respective icon. If the column appears empty the respective VT has not been updated yet.
• Solution type — see the table below.
• Severity — the vulnerability's severity (CVSS, §14.2.3), shown as a bar.
• QoD — Quality of Detection, a value between 0 % and 100 % describing the reliability of the detection. By default only results detected by VTs with a QoD of 70 % or higher are shown; the filter can be lowered (§8.3.1). See section 2.6.
• Host — host the result was found on (IP address and name shown separately).
• Location — port number and protocol type used to find the vulnerability on the host.
• Created — date and time of report creation.

Solution types each result may offer:

Solution type	Meaning
Vendor patch	A vendor patch is available.
Workaround	A workaround is available.
Mitigation	A mitigation by configuration is available.
Will not fix	No fix is and will be available.
No fix available	No solution exists.

2.1.2 Interpreting a Report

When interpreting results, keep the following in mind (§11.2.1.2):

• False positives — a false positive is a finding describing a problem that does not really exist. Scanners often find evidence pointing at a vulnerability without being able to make a final judgment. The appliance reports all potentially existing vulnerabilities (rather than risk a false negative) because a user can identify and manage false positives. If you know a false positive exists, configure an override (section 5).
• Multiple findings, one cause — an old software package often triggers many VTs and therefore many alerts; installing a current package removes many vulnerabilities at once.
• High and Medium — these are the most important and should be addressed with priority, high before medium. Deviate only in exceptional cases (for example, when a high finding is unreachable through the firewall).
• Low and Log — filtered out by default but useful for detailed understanding; considering them increases security. A typical Log result is a service banner exposing name and version number, which is useful to an attacker if that version has a known vulnerability.

2.1.3 Filtering a Report

A report often contains many findings, so the complete report and filtered subsets can both be displayed and downloaded. To filter (§11.2.1.3):

1. Open the filter in the filter bar.
2. Enter a keyword in the Filter input box.
3. For Apply Overrides select Yes to enable overrides, or No to disable them (section 5).
4. Activate Only show hosts that have results if desired.
5. For QoD, select the desired QoD (section 2.6).
6. For Severity (Class), activate the checkboxes of the desired severity classes.
7. For Solution Type, select the radio buttons of the desired solution types.
8. Enter part of a vulnerability name, host or location in the relevant input box.
9. Click Update.

2.2 Exporting a Report

To export a report (§11.2.2):

1. Select Scans > Reports.
2. Click a report's date to open its details page.
3. Open the export action — the scan report content composer opens. The applied filter is shown in the Filter input box and cannot be changed here; change it via filtering (section 2.1.3).
4. Activate Notes to include attached notes, and Overrides to label enabled overrides and include their text. Overrides are only considered if they were enabled when filtering the report.
5. Select the format in the Report Format drop-down list.
6. Optionally activate Store as default to keep the settings for future exports.
7. Click OK, then save with Save File.

2.3 Importing a Report

To import a report (§11.2.3):

1. Select Scans > Reports.
2. Start the import.
3. Click Browse... and select the report's XML file.
4. In Container Task, select the container task the report should be added to (a new container task can be created here; see §10.5).
5. Select Yes to add the report to the assets.
6. Click Import.

2.4 Triggering an Alert for a Report

An alert often includes sending a report. The report sent by an alert is subject to a filter defined in the alert content composer (§10.12). Triggering an alert for a report adds a second filter originating from the scan report content composer (section 2.2). To trigger an alert manually (§11.2.4):

1. Select Scans > Reports.
2. Click a report's date to show the results.
3. Filter the report (via the Powerfilter, section 2.1.3, or by selecting a register) so that only the results to send are shown. The alert content composer filter is applied additionally — to neutralize it, adjust the report filter so that no results are filtered out.
4. Open the alert action — the scan report content composer opens. The applied display filter is shown in Filter and cannot be changed here.
5. Activate Notes and/or Overrides as needed (overrides are only considered if enabled when filtering).
6. Select the alert in the Alert drop-down list (a new alert can be created here; see §10.12).
7. Optionally activate Store as default.
8. Click OK.

2.5 Creating a Delta Report

If a single task has more than one report, a delta report can be created (§11.2.5):

1. Select Scans > Tasks.
2. Click the total number of reports in the Reports column — the Reports page opens, filtered to that task.
3. In the Actions column, select the newer report; its selection icon then greys out.
4. Select the older report in the Actions column — the delta report is displayed and can be exported.

The Delta column shows the type of each delta result:

Type	Symbol	Meaning
Gone	[-]	The result exists in the second (older) report but not in the first (newer) report.
New	[+]	The result exists in the first (newer) report but not in the second (older) report.
Same	[=]	The result exists in both reports and is equal.
Changed	[~]	The result exists in both reports but is different.

Use delta_states= in the filter bar to show only specific types (§8.3): delta_states=g (Gone), delta_states=n (New), delta_states=s (Same), delta_states=c (Changed). Combine letters to show several at once, e.g. delta_states=gs shows Gone and Same.

2.6 Quality of Detection (QoD) Concept

The Quality of Detection (QoD) is a value between 0 % and 100 % describing the reliability of the executed vulnerability or product detection. The range allows fine-grained quality expression, but most tests use a standard methodology, so QoD types are associated with a QoD value. The list of types may be extended over time. (§11.2.6)

:::note QoD interpretation

• The QoD of a Detection result is higher than that of an actual Vulnerability result: it reflects the (reliable) quality of the product detection itself, not the quality of the related vulnerability tests, which may be unreliable for various reasons.
• The lowest applicable QoD is always used — for example, when multiple detection methods (remote, or local/authenticated) exist.
• By default only results detected by VTs with a QoD of 70 % or higher are shown; results below that are prone to false positives. When you lower the filter to show low-QoD results, it is your own responsibility to determine whether a result is a false positive (§8.3.1). :::

QoD	QoD type	Description
100 %	exploit	Detection happened via an exploit and is therefore fully verified.
99 %	remote_vul	Remote active checks (code execution, traversal attack, SQL injection, etc.) where the response clearly shows the presence of the vulnerability.
98 %	remote_app	Remote active checks where the response clearly shows the presence of the vulnerable application.
97 %	package	Authenticated package-based checks for, e.g., Linux(oid) systems.
97 %	registry	Authenticated registry-based checks for Microsoft Windows systems.
95 %	remote_active	Remote active checks where the response shows the likely presence of the vulnerable application or the vulnerability ("likely" = only rare circumstances would make the detection wrong).
80 %	remote_banner	Remote banner checks of applications that offer patch level in version (many proprietary products do).
80 %	executable_version	Authenticated executable version checks for Linux(oid) or Microsoft Windows systems where applications offer patch level in version.
75 %	(none)	Assigned to results processed without any QoD information (e.g., when migrating data from a legacy system to a currently supported system).
70 %	remote_analysis	Remote checks that perform some analysis but may not always be fully reliable depending on environmental conditions; suspected false-positive or false-negative edge cases may require user analysis (section 5).
50 %	remote_probe	Remote checks where intermediate systems such as firewalls may pretend correct detection, so it is unclear whether the application itself answered (e.g., for non-TLS connections).
30 %	remote_banner_unreliable	Remote banner checks of applications that do not offer patch level in version identification (e.g., 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 that are not always fully reliable, e.g., for Linux(oid) systems.
1 %	general_note	General note on a potential vulnerability without finding any present application.

3. Displaying All Existing Results

While a report contains only the results of a single scan, all results are saved in the internal database and can be viewed via Scans > Results. Powerfilters narrow the list to interesting results (§8.3). (§11.3)

Per result the list shows the same core fields as a report's Results register: Vulnerability (note/ticket icons apply; an empty column means the VT is not yet updated; external references and background information always appear in the details), Solution type, Severity (CVSS bar, §14.2.3), QoD (70 % default threshold, section 2.6), Host, Location, and Created. A drop-down below the list exports several results at once.

The result details page (click the result name) has the registers Information and User Tags. From the upper-left corner you can open the manual chapter, show all results, export the result as XML, create a note (section 4), create an override (section 5), create a ticket (section 6), and show the corresponding task or report.

4. Displaying All Existing Vulnerabilities

All vulnerabilities are likewise saved in the internal database and viewed via Scans > Vulnerabilities; Powerfilters apply (§8.3). (§11.4)

Per vulnerability the list shows:

• Name — title of the vulnerability.
• Oldest Result — date and time of the oldest result found for it.
• Newest Result — date and time of the newest result found for it.
• Severity — CVSS severity shown as a bar (§14.2.3).
• QoD — Quality of Detection (70 % default threshold; section 2.6).
• Results — number of results for this vulnerability; click the number to open Results filtered to it.

The vulnerability details page (click the name) offers, from the upper-left corner: open the manual chapter, show all vulnerabilities, export the vulnerability as XML, create a note (section 4), create an override (section 5), and show the corresponding results.

5. Trend of Vulnerabilities

If a task has run multiple times, the trend of discovered vulnerabilities is shown in the Trend column on the Tasks page (Scans > Tasks). The trend describes the change between the newest and the second-newest report. (§11.5)

Trend	Meaning
Up	In the newest report the highest severity is higher than in the second-newest report.
More	Highest severity is the same in both, but the newest report has more issues of that severity.
Same	Highest severity and the number of issues are the same in both.
Less	Highest severity is the same in both, but the newest report has fewer issues of that severity.
Down	In the newest report the highest severity is lower than in the second-newest report.

6. Notes, Overrides, and Tickets — What's the Difference?

These three tools all attach to a finding but do different things:

Tool	What it does	Effect on results
Note	Adds a comment to a VT, shown in reports. Can be attached to a specific result, task, severity, port or host, or generalized to all reports.	None — purely informational.
Override	Modifies the severity of a result (for example, to handle a false positive or an accepted risk, or to raise a Log finding locally).	Changes how a result is displayed when overrides are enabled.
Ticket	Tasks a user (or yourself) with resolving a finding, with a status workflow (Open / Fixed / Fixed verified / Closed).	None on severity — it is remediation tracking.

7. Using Tickets

Tickets let users task others or themselves with resolving scan findings. When you create a ticket for another user, that user gains read and write access to the ticket and automatic read access to the related task, reports and results. (§11.6)

note

If a ticket assignment is withdrawn from a user, the read access to the task and reports remains; permissions are checked and revoked on the task's details page (§10.8). If multiple tickets for results of the same report are assigned to the same user, the same permission appears multiple times. If the assignee of a ticket is changed, the new assignee does not automatically get read access — the ticket owner must grant it via the task's details page.

7.1 Creating a Ticket

1. Either via Scans > Reports (click a report date to show results) or via Scans > Results, click an item in the Vulnerability column and open the result's details page. (§11.6.1)
2. Create a new ticket.
3. In Assign to User, select the assignee.
4. Enter a note in the Note input box.
5. Click Save. The number of tickets for a result is shown in the upper-left corner of the result's details page.

7.2 Changing the Status of a Ticket

A ticket can have the following status (§11.6.2):

Status	Meaning
Open	The vulnerability has not been fixed yet.
Fixed	The vulnerability has been fixed.
Fixed verified	The task ran again and the vulnerability was no longer found. Set automatically.
Closed	The fix was verified or the ticket is no longer required.

To change the status:

1. Select Resilience > Remediation Tickets.
2. In the ticket's row, edit it.
3. Select the new status in the Status drop-down list.
4. Select the user in the Assigned User drop-down list.
5. Enter a note for the new status.
6. Click Save.

7.3 Setting an Alert for a Ticket

Ticket alerts can fire when a new ticket is received, when the status of an assigned ticket changes, or when the status of an own ticket changes. Set one up via Configuration > Alerts, creating a new alert and defining it. (§11.6.3)

The alert details include:

• Name — freely chosen.
• Comment — optional additional information.
• Event — Ticket Received (a new ticket is assigned to oneself), Assigned Ticket Changed (status of a ticket assigned to oneself changes), or Owned Ticket Changed (status of a ticket assigned to another user changes).
• Method — one method per alert. To trigger different alerts for the same event, create multiple alerts linked to the same task. Methods:
  • Email — sent to the given address; transmission can be encrypted with a configurable S/MIME or GPG key (Email Encryption).
  • Start Task — starts an additional task selected in Start Task.
  • System Logger — sends the alert to a Syslog daemon (the Syslog server is defined via the console, §7.2.12).

7.4 Managing Tickets

List all tickets via Resilience > Remediation Tickets. Each row shows: Vulnerability, Severity, Host, Solution Type, Assigned User, Modification Time, and Status. (§11.6.4)

List actions: move the ticket to the trashcan (only the owner may do this), edit, and clone. A drop-down below the list moves several tickets to the trashcan or exports them at once. The details page (click the ticket name) has the registers Information and User Tags, and offers clone, edit, move to trashcan, and export as XML.

8. Using Notes

Notes add comments to a VT and appear in reports. A note can be attached to a specific result, task, severity, port or host (so it appears only in specific reports), or generalized so it appears in all reports. (§11.7)

8.1 Creating a Note

Through a scan result (the simplest way) (§11.7.1.1):

1. Select Scans > Reports and click the report date to show results.
2. Select the Results register.
3. Click a result in the Vulnerability column.
4. Open the result's details page.
5. Create a new note from the upper-left corner.
6. Define the note, then click Save. The note then appears on the result's details page.

On the Notes page (§11.7.1.2):

1. Select Scans > Notes and create a new note.
2. Enter the VT ID in NVT OID.
3. Define the note. You can enter IP address ranges and CIDR blocks in Hosts to cover entire subnets without listing every host. Selecting the radio button Any for hosts, locations, severities, tasks or results generalizes the note.
4. Click Save.

8.2 Managing Notes

List all notes via Scans > Notes. List actions: move to trashcan, edit, clone, and export as XML; a drop-down below the list moves or exports several at once. The details page (click the note name) has the registers Information, User Tags and Permissions (§9.4), and offers create, clone, edit, move to trashcan, and export. (§11.7.2)

9. Using Overrides and False Positives

An override modifies the severity of a result. Overrides are especially useful for managing results detected as a false positive that were given a critical severity but should carry a different severity in future, for raising results given only severity Log to a higher local severity, and for managing acceptable risks. (§11.8)

:::tip Override and false-positive handling The appliance deliberately reports every potentially existing vulnerability rather than risk a false negative. When you have confirmed a finding is a false positive (or an accepted risk), create an override to adjust its severity instead of ignoring it — this keeps the finding documented and auditable. Remember that overrides are not applied to results unless you set Apply Overrides to Yes in the filter. :::

9.1 Creating an Override

Through a scan result (§11.8.1.1):

1. Select Scans > Reports, click the report date to show results.
2. Select the Results register, click a result in the Vulnerability column.
3. Open the result's details page, then create a new override.
4. Define the override and select the new severity in New Severity, then click Save.

When creating an override through a scan result, some settings are pre-filled. The fields are:

• NVT — the VT the override applies to.
• Active — whether the override is active; activation for an arbitrary number of days is possible.
• Hosts — host or host range for which the result must be found for the override to apply. IP ranges and CIDR blocks are supported; a range is written with a minus, e.g. 198.168.1.1-198.168.1.25. A range larger than 4096 is not supported. Conflicting overrides (e.g. one for a host range and another for a host inside that range) are not permitted.
• Location — port for which the result must be found, or Any. A specific port is a number followed by /tcp or /udp.
• Severity — range of severity of the VT the override should apply to.
• New Severity — severity the VT should have after the override is applied.
• Task — tasks the override should apply to.
• Result — results the override should apply to. Select Any if the override should apply to future reports.
• Text — describes the override in more detail.

If several overrides apply to the same VT in the same report, the most recent override is used.

On the Overrides page (§11.8.1.2): select Scans > Overrides, create a new override, enter the VT ID in NVT OID, define it (same fields as above), select New Severity, and click Save.

9.2 Managing Overrides

List all overrides via Scans > Overrides. List actions: move to trashcan, edit, clone, and export as XML; a drop-down below the list moves or exports several at once. The details page (click the override name) has the registers Information, User Tags and Permissions (§9.4), and offers create, clone, edit, move to trashcan, and export. (§11.8.2)

9.3 Disabling and Enabling Overrides

Because overrides change how results are displayed, they can be enabled or disabled via the filter (§11.8.3):

1. Open the filter in the filter bar.
2. For Apply Overrides select Yes to enable overrides, or No to disable them.
3. Click Update.

Overrides can also be labelled in exported reports (section 2.2).

Related

• Greenbone / OpenVAS Guide
• Scanning a System
• Managing Assets & SecInfo