Is your app ready for real users?
You built something that works. This tells you what happens when strangers, traffic and attackers arrive — in plain English, with the fix for each thing, ranked by what actually matters.
Real scanners, not a checklist
Secret scanning across your git history, known-vulnerability checks on every dependency, static analysis, and a look at what your live URL exposes.
Every finding read in context
Scanners cry wolf. Each hit is reviewed against the surrounding code and dropped when it cannot actually be reached — so what is left is worth your afternoon.
No scare tactics
Severity is how much damage is really possible, not how alarming it sounds. If your app is in decent shape, the report says so.
Start a scan
Upload a zip, link a repo, or just give us a URL. Five minutes later you have the report.
Sign in to scanScanning is gated while the service settles — it reads source code and costs real money per run, and both should be attributable. Opening it up is a later decision.
- Your code is deleted once the report exists
- Read in an isolated sandbox with no route out
- Read-only against your live site — GET and HEAD, nothing else
- 5
- Pillars, scored separately
- Security, reliability, performance, observability and deployability — each with its own score out of 100.
- 18
- Pattern rules, over every file
- Fixed checks applied to the whole tree, so coverage does not shrink as your project grows.
- file:line
- Evidence on every finding
- No finding without a location and the quoted line. If we cannot show you where, we do not report it.
- 0
- Copies of your code kept
- The archive is deleted once the report is written. The report is yours; the source is not retained.
What we look at
Five things that decide whether a launch goes quietly. Each gets its own score out of 100, and the report explains every point you lost.
Security
Can a stranger read, change or take something that is not theirs? Auth gaps, injection, leaked keys, vulnerable dependencies.
Could someone take what is not theirs?
Reliability
What happens on a bad day. Unhandled errors, missing timeouts and retries, risky migrations, no health check.
What happens when something fails?
Performance
Whether it stays usable with real traffic. Repeated queries, huge payloads, missing caching, slow paths.
Does it hold up under real traffic?
Observability
Whether you could work out what went wrong at 2am. Useful logs, error tracking, and no personal data in either.
Could you debug it at 2am?
Deployability
Whether it can be shipped repeatably. Pinned builds, config and secrets handled properly, CI, infra as code.
Can it be shipped the same way twice?
A report you can act on
Most scanners are tuned to look thorough. Everything becomes critical, the score reads zero, and you learn nothing about what to do first. Here is the same finding, both ways.
Source code exposure — CRITICAL
“Your source code is downloadable by anyone, enabling competitor analysis and targeted attacks. Security score: 0/100. Not ready — fix critical issues before launch.”
Everything is urgent, so nothing is. The reader either panics or stops believing the report.
Your original front-end code can be read — Low
“Source maps turn your minified bundle back into readable code. It is front-end code, so nothing secret should be in it — but it does hand someone a map of how the app works, and occasionally an API key that was never meant to ship.”
Then: turn off source maps for production, and check the bundle for anything that should not be in a browser. Two minutes of work, honestly rated.
Severity is blast radius × reachability
Never effort-to-fix, and never how alarming it sounds.
Confidence is a separate field
A suspicion is labelled a suspicion instead of being quietly downgraded.
A finding needs a file and a line
“This looks insecure” is dropped before you ever see it.
Two ways to scan
A quick scan needs only your URL and finds everything visible from outside. A deep scan also reads your source, in an isolated sandbox, and cites the file and line for every finding. Whatever a scan could not assess is listed as not checked, never as fine.
| Can a scan tell you about… | Deep scan | Quick scan |
|---|---|---|
| Exposed headers, TLS, stray files, obvious misconfiguration | ||
| Secrets committed to the code (and to git history) | ||
| Known vulnerabilities in your dependencies | ||
| Who can reach what — auth and access-control gaps | ||
| Injection, unsafe input handling, dangerous defaults | ||
| Whether it can be deployed and debugged at all |
How it works
- 1
You hand it over
A zip, a repo link, or just your URL. The report goes to your account — no forms to fill in afterwards.
- 2
We scan it in a sealed box
Your code is read inside an isolated sandbox whose only route out is the one the analysis needs. The scanners run, then every hit is verified against the code around it.
- 3
You get the report
Usually within five minutes, in your email and your scan history. Share it at whatever level of detail you choose.
Your code, handled carefully
We are asking you to hand unreleased source code to a service on the internet. That deserves specifics rather than reassurance.
- Deleted after the report
- The uploaded archive and any clone are removed once the report exists — and on a failed scan too. What we keep is the report itself and the scan record.
- Read in an isolated sandbox with no way out
- Scanning runs in a throwaway sandbox whose network access is narrowed to the one endpoint the analysis needs. Nothing in your code can reach anything else, even if it tries.
- Secrets are named, never printed
- If we find an API key we tell you which file and line, and that it needs rotating. The value itself does not go in the report or the email.
- Read-only against your live site
- GET and HEAD only, a dozen or so requests. Nothing is submitted, changed or deleted, and your data is not read.
Questions
Do you keep my code?
No. The archive or clone is deleted as soon as the report exists — on a failed scan too. What we keep is the report and the scan record.
Will this break my live site?
It cannot. The only requests we make are GET and HEAD, a dozen or so of them. Nothing is submitted, changed or deleted, and we do not read your data.
Can I scan without giving you the source?
Yes, a URL is enough to start. It is a weaker scan and the report says exactly which categories went unchecked, rather than scoring them as fine.
What if it finds a secret?
We tell you which file and line, and that it needs rotating. The value itself never appears in the report or the email. Assume anything found that way is already compromised.
Is this just a wrapper around a language model?
No. Real scanners produce the candidates and a model reads each one against your code to decide whether it is genuinely reachable. Scores are computed by us from the findings — the model never grades its own work.
How much does it cost?
Nothing. It is how Scopic starts conversations about the deployment and hardening work we do. There is no upsell in the report beyond a link.
Would rather someone just fixed it?
Scopic has been building and hardening software for clients since 2006. Every finding in your report is something our engineers do routinely — hand us the report and we will tell you what it takes.