How a scan works
A scan reads one repository and returns a report. You sign in with GitHub, pick the repo, and the code is fetched into an isolated, single-use job where the engine reads it along with your configuration and your dependency manifests. An AI layer filters out false positives. You get a score, a grade, findings and a fix prompt, and the code is discarded when the job exits.
A scan is short and it does one thing: it reads your code and tells you what is wrong with it, in plain English, with a fix you can paste back into your AI builder. You do not need to know any security to run one. Here is the whole flow, start to finish.
What access does signing in with GitHub give you?
You start by signing in with GitHub. The access we ask for is read-only. It lets us do two things and nothing else: list your repositories so you can pick one, and read the one you pick. No pushes, no pull requests, and no reading repos you did not choose.
You do not need to sign in to read this wiki. Signing in is only for running a scan, because a scan has to read real code.
Pick a repo
Once you are in, you choose a single repository to scan. That is the only repo the scan will touch. If you have several apps, you scan them one at a time, each on its own.
What does the security engine read?
Your code is fetched into an isolated, single-use scan job. Inside that job the security engine reads through the repository and looks for the mistakes that AI builders tend to ship.
It reads more than just the application code. Four things get looked at:
- The code itself, for missing authentication, injection holes, cross-site scripting, secrets left sitting in a file, and personal or card data written into source or into a log line.
- Configuration, for an admin page with no lock on it, open CORS, debug mode left on, database rules left wide open, or a storage bucket left public.
- Your git history, for keys that were committed and later deleted. Removing a secret from a file does not remove it from the repository, and that is the one most people get wrong.
- Dependency manifests, the files listing the outside packages your app pulls in, matched against known vulnerabilities.
An AI review layer sits on top of the raw checks to cut noise and keep the findings that actually matter to your app.
The engine does not search for one kind of bug. It covers the spread these apps tend to ship: leaked and hardcoded secrets, committed environment files, secrets that ended up in the browser, missing or client-side-only authentication, exposed admin pages, open CORS, the injection family, cross-site scripting, mass assignment, weak password hashing, weak randomness, unverified tokens and webhooks, Supabase row-level security switched off, debug mode left on in production, and personal, Aadhaar, PAN or card data sitting where it should not be. Where a provider allows it, a secret is checked against that provider before it is reported, so a confirmed finding means the key was live rather than that it looked like one. Common vulnerabilities covers each of these in plain English.
Your source code is never stored. It is read inside that single job, scanned, and discarded the moment the job exits. There is no copy kept and no backup, and nothing is trained on it. The findings stay, the code does not. Your code and your data walks through exactly what is kept and for how long.
What is in the report?
When the scan finishes you get a report with four parts:
- A score, so you can see at a glance how the app is doing. Higher is better.
- A letter grade, a plain summary of that score.
- Findings grouped by severity, from Critical down to Low, so the most dangerous issues sit at the top.
- A copy-paste fix prompt attached to each finding.
Every finding says what the problem is and why it matters, without jargon. You do not have to read the code to understand it. Reading your report explains the score, the grade, and the severity levels in more detail.
Copy the fix, then rescan
Each finding comes with a fix prompt written for the exact tool that built your app, whether that is Lovable, Bolt, Cursor or v0. You copy it, paste it back into your AI builder, and apply it. The prompt is delivered in small steps so the tool changes one thing at a time instead of rewriting your app. The fix prompt covers how to use it well.
When you have applied a fix, you can rescan the same repo. If the fix landed, the finding is gone from the new report. That loop, scan, fix, rescan, is how the grade climbs.
Try a scan
The clearest way to understand a scan is to run one on your own app. Sign in with GitHub and scan a repo free, one a month, no card: start a scan.