Scan Management is the console where you launch, schedule, watch and close out vulnerability scans in SITEY. It turns scanning from a set of separate tool consoles into one queue: pick a group of machines, pick a profile, start it, and for OpenVAS group scans the platform handles target checking, progress tracking, report collection and deduplicated import into your vulnerability database. Output from the other scanners arrives through a single import path that applies the same deduplication.
The problem
Most teams do not have one scanner. They have Nessus for the server estate, OpenVAS for the segments Nessus is not licensed for, Acunetix or Burp for the web applications, and a pile of one-off reports from consultants. Each of those lives in its own console, with its own schedule, its own export format and its own idea of what “high” means.
So somebody becomes the human integration layer, repeating the same steps every week.
Without SITEY
- Log into four consoles on Monday morning to see what finished over the weekend.
- Export XML, open a ticket system, and paste findings in by hand.
- Rediscover, every month, that the same finding on the same host was already imported three times under three slightly different names.
- A scan comes back with a dozen hosts missing, and nobody notices.
With SITEY
- One console, one queue: pick a group, pick a profile, start it.
- OpenVAS reports collect and import automatically, already deduplicated.
- A repeat finding increments a detection count and history instead of creating a new row.
- Preflight separates a clean host from an unreached one, and records both on the scan.
A scan that silently skipped a firewalled machine looks exactly like a scan that found nothing on it.
The result is a vulnerability picture that is always a week old and quietly incomplete.
How it works
- Choose targets from a group, not a text box
Scans are launched against an agent group rather than a hand-typed IP list. The console resolves the group to its member agents and their addresses, so a scan always covers the membership of that group as it stands at the moment the scan starts.
- Preflight the targets before the scanner touches them
For OpenVAS group scans, SITEY probes every target first with a scanner-independent check: ping, TCP connect and traceroute. Hosts with an open access problem are separated out, and the scan proceeds against the reachable ones. If every target fails the check, the scan does not start at all and you are told why instead of receiving an empty report hours later. The excluded list, with its diagnosis, is stored on the scan record and shown on the scan detail page.
- Pick a depth profile with its cost shown up front
For OpenVAS, the start screen lets you choose between a fast profile and a deep-safe profile, and for the deep profile, how much UDP surface to cover. Each choice displays its estimated relative slowdown before you commit, so nobody starts a multi-day scan by accident.
Profile OpenVAS configuration Port range Estimated relative cost Fast Full and fast TCP 1-65535, UDP 1-65535 Baseline Deep, UDP off Full and very deep TCP 1-65535 only ~3x slower Deep, common UDP Full and very deep TCP full + curated UDP ports ~15x slower Deep, full UDP Full and very deep TCP 1-65535, UDP 1-65535 ~120x slower The deep profile also enables “consider alive” host handling, so machines that do not answer discovery probes are still scanned instead of being skipped.
- Track it while it runs, stop it if you need to
Scans tracked by the platform carry a record with their scanner, status, start and end time, progress percentage and, where the upstream scanner returns one, an external task ID linking back to it. The console lists active scans alongside completed ones and refreshes that list every thirty seconds; the scan detail page updates when you refresh it. The progress percentage is driven by the OpenVAS polling worker, so it advances continuously for OpenVAS scans and reflects status changes rather than a live percentage for the others. A running OpenVAS scan can be stopped from the interface, which issues a real stop to the scanner and marks the record accordingly. A one-minute cooldown per tool prevents double-clicking a scan into existence twice, and the platform additionally refuses to create a second scan record for the same upstream task within a five-minute window.
- Collect, parse and deduplicate automatically
When an OpenVAS scan finishes, a background worker polls the task every twenty seconds until completion, downloads the report XML, writes it to disk so you can still download the original, parses it, and imports the findings one at a time. Each finding is written inside its own savepoint, so a single duplicate collision cannot roll back the rest of the batch. Findings that already exist are recorded as repeat detections against the original, incrementing its detection count and detection history rather than creating a second row.
Preflight and a real stop control are OpenVAS-only: scans started with the other scanners skip the reachability check, and stopping one of them marks the record in SITEY without cancelling the run on the scanner itself.
The relative-cost figures in the depth-profile table are the planning estimates the start screen shows before you commit, not measured benchmarks; real runtime depends on your network and host count.
What you can do
Launch OpenVAS and Nessus group scans and Acunetix scans against a group of hosts, start a Burp scan against a target URL, and upload mobile application packages for MobSF analysis. OpenVAS is the most deeply integrated path: preflight, depth profiles, background collection and automatic import all sit behind it.
Import report files from sixteen scanner formats, including Nessus, OpenVAS, Burp, Nmap, Nexpose, Fortify, Nuclei, Qualys, Tenable, Acunetix, Arachni, HCL AppScan, Netsparker, OWASP ZAP and Intruder, plus a manual CSV path with a downloadable template. Fifteen of them sit on the import screen; MobSF is handled on the scan tools page as a mobile application upload.
Define recurring scan schedules daily, weekly, monthly, or on a custom five-field cron expression, with a target group, a tool list and an hour and minute; toggle a schedule off without deleting it, and see its last run and next run. At the scheduled time SITEY queues a scan entry for each online agent in the group, offline machines are skipped, and the scanner run itself is started from the scan console.
See how many scans are active, a breakdown by status, total scans and how many completed today.
Review a six-month history of scan volume, split into completed, failed and still-running.
Open any scan and see its duration, group, agent, progress, findings detected versus findings imported, the raw result payload, and, where a report file was stored for that scan, a download link for the original.
Browse a searchable, filterable, paginated upload history showing which tool, which file, which user and which date each import came from, and re-download the original.
Run a targeted retest of a single finding from Nessus, OpenVAS, Acunetix or Burp, which creates its own scan record linked back to that finding and flips it to open or resolved based on the result.
Start an AI conversation scoped to a completed scan to summarise its findings and propose next steps, using the AI provider configured in your installation.
Who it is for
Get one queue instead of four consoles, and a scan detail page that answers “did this actually cover everything” rather than just “did it finish”.
Get depth profiles with their cost stated in advance, a cooldown that prevents accidental duplicate load on production segments, and a stop control that issues a real stop to OpenVAS.
Get monthly scan volume and success trends without asking anyone to assemble them.
Get a durable record of who imported which report file on which date, retained alongside the original artifact.
Why it matters
Three things change when scanning is centralised. First, the manual export-and-paste cycle shrinks: a completed OpenVAS group scan lands in the vulnerability database deduplicated, with CVE identifiers, normalised severity and vendor references carried over, and CVSS vectors preserved where the source report supplies them, without anyone touching a file. Second, coverage stops being a guess for the scans that run the preflight check. It separates “this host is clean” from “we never reached this host”, and both states are recorded on the scan and linked to a diagnosis page, which is the difference between an honest report and a reassuring one. Third, recurring scanning stops living in one person’s calendar: a schedule keeps its frequency, target group, last run and next run in one place, and is protected so only its creator or an administrator can change its target group, disable it or delete it.
Works with
- Scanner Integrations holds the credentials and endpoints for the upstream scanners that Scan Management launches and polls.
- Network Reachability supplies the preflight and post-scan access diagnosis that tells you which targets were genuinely covered.
- Group Management defines the agent and domain groups that scans and schedules are pointed at.
- Vulnerability Lifecycle receives the deduplicated findings each scan produces and carries them through triage, assignment and closure.
Frequently asked questions
Can I launch every supported scanner from inside SITEY?
No, and it is worth being precise. OpenVAS, Nessus and Acunetix can be started directly from the console against a group, Burp is started against a target URL, and MobSF analysis is started by uploading the application package. The remaining scanners are supported through report import: you run them where they live and bring the output in by upload. The import path is the same for all of them, so the findings end up in the same place with the same deduplication.
What happens if a scan runs for days?
Long scans are expected, particularly on the deep profile with full UDP coverage. OpenVAS collection runs in the background with a configurable maximum wait that defaults to ten days, polling the scanner every twenty seconds rather than holding a connection open. If the ceiling is reached, the scan is marked as timed out with its last known progress preserved rather than being silently abandoned. Acunetix and Burp runs started from the console are executed in the foreground of the request instead, so they suit shorter, targeted scans.
Will re-scanning the same hosts flood my vulnerability list with duplicates?
No. In the import and OpenVAS collection paths, findings are matched on name, risk, target address, port and scanner. A finding that already exists is recorded as a repeat detection against the original record, which increments its detection count and updates its last-seen timestamp. That also means a finding’s persistence over time is visible, rather than every scan producing a fresh copy.
Does scan data leave our network?
SITEY is installed in your own infrastructure. Scan targets, reports, findings and the original uploaded files stay on your servers. The platform itself reaches out for license activation. If you use the AI features, those requests go to the AI provider configured in your installation, which can be an endpoint you host yourself.
Scanning is the input to everything else SITEY does, and its quality decides the quality of the triage, the assignment and the patching that follow. If the manual export-import cycle is where your week goes, or if you cannot say with confidence which hosts your last scan actually reached, this is the module that fixes it. See pricing to deploy SITEY in your own environment.