Importing Scanner Output as Findings

Most engagements include some scanner output: a Nessus run across an internal range, a Burp scan of an application, an Nmap sweep. Copying it into findings by hand is slow and error-prone, and pasting it in raw gives the client forty findings that are really four. This import takes the export of a scanner you ran yourself, against the scope you agreed, and turns it into findings on the engagement, written up like any other.

Where it is

Import from scanner sits beside Import from Library in the findings header of each phase of an engagement, and once on an engagement without phases. The findings it makes belong to that phase, exactly as if a tester had added them.

A firm that never imports scanner output can switch it off: untick Offer Import from scanner in the findings area under Settings, Findings, and the button goes.

What it reads

Sixteen formats, recognised by what the file contains rather than by its name:

The file chooser offers exactly what can be read: .nessus, .xml, .csv, .json, .jsonl and .sarif, up to 200 MB.

Nmap and Nikto give no severity of their own, so their results arrive as informational rather than with a rating the tool never gave, except where one of Nmap’s vulnerability scripts states a risk factor. testssl.sh reports every check it made, so the checks that passed and its informational lines are counted and left out rather than made into findings.

Nothing is written until you have seen it

Choosing a file adds nothing. The screen that opens shows what was read, before a single finding exists:

• How many results were read, from which file, and the format and tool it was recognised as.
• A count by severity, the scanner’s own words put into yours, so a Burp “Information” and a Nessus “info” are counted together.
• Anything the reader left out, and why: a false positive, a result the file marks fixed or passed, a scan’s own diagnostics.
• Every finding it will make, with its rating and the hosts it covers.
• Every field in the file, with a real value from it, and where that value goes.

A file that is broken, empty or in a format the reader does not know says so, and nothing is imported.

Choosing what to keep

What to keep sets the lowest severity brought in, and the counts change as you change it, so you see what you are about to discard. It keeps everything to begin with. Your choice is remembered for that client, because a client whose informational output you never write up is usually that client every time.

Sending a field somewhere else

Where a scanner puts something and where you want it are not always the same. Any field in the file can be pointed at another finding field, or set to Not used. What is offered is your own field list: the built-in fields your firm uses, under your names for them, Impact, your own custom fields, and the affected host. Only what this import writes onto a finding is offered, so nothing can be sent where nobody will see it.

Pointing a field at one that is already filled replaces it, except Evidence, which is added to. Your choices are remembered for that scanner’s format, for every client, since Nessus writes the same fields whoever it was run against.

The line above the list says how many of the file’s fields went nowhere. A scanner’s own codes, such as a Nessus plugin ID or service name, are counted there, because a finding does not keep them; the port and protocol head each host’s evidence instead. If a field with writing in it went unused, the list opens by itself, so it is not missed.

One finding for each issue

A scanner reports per host, and twenty-nine results are often two issues. Results with the same title, once case, punctuation and a trailing bracketed qualifier are set aside, become one finding listing every affected host. Version numbers are kept: “TLS Version 1.0 Protocol Detection” and “TLS Version 1.1 Deprecated Protocol” are different issues and stay apart.

• The worst severity of the group is kept, and the highest CVSS score with the vector it came with, so the metrics behind the number can be opened and checked against this client.
• The rating follows the score, as it does on the finding form: 9.0 and above is critical, 7.0 high, 4.0 medium and anything lower low.
• Each host’s scanner output is kept as evidence, under a heading naming the host and its port, exactly as the scanner wrote it.
• Its references are gathered, up to twelve links.

Where your Library has the issue, by its title or by a scanner’s title an entry has been linked to, the finding takes your title for it and your wording, for the fields your firm reuses from the Library, with your own score where the entry has one. Two scanner titles the Library knows as one issue become one finding.

Bringing in a later scan

A finding already in the phase with the same title is never added twice. Any host it does not list yet is added to it, and nothing written in it changes: the description, the rating and the evidence your tester wrote stay as they are. Importing the same file twice adds nothing.

The import never closes a finding. An issue a later scan no longer reports is for a tester to verify, and a file does not decide that for them.

After the import

The findings are saved in your name, as drafts unless your firm saves new findings as final (Settings, Findings, New findings are saved as), and they are findings like any other: edited, rewritten by AI to your style, added to the Library and reviewed in QA. None is shown to the client until somebody switches it on; Show to client, on the bar that appears when findings are ticked, releases a set of them at once.

The file is read in your browser and the findings are written from the page under your own sign-in, as the ones you add yourself are, so the export never passes through a server of Pental’s.

For finishing what the scanner started, see writing a pentest finding from your notes with AI, and for explaining the difference to a client, vulnerability scan or penetration test.