Explainer
Local vs. cloud code scanning: what changes when your code stays on your machine
Local, repository-connected and URL-based security scanning each see different things. A clear comparison of privacy, access, coverage and when to use each.
Key takeaways
- 01Local scanners analyze code on your own device; repository-connected scanners need access to your Git host; URL scanners test the deployed app from outside.
- 02Local analysis is the strongest default for confidential, client or pre-release code.
- 03No single approach sees everything: local tools can’t see dashboard settings, and URL scanners can’t see code paths they can’t reach.
- 04Ask any security tool where your code goes and what network connections it makes.
Security scanning used to be something only larger teams set up. AI-assisted development changed that: solo founders and small studios now ship real products and need a way to check them. The options fall into three broad approaches, and the differences matter more than marketing pages suggest.
Three ways to scan an application
Local project analysis
A tool installed on your computer inspects the project folder directly. The analysis runs on your machine, using its resources. This is how VibeTect works.
- Sees: the source and configuration files in the folder you choose.
- Needs: the code on your machine. No repository permissions.
- Doesn’t see: settings that exist only in hosted dashboards, or how the deployed app behaves.
Repository-connected scanning
A service connects to your Git host — usually by installing an app or granting a token — and scans repositories, often on every pull request.
- Sees: code in the connected repositories, continuously.
- Needs: ongoing read access to your repositories, granted at the account or organization level.
- Doesn’t see: code that isn’t in a connected repository; deployed configuration.
URL-based (live-app) scanning
A service tests your deployed application from the outside, the way an attacker would start.
- Sees: what’s actually exposed on the internet — headers, open endpoints, misconfigured storage, sometimes database rules.
- Needs: a URL, and sometimes test credentials.
- Doesn’t see: code paths it can’t reach, and problems that haven’t been deployed yet.
Comparing the trade-offs
| Local analysis | Repository-connected | URL-based | |
|---|---|---|---|
| Where your code is analyzed | On your device | On the vendor’s infrastructure | Not required (tests the live app) |
| Access you grant | None to your Git host | Repository read access | A URL, possibly credentials |
| Finds issues before deploy | Yes | Yes | No |
| Sees deployed configuration | No | No | Partly |
| Works for code you can’t share | Yes | Depends on agreements | Not applicable |
| Best moment | Before every deploy | On every pull request | After each deploy |
When local analysis is the right default
Confidential and client code. Many client contracts and employment agreements restrict sharing source code with third parties. Local analysis checks the code without that question arising.
No standing access. Granting a service read access to your repositories creates a long-lived credential that can itself become a target. A local tool needs nothing to revoke later.
Exported and in-progress projects. Code exported from an AI app builder, a feature branch you haven’t pushed, or a prototype that isn’t in a repository at all can be checked where it is.
Speed of the feedback loop. The best time to find a problem is minutes after an assistant wrote it, before it’s committed, reviewed and deployed.
When you need more than local
Deployed configuration. Database policies created in a dashboard, storage bucket permissions, hosting environment variables and DNS settings don’t live in your project folder. Check them in the platform, or use a live-app scanner.
Team-wide enforcement. Larger teams often want checks to run automatically on every pull request, regardless of who opened it. That’s where repository-connected scanning or CI integration fits.
High-stakes systems. For software that handles payments, health data or other sensitive information at scale, automated tools are a first line of defense, not a sign-off. Commission a professional assessment — and use automated checks first, so expert time goes to the hard problems.
What “local” should mean — questions to ask
“Local” is a strong claim, and you should hold any vendor to it, including us:
- Does analysis require uploading source code? If yes, it isn’t local analysis, whatever the marketing says.
- What network connections does the app make? Updates, licensing and telemetry are common reasons. A trustworthy vendor documents them.
- What is stored, and where? Findings, logs and caches should stay on your machine unless you choose to share them.
- Can you verify the installer? Download from the vendor’s own domain and compare published checksums where they’re provided.
The layered approach
The strongest setup combines approaches at the moments they’re best at: a local inspection before you push, platform settings reviewed where they live, and an external check of what’s actually exposed after deploy. Each one covers blind spots in the others.
If you’re building with AI and haven’t done any of these yet, start with the first. Run a local check on your project before your next deploy, and work through our vibe coding security checklist for the items that live outside your code.