Reading your report

A report is meant to be read by a founder, not a security engineer. It gives you a number, a grade, and a list of problems sorted so the worst ones are at the top. Here is how to read each part and decide what to do first.

The score

At the top of the report is a score. It is a single number that sums up how the app is doing overall. Higher is better. A low score means the scan found serious problems. A high score means it found few or none.

The score is there so you can watch it move. Fix real issues and rescan, and the number goes up. It is the fastest way to see whether your work actually changed anything.

The letter grade

Next to the score is a letter grade. It is a plain summary of the score, the same idea in a form you can read at a glance. A better grade means a healthier app. Think of it as the short version of the number, useful when you just want to know "good or bad" without reading further.

A is 90 and up, B is 70, C is 50, D is 25. Anything below that is an F.

One thing worth setting straight early: a single fix prompt will not carry you from F to A. The prompt covers your 25 heaviest findings, so on a big report it is one round of several. If you want to see where a number came from, open "How this is scored" next to the grade. It shows the weight of every severity, the arithmetic, and what your score becomes after this prompt.

That matters most on a noisy repo. If a scan found ninety problems, clearing twenty-five of them is real work that the score can only partly show. Watch the Critical and High counts fall alongside the number. That is the honest measure of progress on a big cleanup.

Severity: what the levels mean

Every finding carries a severity, and the report is sorted by it. There are four levels:

• Critical. The most dangerous. These are the holes that get apps broken into: a database anyone can read, a live key sitting in the code, an admin page with no login. Treat these as "stop and fix now".
• High. Serious problems that a determined attacker could use. Not quite as immediate as Critical, but you do not want to ship with them.
• Medium. Real issues worth fixing, but lower risk or harder to exploit.
• Low. Minor or cosmetic. Good hygiene to clean up, not urgent.

The point of severity is to save you from guessing. You do not have to judge which problem matters most. The report already ordered them for you, so reading top to bottom is the same as working in order of danger.

What to fix first

Work from the top down. Fix everything Critical, then everything High, before you touch anything cosmetic. A Critical finding is the difference between a safe app and a headline. A Low finding is a nice-to-have. Do not spend an afternoon on a Low while a Critical sits open.

Each finding tells you what the problem is and why it matters, in plain words. On a paid scan it also comes with a fix prompt you can paste back into your AI builder. The fix prompt explains how to apply it one step at a time. If you want to understand the kinds of problems behind the labels, common vulnerabilities walks through them.

Free shows you everything, paid tells you how to fix it

A free scan shows you every finding. Not a sample, not a top slice. The rule that fired, the severity, the file, the line, the description, and your real score and grade.

What free does not include is the repair. The copy-paste fix prompt and the per-finding AI fix suggestions are locked until you upgrade to Founder, or spend one top-up credit to unlock that single report. If your code has not changed since the free scan, spending a credit on the report you already have is the cheapest way through, because rescanning an unchanged commit just returns the same report.

One thing worth knowing about free scores. We run the AI false-positive review over your 5 most severe findings on a free scan, rather than up to 50. Anything beyond that is scored at full weight without being reviewed, so a free score can read a little harsher than a paid scan of the same commit. The report tells you when this applies to yours. Plans covers what each option includes.

Confirming a fix with a rescan

A report is a snapshot in time. Once you have applied a fix, the way to prove it worked is to rescan the same repo. If the fix really landed, the finding is gone from the new report and your score moves up. If it is still there, the change did not take, and you can try the fix prompt again.

This is the honest test. You are not trusting that a fix worked, you are checking. Scan, fix, rescan, and watch the findings drop away.

Run your report

The best way to read a report is to have one of your own. Sign in with GitHub and scan a repo free, one a month, no card: start a scan.