How it works
- 1
Paste a public repo URL
Any shape works — a full github.com URL, a git@ SSH remote, or a bare owner/repo. There's no account, no OAuth prompt, and no GitHub App to install.
- 2
We read the config and the code that matters
The repo tree is listed once, then up to 120 relevant files are read: package.json, vercel.json, next.config, tsconfig, middleware, API routes, and app code. Monorepo workspaces are read one level deep so a packages/ layout doesn't score a false 100.
- 3
Applicable checks run
Rules that don't apply are skipped — a repo without Prisma never runs the Prisma rules. Your report shows how many of the 30 actually ran.
- 4
You get a score and your three worst findings, free
In full: what's wrong, the file and line, and the fix. Plus a copy-as-markdown button, so you can walk away with them and never give us an email.
- 5
The rest goes to your inbox, if you want it
One email address, one confirmation click. That click is what unlocks the long tail — and it's also the only thing that ever puts an address on a list.
How the score works
You start at 100 and lose points per finding — 25 for a critical, 12 high, 5 medium, 2 low. Repeats of the same rule decay by half each time, so one rule firing across twelve files can't bury five genuinely different problems.
What it can't tell you
This is worth being straight about, because a scanner that oversells itself is worse than no scanner:
- 100 doesn't mean safe. It means none of 30 known footguns fired. Your own bugs are still your own bugs.
- It reads text, not runtime. It can see that a CSP has no
default-src; it cannot see what your app does under load. - It reads up to 120 files. A very large repo is sampled, prioritising config and API routes. Findings are real; absence of findings is weaker evidence on a big tree.
- Public repos only.There is no private-repo mode, because that would need write-adjacent OAuth scopes we don't want to hold.