Scanner Integrations is the layer where SITEY meets the security tools you already own. You store each scanner’s connection details once, then either launch scans directly from SITEY or upload the reports your scanners produce. Every finding that arrives, whichever tool produced it, lands in the same database table, with the same field names, the same severity scale and the same deduplication rules, so the rest of the platform never has to care which scanner found what.
The problem
Most security teams do not have a scanner problem. They have a scanner output problem. Nessus exports .nessus XML with an ordinal 0-4 severity attribute. OpenVAS exports GMP XML with threat levels and tag strings. Acunetix exports JSON whose HTTP responses are base64-encoded and gzipped. Burp exports XML with embedded request and response blocks, sometimes containing raw NUL bytes that break a naive XML parser. Qualys uses VULN elements, Nexpose uses something else again.
So somebody on the team becomes the spreadsheet person. They export from four consoles, paste rows into Excel, try to spot that “Apache Log4j RCE” from one tool and “Log4Shell (CVE-2021-44228)” from another are the same finding on the same host, hand-map severities onto a single scale because one tool says “4” and another says “High”, and then email the result to a system administrator. The work takes days, it is never complete, and the moment the next scan runs it is stale.
Severity gets silently mangled: treating a Nessus ordinal 4 as if it were a CVSS score of 4.0 turns a Critical into a Medium, and nobody notices until an auditor asks why the Critical counter was empty.
How it works
- Store the connection details once
The Integrations page holds a card per tool with exactly the fields that tool needs, URL plus API key and secret for Nessus, URL plus username and password for OpenVAS, URL plus API key for Burp and ZAP, a binary path for Nuclei and Nmap, URL plus API key for MobSF. Fourteen tools have a configuration card. Saved secrets are written to the integration config file and returned to the browser masked as ******; when you re-save a card, any field still showing the mask keeps its stored value instead of being overwritten with asterisks. Writing integration configuration and starting or stopping a scanner process are both gated behind the infrastructure-manager role, because whoever can change a scanner’s URL can redirect your scans and your credentials somewhere else.
- Launch a scan, or bring the report
Two paths lead into the same pipeline. SITEY drives some engines directly: it creates the target, picks a scan configuration and starts the task over GMP for OpenVAS; it tests connectivity, resolves a scan template or policy, creates a folder, creates and launches the scan for Nessus; it starts a Burp scan against a URL, waits for it to finish and saves the resulting JSON report on the server, which you then import; it runs an Acunetix full scan for a group of targets; it uploads a mobile binary to MobSF and pulls the JSON report back. For everything else you upload the report file, which is the path that covers the widest range of tools.
- Parse into one schema
Each scanner has a dedicated parser that knows that tool’s quirks. The Nessus parser reads both CVSS v2 and CVSS v3 base scores and vectors, prefers v3, collects see_also links and typed xrefs as references, and merges the synopsis into the description. The Acunetix parser base64-decodes and gunzips HTTP responses so you can read them. The Burp parser strips NUL bytes before parsing and carries the request/response pair through. The Nmap parser reads NSE script output, including vulners results, and extracts the CVE and CVSS it finds there. Whatever the source, the result is one row with the same fields: name, description, risk, CVE, CWE, CVSS score and vector, target IP, port, service, solution, endpoint, parameter, file path, request, response.
- Normalize severity honestly
Nessus severity is an ordinal 0-4; CVSS is a 0-10 score. SITEY reads both, maps each onto the platform scale, and when the two disagree it takes the higher one. Severity is never silently downgraded. Other importers run raw severity strings through a deterministic normalizer: a mapping table covers the vendor labels and numeric scores it recognizes, and when that would leave a finding at Info, the name and description are checked for risk keywords and for a CVE identifier before the level is settled.
- Deduplicate and count re-detections
Every incoming finding goes through one central upsert keyed on name, risk, target IP, port and scanner. If it is new, it is created. If it already exists, the original record’s detection_count is incremented, the timestamp is appended to its detection history, last_seen is updated, and the duplicate is linked back to the original rather than cluttering the queue. Each import also stamps every finding with a campaign name, the original filename, the import date and the user who performed it, and the raw report file is kept on disk for later download.
What you can do
Configure fourteen scanners from one page, with per-tool field requirements and masked secrets that survive re-saving.
Import reports from sixteen scanner families.
Accept more than one export format per tool where the vendor offers them, Burp as XML or JSON, Acunetix as JSON, XML or HTML, Nessus as .nessus or .xml, Fortify as .fpr or archive, MobSF from APK, IPA, XAPK, AAB or ZIP.
Start OpenVAS scans with a chosen profile (fast or deep), a full TCP port range, a selectable UDP scope (off, common ports, or full), and optional “Consider Alive” host handling for filtered targets.
Poll a running OpenVAS task for live status and percentage progress, fetch its report when it completes, and genuinely stop it through GMP rather than just marking it stopped in the database.
Run a Nessus connectivity test, list available scan policies and templates, and auto-import a completed Nessus scan by its ID.
Define recurring scan schedules per asset group, daily, weekly, monthly or a custom cron expression, with a tool list per schedule, a computed next-run time, and an active/paused toggle. Only the schedule’s owner or an admin can change, pause or delete one. At the scheduled time SITEY queues a scan job for each selected tool against each online agent in the group.
See which scanner binaries are installed and running on the host, with detected versions and active scan counts, on hosts where the SITEY tool agent is deployed. The Integrations page re-polls that status while it is open, alongside recent lines from the agent’s own log.
Review an import audit trail assembled from the imported findings themselves: which tool, which file, how many findings, uploaded by whom and when, with the stored raw report available for authenticated download while it is still on the server.
Unattended end-to-end execution of those queued jobs is not available yet, so a schedule currently drives the queue rather than the scanners themselves.
Who it is for
Stop reconciling four consoles by hand and work one deduplicated queue instead.
Get a single severity scale they can defend in a meeting, and a re-detection count that shows whether a finding keeps coming back.
See findings already attributed to a target IP, port and service instead of a PDF to interpret.
Can hand over a native tool export instead of rewriting their findings into someone else’s template.
Get the provenance an audit asks for: which tool, which file, which person, which date, with the original report still on disk.
Why it matters
The consolidation work is the expensive part of vulnerability management, and it is pure overhead.
No risk is reduced while someone merges spreadsheets.
Automating it moves that time into remediation, which is the only activity that actually closes findings. It also removes two failure modes that quietly cost real money: a Critical misclassified as a Medium because an ordinal severity was read as a CVSS score, and a finding tracked twice under two different names while a third goes unnoticed. And because every finding enters through one upsert with one schema, everything downstream, triage, scoring, assignment, patching, retest, works identically no matter which scanner found the problem. You keep the scanners you have already paid for and already trust; SITEY becomes the layer that makes their output usable.
Works with
- Scan Management: launch, schedule and monitor the scans that these integrations execute.
- Vulnerability Lifecycle: where imported findings live, get statuses and get closed.
- AI Triage, validates and prioritizes the normalized findings that arrive from every scanner.
- Manual Vulnerability Entry, for findings from a pentest or a review that no scanner produced.
Frequently asked questions
Which scanners does SITEY launch itself, and which are import-only?
SITEY drives OpenVAS and Nessus most completely: it creates targets and tasks, launches them, polls status and progress, and fetches reports. It can also start a Burp scan against a URL and save its report for import, run an Acunetix full scan against a group of targets, upload a binary to MobSF and retrieve its report, and run Nmap against your inventory. The remaining tools are report-driven: you run the scan in the vendor’s own console and upload the export. Both paths produce identical records.
The same host appears in two scanners’ reports. Do I get duplicate findings?
No. All imports pass through one deduplication step keyed on name, risk, target IP, port and scanner. A repeat finding does not create a second open item, instead the original’s detection count increases, the date is appended to its detection history and its last-seen timestamp moves forward, so you can see how persistent a finding is.
Do my scanner credentials or scan results leave my network?
No. SITEY runs on your own infrastructure. Integration credentials are stored in your installation’s configuration file and returned to the browser masked; scan reports are written to your server’s own import directory; findings go into your own database; and scanner traffic stays between your SITEY server and the scanners you point it at. Importing and normalizing scanner output sends nothing to an outside service. SITEY as a whole does reach the public internet in two other places: license activation, and, in the modules where you enable them, optional CVE enrichment from public vulnerability data sources and requests to whichever AI model provider you configure.
How does the import handle very large report files?
Findings are processed and upserted one at a time. An individual finding that fails to parse is logged and skipped instead of aborting the whole import, and a duplicate that collides with a database constraint is rolled back on its own without discarding the findings already imported in that batch. Be aware of one limit: the report file is read and parsed in full before that loop begins, so memory use grows with the size of the export rather than staying flat. For very large estates, size the SITEY host accordingly or split the export.
Scanner Integrations is where SITEY’s eight-phase pipeline begins: nothing can be triaged, scored, assigned, patched or retested until it has been collected and normalized. If you already own Nessus, OpenVAS, Burp or Acunetix, this module is what turns their output into a single queue your team can actually work. See pricing to deploy SITEY in your own environment.