Documentation Security and privacy · Menu
Security and privacy model for local scanning
Guardian is local-first because the alternative — uploading a client’s source to a third party — is not available to a lot of the teams who most need this kind of review.
Five separate things
Most confusion about a tool like this comes from collapsing these into one. They are not one.
| Component | Runs where | Sees what |
|---|---|---|
| Guardian local engine | Your machine | The project files the enabled checks need |
| Guardian reports | Files on your disk | Whatever the scan found, until you move them |
| Your CI runner | Infrastructure you control or rent | The same as a local run, in your pipeline’s environment |
| Optional sanitized sharing | Not built | Would carry approved, redacted findings only — never source, builds, secrets or raw reports |
| This marketing website | A static site | Nothing about your projects. It cannot reach your repository, and visiting it grants no access to anything |
Data handling
| Data | Read during a scan | Leaves your machine |
|---|---|---|
| Project source | Yes, locally | No |
| Platform and release configuration | Yes, locally | No |
| Dependency manifests and lockfiles | Yes, locally | No |
| Built artefacts you supply | Only if you run artefact analysis | No |
| Signing material | No | No |
| Environment secrets | Not requested | No |
| Production database rows | Not requested | No |
| Generated reports | Written locally | Only if you send them |
A complete per-check file-access catalogue is still being documented. Thechecks catalogue names the evidence each documented check uses; a definitive per-check file list is not published yet, and we would rather say so than publish one we cannot stand behind.
Network and accounts
- The scan command’s own help states that scans never use the network.
- A local scan involves no account, no sign-in and no token.
- Anything derived from external data, such as advisory information, is only as current as the copy on your machine. That limitation is inherent to working offline, not a defect.
- Confirm a command’s own help before assuming its network behaviour matches the scan command’s.
Reports and CI responsibility
Once Guardian writes a report, the report is yours and so is the disclosure decision. Review one before sharing it, and apply your own retention rules to what you keep.
In CI, analysis runs inside your runner. Using a hosted CI service means that service processes your repository under the arrangement you already have with them — unchanged by Guardian, but worth stating if source residency is the reason you chose a local-first tool. A self-hosted runner is the answer in that case.
Keep report artefacts under the same access rules as build logs, and avoid logging report contents into systems with wider access than the repository itself.
Secrets and databases
Normal scanning needs no credentials of any kind. Guardian should never ask you for the following, and something claiming to be Guardian that does is worth a second look.
- Source code upload
- APK or IPA upload
- Signing certificates or signing keys
- Provisioning profiles
- Environment secrets or API tokens
- Production database credentials
- Production database rows
- Raw reports sent anywhere automatically
No connected feature may give a cloud service direct access to a production database, and a cloud failure must never prevent a local scan from completing.