Reference

Findings and product lines

Every problem PatchLabs reports, whether the Lab reproduced it in a rebuilt database or Code found it in your repo, arrives in the same shape with a stable ID. This page explains the four product lines and each field of a finding.

The four product lines

Lab and Code run on every check; there is nothing to switch on. Both work from the repo and the rebuilt lab database only: they never connect to your live app or database. Live posture is opt-in per app: PatchLabs never touches your database, and Live posture only loads your public home page, like any visitor, and only on domains you verify.

One finding shape

Each finding, from either line, has the same fields. This one is from our deliberately leaky demo app (fake data):

{"id": "PL-001", "line": "lab", "severity": "critical",
 "title": "Anonymous visitor can read personal data",
 "object": "public.profiles",
 "file": "supabase/migrations/20261101090000_init.sql", "line_no": 12,
 "evidence": "policy \"Profiles are viewable by everyone\" using (true); columns email, phone",
 "proven": true,
 "proof": "anonymous visitor read 2 rows with email and phone",
 "fix": "Replace the open read policy with an owner-only policy",
 "fixed_in_lab": true}

id

The stable finding ID, such as PL-001. Each has a page explaining it: the finding index. IDs never change meaning and are never reused.

line

lab, code or live: which product line found it. The report groups findings by line; live findings come from Live posture and appear on the app page, not in a repo check.

severity

critical, high, medium, low or info. See severity below.

title

A plain-English summary. It can be more specific than the ID’s general title (for example naming the provider of a key).

object

What the finding is about: a table (public.profiles), a bucket, a function folder or a source file (src/pages/Admin.tsx).

file, line_no

Where to look in the repo. For Lab findings, the migration that created the rule; for Code findings, the exact line.

evidence

A short excerpt showing why. Keys are masked and no personal data is ever included.

proven

true when the Lab reproduced it with a real query against the rebuilt database. Code findings are false: they are read from the code, not reproduced, and say so.

proof

For proven findings, what the lab did and saw, such as “signed-in stranger read 3 rows owned by another user”.

fix

One line saying what to change. Database fixes also come as a full migration in the report.

fixed_in_lab

true when PatchLabs Fix wrote a fix for this finding and it passed the lab proof.

advisory

Dependency findings (PL-023) only: the advisory id from OSV, such as a GHSA or CVE id.

Severity

Severity follows one question: who, outside the people meant to see it, can read or change the data?

Dependency findings take the severity of their published advisory. Key findings depend on what the key can do.

Finding IDs

Coming checks have pages so you can check your own project, but they won’t appear in a report until they ship. The changelog records when each one does.

Where findings appear

• The report page groups findings by line, most severe first, with the proof table for Lab findings. Reading a report.
• The API: a finished check’s summary carries findings (up to 200, in this shape) and counts by severity, next to the existing summary fields. REST API.
• Alerts and webhooks count new findings since the last check. Monitoring.
• The free RLS check uses the same IDs for PL-001 to PL-008, from the migrations as written (no lab).

Limits