How we rate findings

How Lockpick sets severity, what a confirmed finding has to show, how sure each finding is, what to fix first and what checking again can prove.

Every finding in a Lockpick report carries a severity, a verdict and a confidence. They answer different questions. Severity says how bad it would be. The verdict says whether we saw all of it. Confidence says how strong the evidence is. Pulse and Deep apply the same rules.

Severity

Severity uses one scale, the same in the app, the docs and the API. From most to least serious it is Critical, High, Medium, Low and Info. Pulse and Deep rate findings up to High today. Critical is used for Monitor advisories, and a Monitor advisory with no published severity shows as Not rated.

A finding is rated high only when the scan shows one of these.

Data anyone can read. Something answered with data to a request with no sign-in, no cookie and no credential.
One customer reaching another. Data or actions that cross from one account or tenant to another.
An exposed credential or session. A secret key, a configuration file with credentials, or a session handed to someone who never signed in.

Taking over an address on your domain counts as well, when we can see the address is free to claim. Whoever claims it serves pages on your real domain and receives cookies set for all of it.

These are never rated high on their own.

Missing security headers, cookie flags and Content Security Policy gaps
TLS settings and certificate warnings
Software version and technology disclosure, including a library version that matches an advisory
Directory listings, stack traces and error pages
Open redirects
Email authentication settings such as DMARC and SPF

We still report them, at medium or below, because they are real gaps and cheap to close. When other observed evidence completes a bigger story, the report tells that story as an attack chain instead of raising the single finding.

What a confirmed finding has to show

Each kind of finding has a proof with four parts.

Part	What it answers
Source	Where an attack starts, and who can start it
Closest control	The protection that should have stopped it
Sink	What the attacker actually reaches
Impact	What follows from reaching it

For an open Supabase table the source is the anon key your client bundle ships by design, the closest control is row-level security, the sink is an unauthenticated read that returned rows, and the impact is what the returned columns hold.

A finding is confirmed only when the scan observed every part. When a part was inferred rather than seen, the finding is marked needs review and says which part is still open. A kind of finding with no defined proof is never confirmed. A finding is not actionable only when we hold positive evidence that its claim does not apply. Missing evidence is never enough for that, and Pulse and Deep do not record such evidence today, so their findings are either confirmed or need review.

The proof you see is written by Lockpick for the kind of finding. It never quotes a secret, a response body or how the scan ran.

How sure we are

High. A response from your site showed the exposure itself.
Medium. A public record or a pattern in your content points to it.
Low. It is inferred from headers, versions or what an API says about itself.

A second read that shows the same thing again raises the confidence one step. A second read that does not show it lowers it one step and keeps the finding in review.

How we rate urgency

Every finding also says when to fix it, in four words. Severity says how bad a thing would be. Urgency says whether to stop what you are doing.

Fix now. Stop and fix it today. Customer data, accounts or keys can be reached. That means a leaked key, an open database or API, password hashes, or an attack chain we observed.
Fix this week. Someone could use it against you. Any other high finding, and medium findings someone can use directly or with a victim, such as email that can be spoofed.
When you can. It makes an attack easier. It is not an attack on its own. Missing security headers, cookie flags and other hardening gaps, and low findings.
Nothing to do. Worth knowing. There is nothing to fix.

A skill, plugin, marketplace or MCP server is not your code to fix. You are deciding whether to install it, so its check says the same four levels in words about installing.

Don't install yet. This is what makes it unsafe to install, a critical finding we confirmed or one that sits in a hook. Wait for a fix or choose another.
Check before installing. Read this part, or ask the author about it, before you install.
Worth knowing. Not a reason to hold off. It helps to know what it does.
Nothing to do. There is nothing to check.

A finding never reads more urgent than the verdict at the top. Under Nothing risky found, every finding reads Worth knowing at most. Under Install with care, a finding reads Check before installing at most. Only what makes a repository Do not install reads Don't install yet. An app repository keeps the words above, from Fix now to Nothing to do.

Beside it, a card says how sure we are in one word. Confirmed means we saw all of it, or saw it again on a second read. Likely means we saw it once, or part of it is still open. Possible means it points to a problem we could not confirm.

A group of findings reads as urgent as its most urgent member. The badge at the top of a report is its most urgent card, so it says Fix now only when a card does. The quick check, Skill Check, emails, the CLI and the MCP tools use the same words. Urgency never changes the grade or the order of the list.

What to fix first

The report lists what to fix by how directly someone could use it, not by the severity label.

Findings anyone can use on their own, confirmed ones first
Findings that need a victim or a second step, such as email that can be spoofed
Hardening gaps that make an attacker's job easier

Within each group, confirmed findings come before ones that need review, stronger evidence before weaker, and only then the higher severity.

What checking again proves

Check again compares a new scan with the earlier one, and Re-read this record compares a fresh read of your public DNS records with the earlier finding. Each earlier finding ends in one of three states.

Fixed. The resource or record behind the finding was read again, and the finding was not there.
Still open. The same finding was raised again.
Inconclusive. The new read could not read what the finding rests on, or the two scans cannot be compared.

A finding is never marked fixed because a ticket was closed or a task was ticked. Removing an exposed key from your site does not revoke it, so rotate it with its provider as well.