The security score and verdicts
1 min read
A ceiling, not a sum
The score doesn't add up penalty points per finding: it starts from the ceiling set by the single worst severity found. The logic: an app with one critical hole and nothing else wrong isn't "a healthy app with one issue", it's a dangerous app. No number of small findings can offset a critical one.
- Worst finding = critical → ceiling 20.
- Worst finding = high → ceiling 55.
- Worst finding = medium → ceiling 75.
- Worst finding = low → ceiling 90.
- Worst finding = info, or no findings at all → 100.
The volume penalty
Beyond the ceiling, every additional significant finding (critical, high, medium or low severity, not info) beyond the first costs 4 points. Three high-severity findings don't lower the ceiling any further than one does (it's still 55), but they cost 2 × 4 = 8 points more than a single isolated high finding.
One exception: if the Supabase service_role key is exposed, the score is capped at 5 regardless of everything else: that key bypasses RLS entirely, so nothing else matters while it's exposed.
One score, always the fullest available
The score shown is the active-mode one when it ran, the passive one otherwise. There are never two separate scores to reconcile, and it can only get worse once active mode runs: some findings only surface in active mode, so a site scanned only passively can look better-rated than it really is. The score never goes up by switching to active, it only ever reflects what was actually tested.
The verdicts
"Healthy" (high score), "Needs attention" (mid score), "Critical" (low score) directly reflect the score. "Scan running", "Scan failed" and "Scan blocked" are distinct states, unrelated to any score (see the article on blocked or failed scans).