A source review shows what the code could do. A live scan shows what the deployed system exposes to an outside requester. Neither tells you everything. A coding agent may fix the source while an old build stays deployed. A hosting setting can change behavior without a code change. Conversely, a live URL cannot reveal a secret that exists only in a private repository or inventory dependencies that have no observable behavior in the deployed app.
Pick evidence that fits the claim
| Question | Best first evidence | What it cannot settle alone |
|---|---|---|
| Are headers, TLS, and public files configured on the deployed site? | Live URL scan | Whether every environment and route has the same setup |
| Is a secret in shipped JavaScript? | Live bundle inspection | Secrets only in source, history, or server configuration |
| Is a dependency vulnerable? | Lockfile inventory, then impact review | Whether the vulnerable path is reachable in production |
| Can A read B's private record? | Two-account test against the deployed app | Every role, tenant, action, and resource variant |
| Is a Supabase public key dangerous? | Classify the key, then test grants and RLS | A key's presence does not show what data is reachable |
| Did a fix reach production? | Deploy, then repeat the live test | Whether the fix introduced a different regression |
I do not use “passed scan” as a synonym for “secure.” It means the checks that ran did not find a problem in the paths and conditions they reached. That is useful evidence, with a clear boundary.
A launch sequence for a small AI-built app
- Inventory the deployment. List the public URL, API origins, auth provider, database, storage, payment provider, and host. Record the production build or commit so you know what you tested.
- Scan the live app. Check public responses, headers, reachable endpoints, bundles, and exposed configuration. Triage each finding against the real app. Do not loosen a Content Security Policy just because a tool mistook a link for an embed.
- Review source and dependencies. Check server-side authorization, secrets, package advisories, and unsafe configuration. A live scanner cannot inspect the whole private repository.
- Test with two accounts. Request the same private resource as its owner, another signed-in user, and an anonymous visitor. Include reads and writes. A single account can miss horizontal access-control bugs. OWASP provides an authorization test model.
- Fix, deploy, and repeat. Confirm the change reached production, rerun the failed check, and keep the original request and expected response as a regression test.
For Supabase apps, include table grants, RLS policies, views, functions, and Storage rules in that review. Supabase distinguishes grants from RLS. A public publishable or legacy anon key is normal; a secret or service-role key in a browser bundle is not. Supabase documents the key types.
When to bring in a person
If the app handles sensitive client data, payments, privileged admin flows, or multi-tenant access, I would budget for a manual review before treating it as production-ready. An experienced tester can explore business logic and unusual role transitions that standardized checks will not reliably infer. The scan is a repeatable layer, not an insurance policy.
VAS focuses on the live application. It can help find externally visible issues and verify a deployed fix. It does not audit your repository. Your developer or AI coding agent still needs to inspect code and make the fix. Use our AI-built app security checklist for a wider launch pass.
Want to see what the live app exposes now? Run a scan.