Solutions · While you build
Find it in the branch that made it.
The cheapest problem to fix is one you find in the branch that created it. You still remember the decision, and no data has gone through it yet.
The situation
The code works. That was never the question.
You are building fast, with help, and you cannot read every line the way you would read your own.
You are shipping quickly, mostly with an assistant writing the code. It works, tests pass, and the parts you did not write yourself you have not read closely.
Security problems from this kind of work are rarely exotic. They are the temporary key that got committed, the route added outside the protected folder, the table left open while you were testing. None of them look wrong in a diff.
Running a scan per branch turns that into a checklist rather than a worry. It takes about a minute, it runs with your browser closed, and it tells you which of the four questions actually applies to what you just changed.
What usually turns up
The findings this moment tends to produce.
Drawn from the rule pack, not from anyone's repo. Your report will differ — this is the shape of it.
The key you were only using temporarily
Pasted in to get something working, committed once, moved to an environment variable later. The move doesn't remove the original — still in history, still valid until you rotate it.
The route the middleware doesn't actually match
Added under a folder you assumed was protected. The matcher doesn't cover it, and nothing in the code looks wrong — the protection is somewhere else.
The table you left open while testing
Row-level security you meant to come back to. If the migration is committed we read it and tell you which tables are open. If it is not, you get an unchecked result rather than a pass.
Packages added since the last scan
Dependencies you added this week, checked against the public record of known holes. Usually clean, and a clean result here is one you can actually rely on because the database ships inside the sandbox.
How it fits
It sits behind your pushes, not in front of them.
No CI config, no YAML, no build step. It watches the branches you point it at.
- 01
Point it at your working branch
Connect the repository once, read-only. Pick which branches you want watched — usually the one you develop on, not just your default.
Read-only is enough for every scan. Write access is a separate grant and it is not needed here.
- 02
Push, and read the report when it lands
Push as normal. Each push queues a scan that runs on our side, and you get an email when the report is ready.
Free is two scans a day, rolling over to a maximum of ten. Enough for a few branches; not enough for every commit.
- 03
Fix, or dismiss with a reason
Fix what matters and dismiss what does not, with a reason. A dismissal survives future scans, so you are not told about the same deliberate decision every week.
Dismissed findings are excluded from your score. A dismissed critical stays visible and labelled rather than disappearing.
- 04
Confirm it is gone
The next scan confirms the finding is gone. If you reintroduce it, it comes back with the identity it had before — findings are identified by the rule and the code they matched, not by a line number.
Which is also why moving a function does not resurrect something you already dealt with.
The parts you configured in a dashboard are not in your repo.
A scan reads the code in your repository. Anything configured in a hosting dashboard — your database's access rules, a storage bucket's policy — is invisible to it, and gets reported as not checked with instructions for reading it yourself. During development that is the most common gap, because those settings are usually the last thing to get written down.
Scan the branch you're on now.
Two scans a day on the free plan, one repo, read-only. Enough to check a branch before you merge it.