Skip to content
LegosphereCyber

Findings · Evidence · Reports

A findings system of record for
penetration testing

Legosphere Cyber is the system of record for security findings, and the report engine that reads it. Scans in, evidence kept, severity computed rather than guessed, and every line of the deliverable traceable to the scan row behind it.

Talk to usHow the engine works
  • Nothing is dropped silently
  • No score is ever invented
  • No unresolved CVE reaches a document
  • A lead signs before anything is final

Three surfaces

An engine, a console, and the frameworks it reads against

One system of record underneath all three: the engine turns scanner output into findings, the console is where an analyst works them, and the compliance surface reads the same findings against a control catalogue.

The engine

The findings engine

Scanner output in, a defensible deliverable out. Parsing that accounts for every row, severity computed from a vector rather than inferred from a word, a verification gate that keeps an unresolvable CVE out of a document, and provenance from a paragraph back to the scan line behind it.

  • Five scanner formats, with parsed, rejected and duplicate counts that reconcile to the file
  • CVSS computed from the vector — and “not scored” where the tool scored nothing
  • Every CVE resolved against the national vulnerability database before anything renders
  • Findings reconciled across scans: new, persisting, reappeared, fixed
  • DOCX, PDF, JSON and an XLSX finding register your client can import

Engineering · platform teams · anyone integrating over an API

The findings engine
The workspace

The analyst console

Where the ten to twenty hours per engagement are saved. Upload a scan and watch it parse, read the rows it rejected and why, triage findings in bulk, override a severity with a written justification, then review, sign off and export.

  • Upload and parse progress, with a rejected-rows view rather than a silent success
  • A filterable findings table with a detail drawer and evidence attachment
  • Bulk triage: status, false positives, severity overrides with justification
  • A review gate — an analyst cannot approve their own report
  • Risk matrix, severity distribution and scan-over-scan trend

Analysts · engagement leads · reviewers

The analyst console
The frameworks

Compliance and policy

The same findings read against a control catalogue. ISO 27001, SOC 2, PCI DSS and the DPDP Act, mapped from findings to controls, with a verdict per control and an explicit answer where the engine cannot judge from scan data alone.

  • Control-by-control gap analysis, each gap citing the finding that drives it
  • Verdicts of compliant, gap, partial, not applicable — or manual
  • “Manual” never renders as a pass, and the report states its own scope limits
  • Security policy generation against the same catalogue
  • Every clause traceable to the control it implements

Compliance practitioners · auditors · security leads

Compliance and policy

Why it is built this way

The expensive failures in this work are the quiet ones

A security report is read almost entirely by people who cannot check it. The client will not re-run the scan, the board cannot read a CVSS vector, and the auditor is reading your document rather than your evidence. Every one of them is trusting that the numbers came from somewhere.

That is what makes the dangerous failures silent ones. A finding the parser dropped is a vulnerability nobody hears about. A severity back-filled from a word looks exactly like a severity computed from a vector. A CVE that does not exist reads exactly like one that does — until a client’s engineer searches for it.

None of those announce themselves. They pass review, they go out, and they surface months later in the one conversation where being wrong is most expensive. So the engineering is aimed at them specifically: account for every row, compute a score or refuse to show one, resolve every reference before rendering, and store the link between a claim and the scan line under it.

Which is why most of what follows is written as a rule about what the software will not do. In this domain, the refusals are the product.

How it works

What happens to a scan file

Five stages on the way to a signed deliverable, each with a rule attached. The rules are the interesting part — most exist because of a way this kind of system fails quietly.

  1. 01

    Ingest and account

    Parsed plus rejected plus duplicate equals the rows in the file, always. An unrecognised format is an error, never an empty finding list that renders as a clean report.

  2. 02

    Score, or say it was not scored

    Severity is computed from the CVSS vector. Where the tool scored nothing, the finding is marked unscored — an absent score never becomes a zero.

  3. 03

    Verify every reference

    A CVE that does not resolve stops the job instead of reaching a client. A published score that disagrees with the draft surfaces as a discrepancy rather than being quietly reconciled.

  4. 04

    Reconcile against history

    The same weakness from two scanners is one finding with two sources, classified against the last scan as new, persisting, reappeared or fixed.

  5. 05

    Assemble, review, sign

    Sections drafted against the findings behind them, a claim with no finding blocked, and a draft watermark that only a lead’s signature removes.

The engine, stage by stage

What it has to satisfy

Twelve rules that constrain the software

Each one is a constraint rather than a capability, and each is written so a customer can hold the software to it. Most of them describe something it refuses to do.

  • Nothing is dropped silently

    Parsed, rejected and duplicate counts reconcile to the input every time, and the rejected rows are visible with reasons. A finding the parser lost is a vulnerability the client never hears about.

  • Nothing renders on an unresolved CVE

    A reference that does not resolve stops the job and names itself. There is no bypass flag, because a bypass flag is the setting that will be switched on the week a deadline slips.

  • An absent score is not a zero

    Where nothing scored a finding, the report says “not scored by tool” and shows no number. Omitting a severity is recoverable; inventing one is not.

Read all twelve

Questions

What people ask first

The ones that decide whether this software is safe to put between a scanner and a client deliverable.

Nessus, Burp Suite, OWASP ZAP, Qualys and generic SIEM exports, detected explicitly and overridable by the caller rather than guessed from the first few bytes. Each format is validated against an expected shape per tool version, so a scanner release that changes its output is a loud failure rather than a quiet one.

Point it at the reporting you already do

The useful conversation starts from your work rather than from a deck: the scanner output nobody can parse cleanly, the report that takes a week, the client complaint you keep answering. Tell us that and we will tell you plainly whether this fits.

Talk to usThe platform

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

Please keep live incident details, credentials and customer data out of this box — it is an ordinary enquiry form, not a secure channel.