Trust

From red to green: how to read your VerifiedApp report

A report is a to-do list, not a grade

The first time you see a security report with red on it, the instinct is to feel caught out. Resist that — a report is not a judgment, it is a prioritized list of specific, fixable things. Most findings are common, most fixes are known, and the report tells you which to do first. Here is how to read one calmly.

Findings, grouped by category

Your report organizes checks into the areas a scan covers — secrets, TLS and certificates, security headers, cookies, exposed files, CORS, dependencies, frontend leaks. Within each, every rule shows as passed or failed. A passed rule is a door you have already shut; a failed rule is one to look at. Seeing many passes is the normal, healthy state — the failures are where your attention goes.

Severity: what to do first

Every failure carries a severity, and that is your priority order:

  • Critical / High — fix now. This is where the real risk lives: an exposed secret, a downloadable .env, a broken or ancient TLS configuration, a missing protection on something sensitive. These are the findings attackers act on.
  • Medium — fix soon. Real issues that need a specific condition or chain to be dangerous: a permissive CSP, an internal URL leak, a missing important header.
  • Low / Info — polish. Good hygiene and easy wins — a missing modern header, a minor disclosure — but not urgent.

If you do nothing else, clear the Criticals and Highs. That removes the exposures that get exploited first.

Reading a single finding

Each finding is written to be actionable. It names the exact rule, explains what the problem is and why it matters, and tells you how to fix it. A good finding does not just say something is wrong — it points at one concrete thing and one concrete change. Work through them one at a time; the list shrinks fast because many fixes (a header, a cookie flag, a moved key) take minutes.

Getting from red to green

The path is simple, if not always instant: clear Critical and High, then Medium, then tidy the rest. Re-scan after your changes to confirm each fix actually took — sometimes a config change does not deploy the way you expect, and the re-scan is how you know it landed. On the Trust tier, daily re-scans track this for you and keep the result current as your site evolves.

A note on never reaching perfect

Most real, well-run sites sit at mostly green with a couple of Mediums rather than a flawless sheet, and that is fine. Frameworks reintroduce small issues; new checks appear. The goal is not a permanent perfect score — it is keeping the serious findings at zero and the rest trending down. That is what a good report, read regularly, gives you.

See a real report

The clearest way to understand the format is to look at one. Browse a live public verification report and see exactly how findings, severities and fixes are laid out.

Related reading

FAQ

What should I fix first in my report?
Critical and High findings — exposed secrets, weak or broken TLS, missing protections on sensitive areas. These carry the real risk and are what attackers act on first. Clear them before moving to Medium and the lower-severity polish.
Is a report with red findings a bad sign?
Not at all — it is normal, especially on a first scan. A report is a prioritized to-do list of specific, fixable issues, not a verdict. Most findings are common and most fixes are quick; the point is to work down the list by severity.
How do I know a fix actually worked?
Re-scan after making the change. Config updates do not always deploy the way you expect, and a re-scan confirms the finding is genuinely resolved. On the Trust tier, daily re-scans track this automatically.