The console

The engine without a console is a curl endpoint

Ten to twenty hours per engagement do not disappear because a model can draft. They disappear when the analyst stops moving findings between a scanner, a spreadsheet and a document by hand. This is the surface where that work happens, described by the decisions it has to support.

Talk to us The engine underneath

Six screens

Described by the question, not the widget

Each screen exists to answer one question an analyst is holding when they open it. If a screen cannot answer its question without them opening a spreadsheet, it has not done its job.

Import

Did the file actually come in?

The screen most tools do not have, and the reason findings go missing. An upload shows parse progress and then four numbers that have to reconcile: rows in the file, findings parsed, rows rejected, duplicates collapsed.

Every rejected row listed with a reason a human can act on, not a count
Tool and version recorded on the import, because parsers drift between releases
A duplicate file recognised by checksum instead of quietly doubling an estate
A failed parse that says where it failed, rather than a report with nothing in it

Findings

What are we actually dealing with?

One table across the engagement rather than one per scan, filterable by severity, status, asset and source, with a detail drawer that carries the evidence and the history rather than a copy of the scanner’s text.

A finding’s full history: first seen, still open, reappeared, fixed — with the scan each event came from
Both sources visible where two scanners found the same weakness
Evidence attached inline — request, response, log line, screenshot, redacted where it carries secrets
Unscored findings shown as unscored, never sorted as though they were zero

Triage

Which of these is real, and who owns it?

The bulk work of an engagement. Marking false positives, accepting risk, assigning status, and disagreeing with a scanner’s severity where the environment justifies it — every override carrying the reasoning that made it defensible.

Bulk status changes across a filtered set, without a page reload between them
A severity override that will not save without a written justification
False-positive marking that survives into the next scan rather than being redone
Every change attributable to a person and a time

Report

Where did this paragraph come from?

Generation with the working shown. A job streams its progress — parsed, drafting, rendering — and the finished draft is readable next to the findings it was assembled from.

Click a paragraph to see the findings behind it; click a finding to see the scan row
A summary claim with nothing supporting it flagged before anyone reads it
Versions kept, so the draft a client saw last month is still the draft they saw
Exports recorded in the audit log with actor, address and timestamp

Review

Is this fit to send?

The gate between a draft and a deliverable. A report reaches final only when a lead signs it, and the software is deliberately unhelpful about routes around that.

An analyst cannot approve their own report
An unapproved export carries a visible “not reviewed” watermark
Sign-off recorded against a named person, with what they were shown
The watermark is the default state, not a setting somebody remembers to turn on

Posture

Is any of this getting better?

Scan-over-scan movement for the engagement: risk matrix, severity distribution, recurring findings and time to remediate — each figure computed from recorded events rather than estimated for a slide.

Every movement on the trend line traceable to a specific finding event
Recurring findings surfaced as a class, not as five separate rows across five reports
Time to remediate computed from real timestamps or not shown at all
A read-only client view scoped to a single engagement and provably nothing else

Console rules

Three rules this interface is being held to

The empty state tells the truth
Where the system has nothing, it says so. A screen that renders zero findings as a clean bill of health is the single most dangerous thing an interface in this domain can do.
Scan text is never trusted
Finding titles and descriptions are attacker-authored strings. They are escaped and rendered inert everywhere they appear, including in exports and in the parts of the UI nobody looks at.
Two hundred findings in one sitting
The performance target is a real engagement, not a demo file: a filterable table that stays responsive at ten thousand rows, and a triage flow that never makes the analyst wait for a page to come back.

What does your day in this actually look like?

Six screens designed from a reading of the work rather than from doing it. If the one you would live in is missing, or the one we put first is the one you never open, tell us.

Talk to us For consultancies

Get in touch

Talk to the people building it

No chatbot and no ticket queue. Tell us what your security reporting actually looks like — which tools you live in, how long a deliverable takes, what a client has sent back — and someone who works on the software will reply.

info@legosphere.com