Reporting

Aether AI turns validated findings into reports that two very different audiences can trust: a board that needs the state of risk in plain terms, and an engineer who needs the exact detail to fix a problem. Both are built from the same underlying findings, so the story a leader reads and the story an engineer works from never drift apart.

Why this matters

Security reporting usually breaks in one of two places. The board-level summary is written separately from the technical detail, so the numbers do not reconcile. Or the report is a snapshot from a point in time that quietly goes stale, describing exposure that was already fixed weeks ago. Both erode trust in the report, and trust is the whole point of reporting to a board.

Aether AI avoids that split. Reports are generated from the validated findings that already sit in the Risk Inbox, across ASM and the autonomous AI pentest. There is one set of facts. The board-ready view and the technical view are two projections of it, not two documents maintained by hand.

Board-ready and technical, from one source

The same validated findings drive both report types.

A board-ready report speaks to risk owners and security leadership. It leads with outcome: where the organisation stands, what changed, what an adversary could realistically do. It leans on the 0 to 100 asset risk score, which is explainable and source-agnostic across ASM and pentest, so leadership can see risk rise and fall without needing to read a single finding.

A technical report speaks to application security and engineering. It carries the detail that makes a finding actionable: the affected asset, the evidence, the severity, and the fix. Because it is drawn from the same findings, every item a leader sees at the top has a corresponding technical record an engineer can act on.

The Dvuln reporting standard

Aether AI reports follow the Dvuln reporting standard. That standard governs how findings are described, how severity is communicated, and how evidence and remediation are presented, so a report from Aether AI reads consistently and holds up to scrutiny. It is the same discipline applied whether a finding came from ASM enrichment, the Conventional Attack Surface layer, a Threat Radar plugin, or the frontier pentest.

Re-validation keeps reports honest

A report is only as trustworthy as the day it was written unless the findings behind it stay current. Aether AI keeps them current through continuous re-validation.

Findings move through a resolve, retest, and regression lifecycle. When a fix is applied, re-validation confirms it and the finding resolves. If the same weakness reappears later, re-validation reopens it. The Conventional Attack Surface layer auto-resolves a finding once a re-check no longer observes it, and the risk score drops back toward nothing as findings clear. Because reports are built from that live state, a report reflects what is true now, not a snapshot that has quietly gone out of date.

That is what lets a board-ready report and a technical report stay in agreement over time. The state of risk they describe is the state Aether AI is still actively validating.

What you see

Reports are generated from the findings you already work with day to day. The severity, source, and evidence you see in the Risk Inbox carry through, with source labels such as Aether ASM, Plugin (Infostealer), and Plugin (Conventional Attack Surface) preserved so the origin of each finding stays clear in the technical view. Leadership sees the outcome and the trend; engineers see the same facts at full depth.

Related