Browse the wiki
Product

Reading your report

A report gives you a score, a letter grade and findings sorted by severity. A is 90 and up, B is 70, C is 50, D is 25, and anything below that is an F. Findings run Critical, High, Medium, Low, so reading top to bottom is the same as working worst first.

Updated 2026-08-30 For everyone

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.

What does the score mean?

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.

What does the letter grade mean?

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.

What do the severity 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 should you 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, including 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.

Free includes the repair too. The copy-paste fix prompt, the per-finding AI fix suggestions and the AI false-positive review all come with a free scan, the same ones a paid scan gets. So a free score is the same number a paid scan of that commit would give you. What a paid plan adds is more scans a month. Note that rescanning an unchanged commit just returns the same report rather than costing you a scan. Plans covers what each option includes.

How do you confirm a fix worked?

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.