How do I wire JavaScript and hostnames?

Retrieve-and-unpack JavaScript emits `code`. This port is `javascript-code`. Hostname enumerators emit `hostnames` or `subdomains`. This port is `hostname`. Those two name mismatches are the usual empty-section miss.

Can it emit a PDF or a branded pentest report?

No. You get an HTML zip. For a client-branded deliverable, use a report builder outside the Library.

Why do screenshots and WHOIS exist on the face?

The face accepts them so a workflow can wire a non-Library source. They are not Library modules and they do not get a public sibling page.

Why is it called a scan report if it does not scan?

The name matches the module slug in the platform, not the job. This module composes files Library scanners and fingerprinters already wrote into one HTML zip. It does not probe, does not match CVEs, and does not score severity. If you need a scanner, nest the upstream scan and fuzz modules first; this sink only indexes what they produced.

2026-08-13

Utilities

Generate Scan Report

Wire findings, ports, DNS, WHOIS, screenshots, and tech fingerprints into one HTML zip. Composition sink for ASM and vuln pipelines, not a scanner.

What Generate Scan Report does

A scan report is only as complete as the ports you wire together. This module is the composition sink that turns scattered module outputs into one HTML archive you can hand off: findings, ports, DNS, WHOIS, screenshots, and tech fingerprints all land in a single zip with an index, a screenshot gallery, a sitemap, and a JavaScript directory. It does not scan, probe, or fingerprint; it indexes what the upstream Library modules already wrote, so a workflow ends on a searchable deliverable instead of a pile of files.

You wire typed outputs from modules you already ran. This subgraph composes them into one html-zip: ./index.html, a ./screenshots.html gallery, a ./sitemap, and a ./javascript directory. It does not scan, probe, or fingerprint. Empty ports stay empty. A report with only DNS is a DNS report.

Where it fits in the pipeline

Illustrative excerpt. Each node is a Trickest module.

Upstream

Any scan or fuzz tail that emits findings. Probe, open-ports, network fingerprint, web fingerprint, DNS records, and path discovery fill the matching ports. Wire code into javascript-code. Wire enumerator hostnames or subdomains into hostname.

Downstream

None in the Library. The zip is the deliverable.

Parallel

None. This is a sink across both tails, not a member of either.

hosts -> open-ports -> network FP -> (misconfig | weak-creds) -> this
hosts -> probe-web -> web FP -> tech-specific -> this

When to use this

Nest this as the last node, after the scans and fingerprints you care about have written their files. Findings from either tail can land here. Skip it when you still need a scanner, not an index.

Data

The tables this module produces. Sample rows are illustrative.

report-summary3 columns · 3 sample rows

Summary of findings aggregated into the HTML zip report.

	finding_countint	severitytext	categorytext
1	3	critical	exposed-admin-panels
2	7	high	sensitive-files
3	12	medium	misconfigurations

How it differs from similar modules

Nessus or Qualys report

Why this is not it

Those products scan, then render their own findings. This module does not probe. It indexes files Library modules already wrote.

Client PDF deliverable

Why this is not it

Output is an HTML zip. No branding, no writeup.

questions