OpenVAS with Dradis
Recognize and manage risks
OpenVAS is a full-featured vulnerability scanner capable of a range of security tests. This integration makes the structure of nodes, issue, and evidence available in Dradis and contain the same information about the hosts, ports, services as the OpenVAS file.
The OpenVAS® name, if trademarked, is the intellectual property of the vendor. Uses of the OpenVAS® name in this page are for identification purposes only and do not imply an endorsement by the trademark owner. Dradis is not endorsed or owned by, or affiliated with, the OpenVAS® vendor.
Allen Harper
Executive Vice President at Tangible SecurityAvailable for
Vendor
Support Documentation
OpenVAS, now part of the Greenbone Vulnerability Management (GVM) framework, is one of the most widely deployed open-source vulnerability scanners in the industry. It maintains a feed of over 100,000 Network Vulnerability Tests (NVTs) covering everything from expired SSL certificates to critical remote code execution flaws. The challenge with OpenVAS is not running the scan — it is making sense of the results afterward. A typical scan against a small corporate network produces hundreds of findings across dozens of hosts, each carrying its own risk factor, CVSS score, NVT reference, and remediation guidance. Copying that data into a pentest report by hand is tedious, error-prone, and a poor use of your time.
Dradis solves this by importing OpenVAS XML reports directly, creating structured Issues, Evidence, and Nodes that reflect the vulnerability-host-port relationships in your scan. Each unique NVT becomes an Issue with its CVSS score, description, and remediation. Each instance of that vulnerability on a specific host and port becomes Evidence linked to both the Issue and the host Node. The result is an organized project where you can review findings by vulnerability type or by host, add manual observations, and generate client-ready reports without transcribing a single line from the scanner output.
| Detail | Value |
|---|---|
| Dradis Plugin | Dradis::Plugins::OpenVAS |
| Supported File Format | .xml (OpenVAS XML report) |
| Available In | Community Edition and Professional |
| Data Imported | Issues (one per unique NVT), Evidence (per host/port instance), Nodes (one per host IP) |
| Typical Import Time | ~2 seconds for 20 results, ~8 seconds for 200+ results |
OpenVAS is a full vulnerability scanner, so its data maps to the classic Issues + Evidence + Nodes model in Dradis. This is the same structural pattern used by Nessus and Qualys — fundamentally different from network scanners like Nmap, which only create Nodes and Notes.
Issues: Each unique NVT (Network Vulnerability Test) in the scan results becomes a single Issue in Dradis. NVTs are identified by their OID — a structured identifier following the pattern 1.3.6.1.4.1.25623.1.0.XXXXX. If the same NVT fires against three different hosts, Dradis creates one Issue and three pieces of Evidence. The Issue contains the vulnerability title, CVSS base score, description, solution, affected software, and external references (CVE, BID, XREF). This deduplication means your Issues list shows distinct vulnerabilities, not repeated copies for every affected host.
Evidence: Each <result> element in the OpenVAS XML creates one Evidence record in Dradis. Evidence is linked to both the parent Issue (by NVT OID) and the host Node (by IP address). Evidence captures the port where the vulnerability was detected (e.g., 443/tcp, mysql (3306/tcp), or general/tcp for host-level checks) and the per-instance description that OpenVAS provides. This description often contains host-specific details — for example, the actual expired certificate date, the specific weak cipher suite detected, or the exact version string returned by a service probe.
Nodes: Each unique host IP address in the scan results becomes a Node in Dradis. Nodes appear under the Scanner output parent in the sidebar tree. The node label is set to the IP address, and the hostname (if resolved during the scan) is stored as a node property. All Evidence records for that host appear under its Node, giving you a per-host view of every vulnerability affecting that target.
Unlike Nikto and Nmap, the OpenVAS plugin does not create Notes. The entire data model is Issues, Evidence, and Nodes — a clean three-tier structure that maps directly to the vulnerability-instance-host relationship that pentest reports require.
| Dradis Field | Template Variable |
|---|---|
| Title | {{ openvas[result.name] }} |
| CVSSv2 | {{ openvas[result.cvss_base] }} |
| AffectedSoftware | {{ openvas[result.affected_software] }} |
| Description | {{ openvas[result.summary] }} |
| Recommendation | {{ openvas[result.solution] }} |
| References | CVE: {{ openvas[result.cve] }}\nCVSS Vector: {{ cvss_base_vector }}\nBID: {{ openvas[result.bid] }}\nOther: {{ openvas[result.xref] }} |
| RawDescription | {{ openvas[result.description] }} |
| Dradis Field | Template Variable |
|---|---|
| Port | {{ openvas[evidence.port] }} |
| Description | {{ openvas[evidence.description] }} |
The plugin exposes a rich set of fields for custom templates (available via the Mappings Manager in Dradis Pro):
Issue fields (result.*):
| Field | Description |
|---|---|
result.name |
NVT name / vulnerability title (e.g., "SSL/TLS: Certificate Expired") |
result.threat |
Risk factor after overrides: High, Medium, Low, or Log |
result.original_threat |
Original risk factor before any overrides applied in OpenVAS |
result.cvss_base |
CVSS v2 base score (0.0 to 10.0) |
result.cvss_base_vector |
CVSS v2 vector string (e.g., AV:N/AC:L/Au:N/C:N/I:N/A:N) |
result.risk_factor |
Risk classification derived from CVSS |
result.summary |
Brief synopsis of the vulnerability |
result.description |
Full technical description from the NVT |
result.insight |
Technical insight into the vulnerability mechanism |
result.impact |
Impact description if the vulnerability is exploited |
result.impact_level |
Affected impact level (Application, System, Network) |
result.affected_software |
Software or OS versions affected |
result.solution |
Recommended remediation steps |
result.solution_type |
Solution category: VendorFix, Mitigation, WillNotFix, NoneAvailable |
result.vuldetect |
Detection method used by the NVT |
result.info_gathered |
Information gathered during the check |
result.cve |
Associated CVE identifier(s) |
result.bid |
Bugtraq ID(s) |
result.xref |
Other external references (URLs, advisories) |
result.notes |
User-added notes/annotations from OpenVAS |
result.overrides |
Override rules applied to modify severity |
Evidence fields:
| Field | Description |
|---|---|
evidence.port |
Port and protocol where the finding was detected (e.g., 443/tcp, general/tcp) |
evidence.description |
Host-specific details for this instance of the vulnerability |
OpenVAS results must be exported in XML format. There are two ways to get the XML report, depending on whether you use the web interface or the command line.
From the Greenbone Security Assistant (GSA) web interface:
From the command line using gvm-cli:
bash
gvm-cli --gmp-username admin --gmp-password secret \
socket --socketpath /run/gvmd/gvmd.sock \
--xml '<get_reports report_id="REPORT-UUID-HERE" format_id="a994b278-1f62-11e1-96ac-406186ea4fc5"/>'
The format_id value a994b278-1f62-11e1-96ac-406186ea4fc5 is the built-in XML format identifier in GVM. You can also use gvm-cli to list available formats if your installation uses a different ID.
Key points about the export:
<report> as its root element (or within an outer <get_reports_response> wrapper)Log into Dradis and open your project. Click the Upload tab in the top navigation bar to access the file upload interface.
The Upload interface in Dradis. You will select the tool plugin (1), choose the default state for imported records (2), and pick your XML file (3).
From the Tool you are uploading output from dropdown, select Dradis::Plugins::OpenVAS.
Select Dradis::Plugins::OpenVAS (1) from the tool dropdown. This tells Dradis to parse the file using the OpenVAS XML importer.
Make sure you select the correct plugin. OpenVAS XML has a different structure from Nessus (.nessus) or Qualys (SCAN XML), and selecting the wrong plugin will result in an empty import or parsing errors.
Click Choose File and browse to your exported OpenVAS XML report. The filename will typically be something like report-2026-02-15T093000.xml or a UUID-based name if exported via gvm-cli.
The OpenVAS XML file is selected and ready to upload. Click the upload button to begin the import.
After uploading, the Output console displays the import progress. You will see log entries for each host processed and each NVT identified:
Processing OpenVAS XML report...
Creating node for host 10.10.20.5 (webserver.corp.local)
Creating issue: SSL/TLS Certificate Expired (OID: 1.3.6.1.4.1.25623.1.0.103955)
Adding evidence on port 443/tcp
Creating issue: Apache HTTP Server ETag Header Information Disclosure
Adding evidence on port 80/tcp
Creating node for host 10.10.20.10 (db.corp.local)
Creating issue: MySQL/MariaDB Weak Password
Adding evidence on port mysql (3306/tcp)
Creating issue: SSH Weak Encryption Algorithms Supported
Adding evidence on port 22/tcp
...
Worker process completed.
Each "Creating issue" line means a new NVT OID was encountered and a new Issue was created. "Adding evidence" means an Evidence record was created linking the Issue to the current host Node and port.
The import log (1) shows the plugin processing each host and NVT from the XML file. "Worker process completed" at the end confirms a successful import.
Watch for these key indicators:
Click the Issues tab in the top navigation to see all imported vulnerabilities. Each unique NVT from the scan appears as a separate Issue, deduplicated across hosts.
The Issues list (1) shows all unique vulnerabilities imported from the OpenVAS scan. Each row represents a distinct NVT, regardless of how many hosts are affected. In this import, you can see findings like SSL/TLS Certificate Expired, Apache ETag Header Information Disclosure, Apache HTTP Server Version Detection, OS Detection, MySQL/MariaDB Weak Password, SSH Weak Encryption Algorithms, and HTTP TRACE Methods Enabled.
The Issues list gives you a vulnerability-centric view of the scan results. Notice how the seven unique NVTs are listed once each, even though some affect both hosts. The risk levels range from High (SSL/TLS Certificate Expired, MySQL/MariaDB Weak Password) through Medium (SSH Weak Encryption Algorithms, Apache ETag Information Disclosure, HTTP TRACE Methods Enabled) to Log (Apache HTTP Server Version Detection, OS Detection).
Click any Issue to see its full details. The Issue detail view shows all the fields imported from the NVT, including the vulnerability description, CVSS score, affected software, solution, and external references.
The Issue detail view (1) for an imported OpenVAS finding. Fields include Title, CVSSv2 score, AffectedSoftware, Description, Recommendation (solution), References (CVE, BID, XREF), and RawDescription. The Evidence section at the bottom lists every host/port instance where this vulnerability was detected.
Key things to notice in the Issue detail:
result.summary field, which contains the NVT synopsis — a concise explanation of what the vulnerability is and why it matters.result.solution field, which provides specific remediation guidance. OpenVAS categorizes solutions as VendorFix (apply a patch), Mitigation (workaround), WillNotFix (vendor has declined to fix), or NoneAvailable (no fix exists yet).result.description from the NVT, which often contains more technical detail than the summary — detection methods, version checks, and configuration specifics.Switch to the sidebar node tree and expand the Scanner output section. Each host IP address from the scan appears as a child node.
The sidebar node tree (1) with Scanner output expanded. Each host IP from the OpenVAS scan appears as a separate node (2). In this example, you can see nodes for 10.10.20.5 (webserver.corp.local) and 10.10.20.10 (db.corp.local).
Click on a host node to see its properties and the Evidence records associated with that target.
The host node view (1) for 10.10.20.5 (webserver.corp.local). Node properties include the IP address and hostname. The Evidence records linked to this node are listed below, showing every vulnerability instance detected on this specific host — including SSL/TLS Certificate Expired on port 443/tcp, Apache ETag Information Disclosure on port 80/tcp, and HTTP TRACE Methods Enabled on port 80/tcp.
The host node provides a target-centric view — instead of browsing by vulnerability type (Issues), you can see everything that affects a single server. This is particularly useful when writing per-host remediation sections in your report, or when working with system administrators who need to know exactly what to fix on their specific machine.
Click on an Evidence record under a host node to see the per-instance details. Evidence contains the specific port and description for this occurrence of the vulnerability on this host.
The Evidence detail view (1) shows the port where the vulnerability was detected and the instance-specific description. The Port field (2) identifies the exact service (e.g., "443/tcp" or "mysql (3306/tcp)"). The Description field (3) contains host-specific details that differ from the general Issue description — such as the actual certificate expiry date, the specific weak cipher detected, or the exact version string returned by the service.
Evidence is where you find the host-specific proof that a vulnerability exists. While the parent Issue describes the vulnerability in general terms ("SSL/TLS Certificate Expired"), the Evidence provides the concrete details ("The certificate on 10.10.20.5:443 expired on 2025-12-31 for CN=webserver.corp.local"). This separation between general vulnerability information and specific instance data is what makes the Issues + Evidence model so powerful for reporting.
The OpenVAS project underwent a significant rebranding. What was once "OpenVAS" (Open Vulnerability Assessment System) is now officially called Greenbone Vulnerability Management (GVM). The scanner component retains the OpenVAS name, but the management daemon is gvmd, the web interface is Greenbone Security Assistant (GSA), and the vulnerability feed is the Greenbone Community Feed. In Dradis, the plugin is still labeled Dradis::Plugins::OpenVAS because the XML report format has remained consistent across the rename. Whether you are running OpenVAS 9, GVM 10, GVM 20, GVM 21, or GVM 22, the same Dradis plugin handles the import.
Every vulnerability test in OpenVAS has a unique OID (Object Identifier) following the IANA enterprise arc for Greenbone: 1.3.6.1.4.1.25623.1.0.XXXXX. The Dradis plugin uses this OID as the deduplication key for Issues. If you import two OpenVAS reports from different scans that both detected "SSL/TLS Certificate Expired" (OID 1.3.6.1.4.1.25623.1.0.103955), Dradis creates the Issue once and adds Evidence records for each new host/port combination. This is important to understand when you run incremental scans or merge results from different scan targets — the Issues list stays clean while the Evidence accumulates.
OpenVAS uses four risk factor levels: High, Medium, Low, and Log (also labeled "None"). These map roughly to CVSS score ranges, but the mapping is not always one-to-one. A finding might have a CVSS base score of 4.3 (which would typically be Medium) but be classified as Low by the NVT author based on practical exploitability. The result.threat field contains the current risk factor (which may have been modified by overrides in OpenVAS), while result.original_threat preserves the original classification. When building report templates in Dradis Pro, you can reference either field to sort and categorize findings.
The Log risk factor deserves special attention. These are informational findings — service detection, OS fingerprinting, version enumeration — that do not represent vulnerabilities. In our sample import, both "Apache HTTP Server Version Detection" and "OS Detection" carry the Log risk factor with a CVSS score of 0.0. They are imported as Issues because they follow the same NVT structure, but they represent information gathering rather than security weaknesses. You may want to filter or archive Log-level Issues after import, or use them as supporting evidence for other findings.
OpenVAS packs structured metadata into a <tags> element within each NVT result, using pipe-delimited key-value pairs. The Dradis plugin parses these tags to populate fields like result.summary, result.solution, result.insight, result.impact, result.affected_software, result.vuldetect, and result.solution_type. If you examine the raw XML, you will see something like:
summary=The SSL/TLS certificate has expired.|solution=Replace the SSL/TLS certificate
with a new one.|solution_type=Mitigation|affected=All SSL/TLS enabled services|
vuldetect=Checks the certificate expiry date via the server's TLS handshake.
The plugin splits these pipe-delimited tags and makes each one available as a separate field in Dradis. This is why the Issue detail view shows cleanly separated Description, Recommendation, and AffectedSoftware fields even though they originate from a single <tags> string in the XML. Both the v6 format (older OpenVAS, where details were embedded in freeform <description> text) and the v7+ format (GVM 10+, with structured <tags>) are supported — the plugin auto-detects which parsing strategy to use.
OpenVAS works well alongside other vulnerability scanners in a Dradis project. A common workflow for thorough assessments is:
When multiple tools scan the same IP address, their data merges under the same host Node in Dradis. The Nmap port table, OpenVAS vulnerability evidence, and Nessus findings all appear together, giving you a comprehensive view of each target. This multi-scanner approach is valuable for validation — if both OpenVAS and Nessus flag the same SSL certificate issue on 10.10.20.5, you can be more confident in the finding. OpenVAS began as the open-source fork of Nessus before Tenable made Nessus proprietary, so the two scanners have significant NVT overlap, but each catches issues the other misses.
OpenVAS uses several port format conventions in the evidence.port field that you should be aware of when reviewing findings:
443/tcp, 22/tcp, 80/tcp — a numeric port with protocolmysql (3306/tcp), ssh (22/tcp) — includes the service name for claritygeneral/tcp — host-level checks that are not port-specific (e.g., OS Detection, TCP timestamp analysis)cpe:/a:apache:http_server:2.4.52 — Common Platform Enumeration identifiers for detected softwareIn our sample import, you would see 443/tcp for SSL/TLS Certificate Expired evidence on the web server, mysql (3306/tcp) for the MySQL/MariaDB Weak Password finding on the database server, and general/tcp for the OS Detection results on both hosts. When building report templates, the {{ openvas[evidence.port] }} placeholder will contain whichever format OpenVAS used for that specific result.
Verify that you selected Dradis::Plugins::OpenVAS from the plugin dropdown. If you accidentally selected a different plugin (such as Nessus or Qualys), the parser will not recognize the OpenVAS XML structure and will silently produce zero results. Also check that your XML file contains actual <result> elements — an empty scan report with no findings will import successfully but create nothing in Dradis.
This can happen when the XML file contains NVT definitions but no <result> elements with host-specific data. Some OpenVAS export modes produce summary-only reports that lack per-host instances. Make sure you exported the full scan report from GSA, not a filtered or summary view. Also verify that each <result> contains a <host> element with a valid IP address — the plugin needs the host IP to create Evidence and link it to a Node.
If you import the same OpenVAS XML file twice into the same Dradis project, Issues are deduplicated by NVT OID — you will not see duplicate Issues. However, Evidence records will be duplicated because each import creates new Evidence entries for every <result> in the XML. If you need to re-import cleanly, delete the existing Evidence records and host Nodes first, or start a fresh project.
When exporting via gvm-cli, the XML file may be wrapped in <get_reports_response> elements rather than starting directly with <report>. The Dradis OpenVAS plugin handles both formats — it will locate the <report> element inside the GMP response wrapper. However, if you manually edited the XML or concatenated multiple reports, the wrapper structure may be malformed. Open the file in a text editor and verify it has a single <report> element (possibly inside a <get_reports_response> wrapper).
OpenVAS scans of large networks can produce XML files exceeding 100MB. While Dradis can handle large files, the web upload may time out on slow connections. If this happens, try these approaches:
Many OpenVAS NVTs — especially informational detections and recently added tests — do not have associated CVE or BID identifiers. The result.cve and result.bid fields will contain "NONE" in these cases. This is not an import error; it reflects the upstream NVT data from the Greenbone Community Feed. For example, "Apache HTTP Server Version Detection" and "OS Detection" are purely informational NVTs that have no CVE association. You can supplement these findings with your own CVE research when writing your report.
For older v6 format reports (from OpenVAS versions before GVM 10), the plugin parses vulnerability details from the freeform <description> text by looking for section markers like "Summary:", "Impact:", and "Affected Software/OS:". If the NVT used non-standard labels or the description lacks these markers, some fields may import as empty. The result.description field will still contain the full raw text. In Dradis Pro, use the Mappings Manager to map the raw description to a single field rather than relying on parsed sub-fields.
| Feature | Community Edition | Professional |
|---|---|---|
| OpenVAS XML import | Yes | Yes |
| Default field mapping | Fixed template | Customizable via Mappings Manager |
| Custom Issue templates | No | Yes — remap any OpenVAS field to any Dradis field |
| Custom Evidence templates | No | Yes — add or remove Evidence fields |
| v6/v7 tag parsing fields | Fixed defaults | Full access to all parsed tag fields |
| Rules Engine | No | Yes — auto-categorize by risk factor, auto-tag by CVSS range |
| Report generation | Manual (HTML export) | Automated Word/Excel reports with OpenVAS field placeholders |
| Multi-project templates | No | Yes — standardize OpenVAS mappings across all engagements |
| Integration with ticketing | No | Yes — push findings to Jira, ServiceNow, etc. |
The Mappings Manager in Dradis Pro is particularly valuable for OpenVAS imports because of the rich metadata available in the NVT tag fields. You can build Issue templates that pull in summary, insight, impact, affected software, detection method, and solution type — surfacing the full depth of OpenVAS data without manual transcription. The Rules Engine can then automatically categorize findings by threat level, flag NVTs with vendor fixes available, or tag entries by CVSS score thresholds. For example, you could create a rule that marks all Issues where result.threat is "High" and result.solution_type is "VendorFix" as high-priority remediation items.
You now have your OpenVAS vulnerability scan data structured and organized in Dradis. From here you can:
{{ openvas[result.name] }}, {{ openvas[result.cvss_base] }}, and {{ openvas[result.solution] }} for each Issue.Ready to automate your OpenVAS reporting workflow? Dradis Pro includes the Mappings Manager for custom field templates, the Rules Engine for automatic severity classification, and one-click Word/Excel report generation with OpenVAS data pre-populated. Request a demo to see how it can save hours on every engagement.
Yes. The Dradis OpenVAS plugin supports XML reports from OpenVAS 6 through the latest GVM 22 releases. The core XML report structure — <report>, <results>, <result>, <nvt> — has remained consistent across all versions. The plugin auto-detects whether it is processing the v6 format (details in freeform <description> text) or v7+ format (details in structured <tags> elements). Whether your XML was exported from the classic OpenVAS web interface, the Greenbone Security Assistant (GSA), or via gvm-cli, Dradis will parse it correctly.
OpenVAS allows users to create "overrides" that change the severity of specific NVT results — for example, downgrading a High finding to Medium because a compensating control is in place. The Dradis plugin imports the post-override threat level in result.threat and preserves the original level in result.original_threat. Both fields are available in your report templates, so you can show the adjusted severity while noting the original classification for transparency.
Not during import — the Dradis plugin imports all results from the XML file regardless of severity. However, you can filter the Issues list in Dradis after import to focus on actionable findings. If you want to exclude Log-level results entirely, filter your OpenVAS report in GSA before exporting (set the minimum severity filter to exclude "Log" results). This is generally recommended for large scans where informational detections like OS Detection and service version checks can outnumber actual vulnerabilities by a factor of ten or more.
Dradis handles this cleanly. Issues are deduplicated by NVT OID, so importing a second scan that detected the same vulnerability will not create duplicate Issues. New Evidence records are created for any host/port combinations not already present. Host Nodes are matched by IP address and reused across imports. This makes it safe to import results from different scan configurations (e.g., a credentialed scan of 10.10.20.10 plus an unauthenticated scan of the same target) into the same project.
A CVSS base score of 0.0 indicates an informational finding — typically a detection or enumeration NVT. Examples from our sample include "Apache HTTP Server Version Detection" and "OS Detection." These NVTs confirm what software is running on a host but do not identify exploitable vulnerabilities. They appear as Issues in Dradis because they use the same NVT structure, but their result.threat will be "Log" and they represent reconnaissance data rather than security findings.
Absolutely. This is a common workflow for teams that use both scanners for validation and broader coverage. Import each file using its respective plugin (Dradis::Plugins::OpenVAS and Dradis::Plugins::Nessus). Both create Issues and Evidence under the same host Nodes (matched by IP address). You will see separate Issues from each scanner even when they detect the same underlying vulnerability, since each tool uses its own identifiers (NVT OIDs for OpenVAS, Plugin IDs for Nessus). This is actually useful — having independent confirmation from two scanners strengthens your findings and can reveal coverage gaps where one tool found issues the other missed.
In Dradis Community Edition, you can manually edit Issue titles or add custom fields to include your organization's severity rating. In Dradis Pro, the Rules Engine automates this: create rules that match on result.threat values (High, Medium, Low, Log) and automatically set a custom severity field to your organization's scale (Critical, High, Medium, Low, Informational). You can also create rules based on CVSS score ranges for more granular mapping — for example, mapping CVSS 9.0-10.0 to Critical, 7.0-8.9 to High, and so on.
Your email is kept private. We don't do the spam thing.