How a scan works

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.

Sign in with GitHub

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.

The security engine reads the code

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. It looks at:

• The code itself, for things like missing authentication, injection holes, cross-site scripting, and secrets left sitting in a file.
• Configuration, for things like an admin page with no lock on it, open CORS, debug mode left on, or database rules left wide open.
• Dependency manifests, the files that list the outside packages your app pulls in, checked against known security holes.

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 just search for one kind of bug. It covers the whole spread of mistakes 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, disabled database row-level security, and debug mode left on in production. It also checks the outside packages your app depends on against known security holes.

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.

You get a 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.