SITEY turns the findings already sitting in your database into a document someone outside the security team can actually act on: a PDF for a management review, an Excel sheet for the people doing the patching, a Word file you can edit before it goes to a client or an auditor. Every report is generated from live data at the moment you click download, and the credentials buried in attack evidence are masked before the file is written.
The problem
Reporting is where vulnerability programs quietly lose a week every month.
Without SITEY
- Export a scanner’s raw output and paste it into a spreadsheet
- Sort by severity by hand and re-type the remediation advice
- Look up who owns each host and chase down which findings were actually closed since last time
- Rebuild the same summary slide from scratch
With SITEY
- Generate PDF, Excel or Word from live data in a single dialog
- Task status, assignee and priority are attached to every finding automatically
- The same dashboard charts stay current between reports
By the time the document is ready, the data in it is already stale, and nobody can tell you which of the 400 rows still matter.
There is a second problem that is less obvious and considerably worse. Scanner evidence contains live secrets. A web finding carries the full HTTP request and response that proved the bug, and that request usually includes the Cookie header, the Authorization bearer token, and the session identifier that were valid at the moment of the test. Copy that evidence into a report, email the report to a vendor, a consultant or an auditor, and you have handed over a working session to your own application. Most teams discover this only after the fact, if at all.
How it works
- Choose the scope
You pick a time window, the last 1, 3, 6 or 12 months, and check which work states to include, so an “outstanding work” report and a “what we closed” report come out of the same screen. If you only care about a specific set of findings, select them in the vulnerability list and generate the report from that selection instead; the time window is ignored and only the chosen findings are written.
- Live task state is attached to every finding
Before anything is rendered, each vulnerability is matched against its task record and carries that task’s status, assignee list, priority, creation date and completion date into the report. Findings that have never been assigned a task are treated as not started rather than silently dropped, so nothing disappears between the dashboard and the document.
- Credentials in the evidence are masked
Raw HTTP request and response bodies pass through a redaction step before they reach the PDF, Excel or Word writer. The values of Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-Api-Key, X-Auth-Token, X-Access-Token, CSRF and session headers are replaced with a redaction marker, as are inline parameters such as session_id, access_token, api_key, token, password and secret. The header and parameter names are deliberately kept, because the presence of the header is usually the point of the evidence. The result is a report you can forward without shipping a live session along with it.
- The file is rendered in the format you asked for
PDF opens with a cover page carrying the report date, the reporting period, the total finding count and the risk breakdown, then devotes a page to each finding, ordered Critical first and Low last. Excel produces a 21-column sheet with the severity cell colour-coded by risk, and with column widths and text wrapping set so the long fields stay readable. Word produces an editable document with a heading and a detail table per finding, so you can cut, annotate and rewrite before sending it on. Scanner text that arrives as HTML is converted to clean paragraphs first, so a malformed scanner description does not break the layout.
- Charts keep the same data visible between reports
The dashboard draws the same underlying data continuously: monthly findings, a risk donut, a trend area you can switch between findings, tasks and scans, a completed-work trend, a task status donut, a new-versus-resolved burndown, and a breakdown of findings by target type (web application, internal network, external system). Alongside them sit the derived tables: most frequent finding names, top sources, an asset risk heatmap of the hosts carrying the most findings, and a per-user resolution breakdown.
What you can do
Generate a report in PDF, Excel (.xlsx) or Word (.docx) from a single dialog.
Report on the last 1, 3, 6 or 12 months, or on a hand-picked set of findings you selected in the list.
Produce an open-items report and a closed-items report from the same data.
Include per-finding CVE, CWE, CVSS score and CVSS vector, target IP, port, service, detecting scanner and detection timestamp.
Include the full description, remediation advice, attack details, affected endpoint, parameter and file path.
Include the raw HTTP request and response as proof, with credential values automatically masked.
See total findings, critical and high count, and the risk breakdown for the selected period.
Pull the report statistics through an API endpoint if you want them in a system of your own.
Export the vulnerability list to CSV or JSON, and the task list to CSV, straight from the browser.
Watch the risk donut, monthly trend, burndown and asset heatmap update as findings come in.
Who it is for
Need to hand a system owner a document that contains the evidence, not just a ticket number.
Want the Excel sheet so they can filter to their own hosts and work down the list.
Have to show a trend rather than a snapshot: what came in, what went out, and whether the gap is closing.
Need dated, period-bounded evidence that findings were identified and tracked.
Produce client-facing documents and take the Word version into their own template, adding their own branding by hand, before delivery.
Why it matters
The direct saving is the afternoon nobody has to spend assembling a spreadsheet by hand each month. The larger saving is the argument that does not happen: when the report carries the CVSS vector, the affected endpoint, the remediation advice and the HTTP exchange that proved the issue, the system owner has no reason to ask for more information before starting work. Reports built from selected findings mean each team gets a document about their own systems rather than a 400-row file they will not open.
The redaction step is a risk control, not a formatting nicety.
Vulnerability reports are the single document most likely to be forwarded outside the security team, and raw scanner evidence is the single place your live session tokens are most likely to be sitting. Masking those values before the file exists removes an exposure route that is easy to create and very hard to notice afterwards.
Because SITEY runs inside your own infrastructure, the findings, the evidence and the generated files never leave your network. Nothing is uploaded to a vendor cloud for rendering.
Works with
- Vulnerability Lifecycle: the statuses your reports filter on are the states findings move through here
- Task Management: assignment, priority and completion data is read from tasks and written into every report
- Command Center: the charts and metrics described above live on the main dashboard
- Compliance Mapping: period-bounded reports give you dated evidence you can attach to a compliance review, though the report layout itself is not framework-specific
Frequently asked questions
Which file formats can I produce?
Three: PDF, Excel (.xlsx) and Word (.docx). PDF is laid out for reading and forwarding, Excel for sorting and filtering the list in your own spreadsheet tool, Word for editing before you send the document on to someone else.
Does the report include the raw HTTP request and response?
Yes, when the finding has them. Credential values are masked first, covering authorization headers, cookies, API keys, CSRF and session tokens, and inline password or token parameters, while the header and parameter names are left intact so the evidence still reads correctly.
Can I report on just a handful of findings?
Yes. Select the findings you want in the vulnerability list and generate the report from that selection. Only those findings are included, regardless of the time window.
Does our vulnerability data leave our network to produce a report?
No. SITEY is installed on your own infrastructure and the report is rendered there, so the reporting pipeline itself makes no outbound call. Elsewhere in the product there are two other cases: the licence is activated against our licence server, and optional features such as the AI assistant and CVE enrichment reach external services only if you configure and enable them.
If your monthly reporting cycle currently runs on copy-paste and a shared spreadsheet, this is the part of SITEY you will feel first. See pricing and deploy it in your own environment.