Reading a report

A report opens with a summary, a risk score and a count, then lists findings from most to least severe. Everything below the summary is written to be acted on, not just read.

Risk score

The risk score runs from 0 to 100 and expresses how exposed this code is overall: it weighs the worst findings far more heavily than the number of findings. A single critical, remotely reachable issue scores higher than a dozen low-severity ones. Use it to compare a repository against itself over time; it is not a benchmark against other codebases.

Severity

• Critical — remotely exploitable, leads to remote code execution, authentication bypass, full data compromise, or a leaked production secret.
• High — a serious weakness that needs a specific condition, such as an authenticated session or a particular input path.
• Medium — real but limited: it needs an unlikely precondition, or the damage is contained.
• Low — hygiene and hardening: worth fixing, not worth waking anyone up for.
• Info — an observation with no direct security impact.

Inside a finding

Each finding is built so you can judge it without trusting it blindly:

• Location — the file and line range the issue lives at.
• Evidence — the exact code quoted from your repository. If the evidence does not match the file, the finding is wrong; that is the point of quoting it.
• Description — what is wrong, written for a developer who did not write this code.
• Impact — what an attacker gets out of it, and what they need first.
• How to fix it — ordered steps, not general advice.
• Patch — corrected code written against the code that was quoted, ready to adapt.
• How to verify — the check that tells you the fix worked, so you are not guessing.
• References — one to three authoritative links, such as the CWE entry or the library's own documentation.
• Confidence — how sure the reviewer is. Low confidence means the finding depends on context the audit could not see.

CWE mapping

Findings carry a CWE identifier where one applies. The CWE is what ties your findings to the rest of the system: it drives the weakness breakdown on the dashboard, the CVE feed filters, and the key that keeps a dismissal attached to the same issue across audits.

Exporting

Any report can be copied or downloaded as Markdown, with the patches inside fenced code blocks, which is convenient for pasting into an issue tracker or a pull request description. The findings explorer additionally exports CSV across repositories.

Sharing a report

A finished report can be handed to someone without an account: the share button copies a read-only link that carries its own signature and expiry. The page it opens shows the report and nothing else — no dismissing, no account data — and the link stops working after seven days. Anyone with the link can read the report, so treat it like the code it describes.

Language

Reports are written in the language you were using when you started the audit. Code, file paths, CWE identifiers, patches and reference links stay as they are — only the prose is translated.