Deduplicating Scanner Results into One Finding per Issue

Four scanners pointed at the same estate will report the same weak cipher suites four times, under four names, on overlapping sets of hosts. Pasted into a report as they come, that is four findings a developer is asked to fix, when there is one fix to make. Pental brings them together before anything is written: one finding for each issue, whichever scanner reported it and whatever it called it, listing every host any of them saw it on.

Several files at once

Import from scanner, in the findings header of each phase of an engagement, takes several files in one go: choose them together in the file chooser. Each file is read as it would be on its own and recognised by what it contains, so a .nessus file, a Qualys XML report, an OpenVAS report and a testssl.sh JSON file can go in together. A file with nothing in it says so, and the others carry on.

Each file is read with the field mapping its scanner was given the last time it was imported on its own, since one screen cannot map several formats at once. The formats themselves, and choosing fields, are in importing scanner output as findings.

How it knows two results are one issue

Each result is matched to an issue in this order, the most certain first:

1. Your own Library. A title it holds, or a scanner title one of its entries has been linked to, makes the result that entry, under your title for it.
2. The finding library. A scanner’s own identifier for the issue (a Nessus plugin, a Nuclei template, a testssl.sh check), a title scanners are known to give it, a pattern over the title, or, for a scanner that files a kind of issue under one family, the family. The result takes the library’s name for the issue.
3. Its CVEs. Two scanners’ names for the same advisories are one finding.
4. Its title, with case, punctuation and a trailing bracketed qualifier set aside, as before.

What the preview says

Nothing is written until you press Import. The screen that opens says how many results become how many findings, “19 results → 9 findings” for example, and how many of those findings were brought together from more than one scanner title or tool. Each finding in the list names the scanners its results came from and how many there were, so a grouping you disagree with is seen before it exists.

Whose wording each finding is in

• An issue your Library has is written in your Library’s words, for the fields your firm reuses (Settings, Findings).
• An issue your Library does not have is written in the finding library’s words: description, remediation, CWE, category and references. Untick Write findings your library does not have in the finding library’s wording to keep each scanner’s own text instead; the finding still takes the library’s name for the issue.
• The rating is the scanner’s, the highest CVSS score among the results with its vector, because it was measured on this client’s hosts. Where no scanner gave a score, the library’s rating is used.

The preview counts each: so many in your library’s wording, so many in the finding library’s, and so many in the scanner’s own.

What each finding keeps

• Every host any of the scanners reported it on.
• Each host’s scanner output as evidence, headed with the host and its port, exactly as the scanner wrote it.
• Above the evidence, a list headed Brought together from these scanner results, naming each scanner, the title it used and how many hosts it reported, so a reviewer can see what one finding stands for.

Importing again

An issue already in the phase is never added twice, whichever scanner reported it first and under whichever name. Any host it does not list yet is added to it, and nothing written in it changes. Importing the same files a second time adds nothing.

One finding per issue is also one fix per issue for the client’s engineers. For writing that fix so it gets done, see remediation a developer will action.