Every finding keeps its
evidence chain.
Nyxeara attaches proof to every finding at collection time: the tool that produced it, the target, the persisted evidence, and a SHA-256 integrity digest over the finding plus its evidence linkage. Verification is a lifecycle state you control. This page explains the seven layers.
The scanner records what it found, not what it claims.
When a tool — nuclei, nmap, gobuster, sqlmap, or a custom adapter — runs against a target, the platform captures the execution result and stores the raw output as a saved_result. That result is linked to a finding through a finding_evidence row, which stores the exact relationship: which result, which tool, which execution, and when the link was recorded.
The platform does not retroactively claim “detected” from a confidence score alone. A finding is created by an operator or an automated trigger, and the evidence link is written at creation time. The detection event is the link, not the score.
The exact probe is preserved, but not every transcript.
The platform stores the tool execution parameters and the raw output produced by the tool. For tools like nuclei, the stored evidence includes the template id, the matched matcher, and the host/port that triggered it. For nmap, the output is the full scan result.
What the platform does not persist on this deployment: full HTTP request/response pairs (headers + body) for every probe, replay counts, or baseline diffs. Where a request path and headers were recorded by the tool, they appear in the evidence body; where they were not, the platform says so explicitly.
Per-probe replay not collected; scan-level diff available.
Nyxeara's Flask backend provides a scan-level baseline diff endpoint (POST /api/baseline/diff) that compares two finding sets (current vs. baseline) and reports new, resolved, and unchanged findings. This is a metadata-level comparison — not a per-probe byte-level replay.
Per-probe replay (re-executing individual probe requests against a clean baseline and comparing HTTP responses byte-by-byte) is available in the scanner's confirmation and differential injection engines but is not wired into the deployed product pipeline. Findings in the deployed platform donot carry a per-probe replay count, baseline response body, or “verified after replay” badge. The proof bundle honestly omits these fields instead of fabricating them.
A lifecycle state, not a scanner claim.
Verification in Nyxeara is derived from two sources: (1) the persisted evidence count and lifecycle status (OBSERVED, TRIAGED, CONFIRMED, RESOLVED, DISMISSED), and (2) an explicit investigator action. The platform never stamps “verified” because a detection rule fired.
Each finding carries a confidence label and the basis for it:detector-recorded (the tool produced a match), investigator-recorded (a human set it), or defaulted (application-level constant). The proof bundle surfaces both the verification verdict and the reasons behind it.
The finding plus its linkage, hashed together.
Every proof bundle includes a SHA-256 integrity digest computed server-side over the canonicalized finding metadata and its evidence linkage rows. The digest covers:
- finding id, title, status, severity, confidence
- evidence count and each evidence row id, type, tool name, execution id, timestamp
The digest explicitly does not cover the raw evidence body bytes (which are redacted before leaving the server) or form a Merkle tree. It is a digest of what the platform recorded — not an authenticity attestation. The algorithm, scope, and limitation are exposed in the proof response so you can audit exactly what was hashed.
Recorded recommendations, not automated fixes.
Where the matched template or tool carries a remediation reference — a CWE id, an OWASP category, or a stored recommendation — it is surfaced in the proof bundle. The platform does not generate fix code or claim automated remediation.
The remediation section shows exactly what was recorded: a recommendation string, a reference URL, and the original tool that produced it. If no recommendation was stored, the panel says so rather than fabricating one.
A link to the scan launcher, not a fake “Verify fix” button.
The “re-test” entry point in the platform routes to the existing scan-launcher tool — not a dedicated “Verify fix” button that would suggest re-confirmation logic that does not exist on this deployment.
Re-running a scan against the same target after a fix is the correct procedure. The platform makes that action available but does not paper over the gap betweendetected again and fixed. A re-test integration that compares before/after evidence and generates a regression verdict is planned for a later phase.
See the proof layer in action
The landing page embeds the same ScanView component that renders real platform data. Explore the demo scan to see evidence rows, verification status, and metadata — exactly as the platform presents them.
View demo scanBenchmark infrastructure
Nyxeara maintains an independently verified ground-truth benchmark for the nyx-lab target. Metrics are computed from live scanner execution — not fabricated.
Methodology: Ground truth established by source-code review of nyx-lab v1.0. Scanner run with active checks, max_pages=30, max_depth=2. Results are fully reproducible across 3 runs. False negatives are documented with root causes. Benchmark runner at scripts/benchmark/.