Vulnerability Scanning, End to End

Pental never scans anything itself. It brokers: it takes results your scanner produced, deduplicates them, files them against a customer, and turns them into a document. Everything below is about getting results in and what happens to them once they are there.

The three ways results arrive

You upload an export. Open Vulnerability Scans, press Import a scan, choose the customer, and pick the file. Sixteen formats are read: Nessus, Greenbone, Burp, Nmap, ZAP in both XML and JSON, Nuclei, SARIF, Trivy, Acunetix, Qualys, Nikto, testssl.sh, Semgrep, Wapiti, CSV and generic JSON. Nothing is written until the screen has shown you what it read.

Pental pulls them. Connect a scanner in Settings, Vulnerability Scanning, and Pental calls its API on demand or on a schedule.

Something posts them. A CI job, a script or a scanner Pental has no adapter for can POST results to the ingestion webhook. That is documented separately in Posting Scan Results to Pental.

A scan does not need an engagement

Importing asks which customer, then offers to attach the scan to an engagement. Attaching is optional: a scan can stand on its own, and Pental files it under an engagement of its own making so the results have somewhere to live. Attach it when the scanning is part of a piece of work you are already doing.

Connecting a scanner: two ways, and the choice matters

Pental calls your scanner. Nothing to install, and it works immediately. Your scanner has to be reachable from the internet and Pental holds the credential. Fine for a cloud scanner like Tenable Vulnerability Management.

Your network calls Pental. You run a small collector inside your own network. Nothing inbound is opened and your scanner credential never leaves your building. This is the right choice for a Nessus on an internal address, and for any firm that will not allow a shared cloud egress into its scanner.

To set up a collector: add the scanner in Settings, Vulnerability Scanning, Connected scanners, choose "Your network calls Pental", then press Get the collector token and command. The token is stored the moment it is issued and shown to you once; only a hash is kept, so if you lose it you issue another rather than recovering it. Download pental-collector.mjs, which already knows your portal address and tenant, and run it where your scanner is. It needs Node and nothing else.

# macOS, Linux or WSL
PENTAL_COLLECTOR_TOKEN=<your token> node pental-collector.mjs

# Windows PowerShell
$env:PENTAL_COLLECTOR_TOKEN="<your token>"; node pental-collector.mjs

The collector polls for work, runs the scan through your scanner, and posts results back. It checks in even when it has nothing to do, so the portal can tell "not running" from "running and correctly finding nothing".

Letting a customer run their own scans

Three gates have to be open, in this order, and the screen tells the customer which one is closed rather than simply refusing. The module has to be on for your firm. Self-service has to be on for that customer. And the asset has to be approved, with an authorisation that is in date at both ends: a start date in the future is as unapproved as an expiry in the past.

That third gate is the commercial one. Without it, a customer can point traffic at anything they like under your name. Approve assets on the customer's own page, with the dates and a reference to whatever letter of authority you hold.

You decide who may ask: your testers, the customer, or both. You can cap how many scans a customer runs a month and how long they wait between them; neither applies to your own staff, because those limits exist to stop a customer spending your money rather than to stop work happening.

You also decide where results land. Under "holding", a finished scan waits for one of your testers to read it before the customer sees anything, and the completion email goes to your firm rather than to them. Sending "your scan found 14 criticals" to a customer before a human has looked is the situation that setting exists to prevent.

What happens to the results

Results are merged as they arrive. Two hosts with the same issue become one finding with both hosts listed and a table showing what was seen on each, rather than two findings that say the same thing. Matching is on the title only, and version numbers are kept: "TLS 1.0 Protocol Detection" and "TLS 1.1 Deprecated Protocol" are different vulnerabilities and are never folded together.

If a finding matches an entry in your library, your own wording wins. Otherwise the longest description survives, because scanners truncate differently on different hosts. The worst severity and the highest CVSS survive a merge: nothing quietly lowers what a customer is told.

Scan results stay in the Vulnerability Scanning section on an engagement. They do not join your findings tables and they do not appear in a pentest report, because a report is written work and a scan result is not. When one is worth writing up, "Move into findings" turns it into an ordinary finding that a later import will not overwrite.

The document

A finished scan produces a vulnerability report: a severity chart, a table of findings, then the findings themselves. No executive summary, no scope, no methodology, no appendices, because a scan has none of those to write. It is styled from the same template as your pentest report, so a margin or a font changed in one reaches both.

Results also download as a spreadsheet, a CSV or JSON from the scan itself, for a customer's team who will work through them in their own tools rather than read a PDF.

Charging for it

You can absorb the cost, raise an invoice automatically, or take payment through Stripe. Invoicing needs nothing connected: a draft invoice is created against that customer when the scan finishes, numbered and dated like any other, and you send it the way you send the rest. Stripe is for taking a card, and needs its secret key set, not just the publishable one.

When something is wrong

A collector that says "Unknown collector" is not being recognised by the database: either the token is not the one stored, or that scanner is not set to the collector style. The message says which.

A scan that sits queued is usually waiting for a scanning window you set, or for a collector that is not running. The scan list says which, rather than showing a spinner.

A scan that finished with nothing in it is a real outcome, not a failure, and Pental says so rather than producing an empty report.