Reading a report

Severities and the score

Every finding carries one of five severities — CRITICAL, HIGH, MEDIUM, LOW, INFO — and each contributes a fixed number of points deducted from a starting score of 100: 25 for CRITICAL, 10 for HIGH, 4 for MEDIUM, 1 for LOW, and 0 for INFO. The score is 100 minus the sum of those deductions, floored at 0.

A finding the false-positive classifier has flagged is excluded from the deduction — it does not lower the score — but it is not deleted from the report either. It is shown in its own section so you can review the classifier's reasoning and override it if the flag turns out to be wrong.

Grade bands

The numeric score maps to a letter grade:

A scan that could not complete in full is graded n/a, never rounded up to an A. See Degraded and unknown below.

Verdicts on a multi-model verification

A multi-model contract or code verification produces a verdict of PASS, CAUTION, or FAIL rather than a plain score. PASS is treated as the strongest claim a report can make — that the panel actually looked and found nothing — so it is the one verdict that can be withheld even when the raw consolidation would have produced it. A gate downgrades a PASS to CAUTION, and caps the score at 50, whenever any of the following is true for that run: reviewed-function coverage fell under the threshold the gate enforces, no finding was backed by an actual execution (a Foundry proof-of-concept or an adversarial on-chain campaign), or a finding cites a source location that does not resolve in the code actually supplied. A FAIL or a CAUTION reached without hitting the gate is never softened the same way — those verdicts rest on findings a reader can check on their own, and downgrading them would add false doubt rather than remove it.

"Degraded" and "unknown"

A scan is marked degraded when one or more of its required tools failed or was skipped. A degraded scan is not scored — an empty findings list from a scan that did not run in full means the tools did not look, not that the target is clean. The report shows exactly which tools failed (with the error) and which were skipped (with the reason), rather than folding that gap into a silent zero.

When nothing at all ran, the scan is shown as failed outright: the report says plainly that it describes nothing about the target and carries no score. The same discipline holds for a cloud posture check that could not read a resource, or a contract chain whose testnet proof could not run — see Limitations for where this shows up per scan family. Nowhere in this platform does an unanswered question default to a clean result.

False positives

The underlying tools sometimes match a pattern that is technically correct but, in context, almost never a real problem — a gitleaks "generic API key" rule firing on a public contract address, or a plaintext-HTTP-link rule firing inside an auto-generated coverage report. A classifier checks every finding through three layers, in order, and the first match wins:

1. Path — the file sits in a generated build-artifact directory (coverage/, artifacts/, node_modules/, and similar) that is not part of the audit surface.
2. Pattern — the matched value has a shape that is provably not sensitive, such as an EVM address or a transaction hash, which are public by definition. This layer is deliberately conservative around credentials files: a value shaped like an address inside a .env stays flagged, because in that context it is more likely a real secret.
3. Context — the file kind makes the finding meaningless even outside a build directory, such as a .env.example template or a lockfile's integrity hash.

A flagged finding is never deleted. It stays in the findings list, shown in its own section, and you can mark it back as real if the classifier is wrong for your case.

The lifecycle of a finding

A report's own status column is keyed to that one run: rescan the target and the ids renumber. Findings tracked for remediation are matched across runs by a separate identity — a fingerprint of the tool, the title, and the file — so the same underlying issue can be followed scan to scan and cross-referenced against a suppression.

A tracked finding moves through a small set of states:

• Open — the default state for anything newly raised.
• Fix claimed — a person recorded that something was changed. This does not close the finding; there is deliberately no button that marks a finding fixed directly, because that would let the distinction the whole feature exists to preserve be clicked away.
• Fix verified — reached only by reconciliation, when a later scan that demonstrably read the affected code (the file was in its scanned set, the symbol still exists in the source it parsed, and the panel did not fail) does not report the finding again. A scan that skipped the file, or was degraded, leaves the claim standing rather than verifying it.
• Regressed — a finding previously verified fixed reappeared in a later scan.
• Accepted — closed deliberately, without a fix. Accepting a risk reduces protection, so it requires a written reason and a review date; an acceptance with no end date is treated as indistinguishable from forgetting about it.

Suppressing a finding as a false positive works the same way: it is hidden from every future scan on that and any other target it recurs on, but only after a written reason is given, and it can be reversed at any time.

Exporting and printing

A completed verification can be printed to a client-style PDF from the report's print view — a server-rendered, light-mode page meant for a browser's own "Save as PDF". It carries the same verdict, findings, coverage, and execution results as the interactive report, plus every static finding the panel considered but did not carry forward into the final list, each with its own stated reason. The printed page ends with a fixed disclaimer:

"This is an automated security review. It is a strong pre-audit and continuous-monitoring instrument, but it does NOT replace a manual audit by a professional firm: deep protocol-specific economic reasoning, multi-week adversarial review, and formal verification of all invariants remain out of scope. Findings are best-effort and may contain false positives and false negatives. No warranty is expressed or implied; deploying audited code remains at the owner's risk."