One place where the answer lives
Findings with the request, the response and the fix. A risk score you can decompose. A trend line across assessments that means something because the methodology does not change.
Reports are for people outside the loop. The dashboard is for the people in it.
Evidence on every validated finding · Score breakdown visible · Role-based access
Overview
Reports are snapshots. They are the right format for someone who was not part of the work (a board, an auditor, a customer's risk team) and the wrong one for the people doing it.
A security team does not want a document. They want the current state: what is open, what changed since yesterday, what the evidence for a specific finding actually is, and whether the thing that was fixed last week has stayed fixed. Those are live questions, and a PDF answers none of them.
The dashboard is where the assessment lives between reports. It holds the findings with their evidence, the score with its breakdown, the status of everything in flight, and the history of what has already been resolved, with the record of who resolved it and when.
The design intent is worth stating plainly: nothing in the dashboard is a summary of something held elsewhere. The finding you read here is the same object that appears in the report, in the Jira ticket, in the SARIF annotation and in the API response. There is one record, viewed several ways.
How It Works
- Step 01
Findings, with the evidence attached
The primary view is the findings themselves. Each carries what makes it actionable rather than merely reported.
A finding opens onto its title, severity and category, the affected endpoint, the impact and the remediation guidance; and, on anything validated, the exact request, the response proving the exploitation and a reproducible curl command, syntax-highlighted. That is the difference between a finding somebody has to reproduce before acting on it and one they can confirm in ninety seconds by running the command themselves.
- Step 02
Status, tracked and attributed
Every finding carries open, fixed, accepted or false_positive. Every change records who made it, when, and any notes attached.
This is the part that turns a findings list into a working record. A finding marked accepted three months ago carries the name of the person who accepted it and the reason, which is the difference between a governance decision and a gap.
- Step 03
Risk score, decomposed
The composite risk score runs 0 to 100, derived from critical and high findings, exposure level and asset criticality weighting. The breakdown is visible rather than presented as a single figure, so the number can be interrogated rather than accepted.
See Risk Prioritization - Step 04
Trend across assessments
Comparative analysis against previous scans, so the score is a tracked measurement rather than a snapshot. Because the assessment methodology is consistent between runs, the comparison is like-for-like.
- Step 05
Assessment progress
Scans can be watched while they run rather than waited on. Findings appear as they are validated.
What a finding carries
The fields on every validated finding, which is what makes it actionable rather than merely reported:
- Title, severity and category
- With subcategory for the specific vulnerability type
- Affected location
- Endpoint with method, path, parameter and full URL
- Description and impact
- What it is and what an attacker gains
- Proof of concept
- The exact request, the response proving exploitation, and a reproducible curl command, with syntax-highlighted code
- Remediation
- A summary, the vulnerable and secure code side by side, and references to OWASP, CWE and CVE material
- Scoring
- CVSS 3.1 score and full vector string, plus CWE identifier
- Compliance mapping
- The controls the finding touches
- Timestamps
- first_seen, created and last updated
Access and administration
Role-based access within the workspace, with reports scoped to the projects a user is assigned to. API key management for CLI and programmatic access: aiptx auth login, or the AIPTX_API_KEY environment variable.
Capabilities
Findings view with full finding detail
Title, severity, category, subcategory, description, impact, affected endpoint, proof of concept, remediation and references.
Syntax-highlighted evidence
Request, response and curl command.
Remediation inline
Summary plus vulnerable and secure code examples.
Scoring visible per finding
CVSS 3.1 score and vector, CWE identifier.
Compliance mapping shown against findings
PCI DSS, OWASP Top 10 and CIS associations carried on the finding itself, so regulatory scope reads at triage.
Status management
open, fixed, accepted, false_positive, with attribution, timestamps and notes.
Composite risk score
0 to 100 with its contributing breakdown.
Trend analysis across previous scans
Severity counts and the composite score compared against earlier assessments, so direction of travel is visible.
Scan progress visible during assessment
Phase-by-phase progress while the run is live, with findings appearing as they are validated rather than at the end.
Report generation and export
Four templates, five formats, with filtering by severity and category, custom branding, scheduled delivery and time-limited shareable links.
Role-based access control within the workspace
With project-scoped visibility.
API key management
For CLI and programmatic access.
REST API parity
Scans, findings and reports available programmatically for teams who would rather build their own view.
Benefits
- 01
The evidence is where the finding is.
No switching between a report, a ticket and a terminal to establish whether something is real.
- 02
Status is a record, not a recollection.
Who accepted what, when, and why, available when someone asks, which is usually at the least convenient moment.
- 03
The score can be argued with.
A visible breakdown invites specific disagreement, which is how a prioritisation improves. A single opaque number invites general distrust.
- 04
Progress is visible while it happens.
Findings appear as they are validated rather than arriving as a batch at the end.
- 05
One record, several views.
The dashboard, the report, the ticket and the API response are the same object, so nothing drifts and nothing is re-keyed.
- 06
Access matches responsibility.
Role-based access and project scoping mean a team sees its own findings without seeing everything.
- 07
Teams who prefer their own tools are not penalised.
Full REST API parity means the dashboard is an option rather than an obligation.
- 08
Decisions remain traceable.
Every change in status, priority, ownership and risk acceptance is recorded against the finding, creating a history that explains not just what was decided, but how it got there.
Monday morning, three people, one dashboard.
Illustrative example. Not a customer account.
- 01
The AppSec engineer opens the findings view. Two new criticals arrived from Friday's Standard assessment. She expands the first: the endpoint, the request that worked, the response returning another account's data, and the curl command. She confirms it in ninety seconds by running the command herself, then routes it to the owning team with the remediation example attached. The second she recognises as a duplicate of something already accepted: she checks the record, sees the acceptance from two months ago with the reasoning, and marks it accordingly rather than reopening a settled decision.
- 02
The engineering lead is looking at his team's scoped view. Four findings, all with fix examples in his stack. One is already in progress; the branch is open and the SARIF annotation is in the pull request. He schedules the other three into the sprint, because each one arrived with an estimate he can actually make.
- 03
The head of security looks at the score. 64, down from 71 at the previous assessment, with the breakdown showing the improvement came from closing two criticals rather than from anything having drifted in the weighting. She opens the trend view, confirms three consecutive assessments of improvement, and exports a filtered executive PDF for Thursday's leadership meeting.
None of them produced a document for the others. They were all reading the same records, at the depth their role needed.
What this illustrates.
The dashboard's value is not the visualisation. It is that one object serves three people with different questions, and none of the three had to reconstruct anything to answer theirs.
FAQ
Frequently Asked Questions
What can we see in the dashboard?
Findings in full detail — severity, category, affected endpoint, impact, proof of concept with request, response and curl command, remediation with code examples, CVSS scoring, CWE class and compliance mapping — alongside status, the composite risk score with its breakdown, trend across previous assessments and live scan progress.
Can we watch an assessment while it runs?
Yes, progress is visible during the scan and findings appear as they are validated rather than arriving together at the end.
Who can see what?
Access is role-based within your workspace, and reports are scoped to the projects a user is assigned to.
Can we manage finding status from the dashboard?
Yes, findings carry open, fixed, accepted and false_positive, with updated_by, timestamps and notes recorded on every change.
Do we have to use the dashboard?
No — scans, findings and reports are all available through the REST API and the CLI, so teams who would rather build their own view can.
Is our data isolated from other customers?
Access is role-based within your workspace and results are never shown to other customers.
How do we get API access?
Through the dashboard settings, then authenticate the CLI with aiptx auth login or set AIPTX_API_KEY in your environment.
Are reports available from both the dashboard and API?
From either — report generation and export run in the dashboard, through the REST API and from the CLI, with nothing exclusive to one surface.
The platform capabilities behind this feature
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
Four audiences, four reports, one assessment
Four report templates for four audiences, five export formats, and a trend line that means something because the methodology does not change.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
A finding in a dashboard is a finding waiting
Findings routed to where the fix happens: the pull request, the backlog, the channel. Plus a REST API and webhooks for everything else.
See it with your own findings in it
Run an assessment and watch it populate: findings with evidence, a score with its breakdown, and a record that persists.
No credit card required · Full REST API available