Solutions · Before you launch
Know where you stand before strangers do.
Launch day is when strangers start looking. Most curious, a few hostile — all of them at code a scan reads in about a minute.
The situation
Right now, nobody is trying. That changes on launch day.
The window between shipping and being looked at is measured in hours.
Before launch, the number of people who have looked at your app adversarially is zero. After launch it is not, and the gap between those two states closes in hours.
The risky part is not the sophisticated attack. It is the obvious thing — a public table, a key in a bundle — found by someone who was only curious, and then posted, because a screenshot of a leaking app is a good post.
So the goal for launch is narrow: no critical or high finding left open, every key that ever touched the repo rotated, and a short written list of the things you had to configure outside the code. That is a morning's work if you know what is on the list.
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.
Anything that exposes another person's data
Reading another user's data, acting as them, or reaching an admin surface. This is the finding that becomes a public thread, so it's ranked first and never hidden behind a plan.
Keys that still work
Live keys in history, valid right now, for services that cost money. Rotating these is the single highest-value hour of work before a launch.
A score you can explain
Every dependency against the public record of known holes, plus your score with a plain breakdown of what pulled it down. The number is only useful if you can see what it is made of.
The list to close by hand
Whatever we could not read — dashboard-configured rules, missing migrations, a bucket policy that lives outside the repo. These are listed separately so you can close them by hand before launch rather than discovering them after.
How it fits
A launch checklist that takes one morning.
Do this the week before, not the night before. Rotating a live key changes behaviour — leave a day to notice breakage.
- 01
A week out, scan and read everything
Scan the branch you will actually deploy. Read the whole report, including the medium and low findings if you are on Pro — before a launch is the one time the long tail is worth your attention.
If a stage failed, the report withholds the score and says so rather than giving you a number it cannot stand behind. Re-run it.
- 02
Close the serious findings
Close every critical and high finding. On Pro, VibeCheck writes the change onto its own branch and tells you what it left alone — anything needing a decision only you can make is described, not attempted.
Fixes never land on your default branch. You review the diff and merge it yourself.
- 03
Rotate keys, then re-scan
Rotate every key the report mentions, in the provider's dashboard, even the ones you think were never live. Then re-scan to confirm the history findings are the only thing left and that nothing new appeared.
Rotation is the part no tool can do for you, and the part that actually removes the risk.
- 04
Handle the unchecked list, then share the number
Work through the not-checked list by hand and write down what you found. When someone asks about your security posture — and after a launch, someone will — that list is the honest answer.
Then share the score card if you want to. It states the date, the rule pack version and whether anything was dismissed.
We will not give you a badge that says secure.
A clean report means no issues were found in the checks we ran. It is not a certificate, it does not say your app is secure, and we will never print those words on a card you can post — because the moment a badge like that is worth something, it is worth faking. What the card states is the score, the date, the rule pack version, and whether any findings were dismissed.
Better you find it than they do.
Free gets you the whole scan and every critical and high finding. Run it now, fix what it finds, and share the number afterwards.